Утрируете. Предположим вы берёте в кредит автомобиль. Вы отличаете "стоимость владения" от "суммы выплаты по кредиту"?

Утрирую я только в кроссовках :) Просто пару лет просматриваю форум, на котором о кредитах очень много и многие общаютсяс разбором полетов... и про стоимость владения большинство знает и учитывает, пусть не в терминах, но на интуитивном уровне точно. А не учитывает как раз таки крупные траты, которые возникают регулярно, но в разных областях... И именно оценка стоимости одежды, полетел комп, вдруг оказалось, что надо купить посуду, стоматолог, с друзьями в ресторане загуляли, ДПС штрафанул пару раз и т.п. до бесконечности.
Ну не замечают этого... и именно на этом все сыпется.
Либо личный героизм, когда сознательно идут на жесткое сокращение расходов, типа, полгодика потерпеть можно, а там зарплату поднимут или халтуру найду, ЗАТО иномарка (марку сами подставьте)... или что там еще.

Например, два раза решал с разной степенью вовлечённости в процесс, вопросы с поиском новой квартиры сотруднику и помогал с переездом - не потому что я такой офигенно добрый, мне просто надо, чтобы человек работал, а не ломал голову когда его семью и вещи выбросят в коридор.

Так это проблема в диком рынке аренды. И никакое образование тут не поможет: либо повезло встретиться с нормальным арендодателем, либо нет.

Читали на 4-ом курсе. Первый семестр. Я, наверное, тупой,но в меня теория не влезла. Читал потом сам - наверное оттого и хромаю на эту ногу.

Моя мысль была проста: если брать тоже ООП, то основные формулировки много букв не занимают. А дальше идет процесс осмысления и использования, но уже в рамках других предметов, курсовых и т.п. Не знаю как у Вас, но в моем ВУЗе возможностей было полно.
Вот только с самого начала медитировали над этим избранные, а остальные поняли, что это оказывается нужно, только когда на работу устроились...

вставлю свое имхо: никогда не понимала ВУЗы.

Но на заочном Вы все-таки были :) Кстати, на лекции получаешь гораздо больше... особенно, если преподавателю есть чем поделиться... в книгах этого может и не быть... совсем. :)

Ясно, что однозначного ответа на мой вопрос нет. И я вовсе не призываю осудить ни ту, ни другую точку зрения.
Я просто хочу собрать некоторую информацию о том, какой подход преобладает в реальных условиях.
Не в абстрактных условиях, а в вашей конкретной компании -- кому отдаётся преимущество, узким или широким специалистам?

В моих реальных условиях все зависело от компании.
Если разрабатывался один продукт, то брались узкие специалисты.
Если было много мелких заказов с использованием различных технологий для каждого проекта, то предпочтения отдавали специалистам широкого профиля.

Вобщем-то оба высказывания верны, просто применимы к разным случаям жизни.

Но цель хаотического тестирования (то, что я видела во многих небольших компаниях) - это "потестриуйте что-нибудь, у всех наших конкурентов есть тестеры" :) А каким в данном случае может быть критерий успешности тестов? Только количество багов, так как оценить покрытие невозможно и предугадать масштабы пропуска дефектов до выхода продукта в свет - тоже. Цели контроля качества не стоит, оценки статуса продукта не стоит. Только искать баги. А это цель, при которой подойдут любые способы и любые скиллы, и процесс достижения именно этой цели я называю ad hoc или хаотическим тестированием.

В более зрелых компаниях встречала другую интерпритацию ad hoc тестирования.
Самый простой пример: для графических компонент проводилось хаотичное кликание по произвольным координатам и ожидалось, когда все завалится.
Помимо графики есть еще медоборудование, мобильная связь, датчики движения, сканеры, распознаватели... Какой-то эталонный набор данных или тесткейзов может быть слишком узким или его очень долго создавать... И вот тогда можно на постоянной или временной основе проводить хаотичные тесты, особенно, если это все можно быстро реализовать. :)
Критерий везде успешности простой: справимся или нет + анализ логов на ошибки. Иногда возможно вывести и некие характеристики по результатам испытаний :)
Тест-кейзов действительно нет, вернее, они генерируются... и в принципе никогда не повторяются...

Некоторые баги зависят напрямую от порядка предыдущих действий и введенных значений.
Как только обнаружили ошибку, отматываешь в памяти назад все свои действия, добиваешься минимального набора действий для падения/ошибки с момента запуска приложения (но тратить на это полдня не стоит) и записываем последовательности этих действий: на что нажимать, что и куда вводить... ну или более кратко, но чтобы было понятно сразу в чем проблема.

"Как получился этот баг" - ежели хочешь успешно пройти стажировку и расти дальше, то ищи сам. :)

Для работы тестировщика, надо приобретать знания: по программированию, как работают и из чего состоят различные приложения, что и как устроено в операционных системах и т.п. Вобщем начинать с азбуки.
То, что вам легко давались какие-то пакеты - это хорошо. Но учтите, что разработчики ОЧЕНЬ старались, чтобы с ними было легко работать.

Могу дать пару советов от себя лично:
1. присмотреться к деятельности Quality Assurance - налаживать и улучшать процессы в больших компаниях.
2. Некоторые проекты (их довольно много.. и еще могут возникнуть) нуждаются в грамотной прослойке между программистами и заказчиками, чтобы облегчить всем жизнь. И по этому поводу существуют разные позиции: начиная от простого саппорта (если хочется относительно спокойной жизни, или наоборот любите командировки), заканчивая придумыванием новых фич и постановкой задач для развития проекта и подавления конкурентов (если есть амбиции и хочется работать головой). Если у вас есть идеи собственного проекта и его развития, то никто не запрещает предложить свои услуги "фирме-издателю".

Ответы на вопросы вполне доступны, и если будет время, в будущем постараюсь что-то из них перевести.

Присоединюсь к мнению коллег о том, что "просто перевести" принесет скорее вред, чем пользу.
Читая оригинал в скобках узнаю термины, которые широко использую в своей работе. При этом, некоторые переводы просто не верны, да и вопросы, мягко говоря, странно сформулированы, с моей колокольни. Без кропотливого изучения "а что хотел сказать этим автор" тут не обойтись...

А я считаю что это очень плохой тест для тестировщика. И все остальные тесты типа "протестируйте наше приложение и напишите список ошибок"
Почему плохой, спросите вы? Ок, а какие выводы вы, как работодатель, можете сделать из списка багов? Оценивать работу тестировщика по количеству багов это, вообще, нормально?
С другой стороны, таким образом можно отсеить тех, кто действительно хочет получить работу в данной компании и не пожалеет некоторого времени для поиска и описания 40-50 багов.
Но как тест это полная фигня.

Присоединюсь к мнению коллеги. В свое время видела эту программку (или очень похожую, т.к. мир не стоит на месте). Так вот: основной упор там был сделан именно на какие-то интерфейсные глюки и ошибки, типа, кто-то что-то забыл. Ну и основные выводы, которые я могла бы извлечь из списка багов, что товарищ не поленился нажать на все кнопки. При этом нельзя судить хотя бы насколько оптимально он это делал (иногда бывает перед командой стоит задача в короткие сроки получить что-то работающее), насколько он способен оценивать ошибки именно в логике приложения (для некоторых проектов это гораздо критичнее, т.к. ставит под вопрос весь проект в целом)... И т.д. и т.п.
Вобщем, может подойти только для определенного класса проектов :)