На самом деле, где-то четверть (по личным наблюдениям) практикуются.
Но, зачастую, так получается, что человек берет софтину и начинает активно искать баги, а не тестировать, чем потом неистово хвастается на собеседованиях.
Тут желательно присутствие некого подобия ментора, который даст стартовый пинок и покажет, как надо.
Когда я шел в тестирование, у меня были точно такие же мысли (а-ля «пару лет потестить, набраться опыта, и программеры»). Всё от поверхностного понимания процесса и перспектив карьерного роста. Но, ничего, понимание пришло после первого же собеседования.
Хотя, по сути, если тестер переквалифицируется в дева с течением времени — в этом страшного нет ничего, дело ведь в понимании своей работы и отношению к ней.
Такие «недо-программисты-тестировщики» преимущественно в любой сфере будут партачить и халатно относиться к своим обязанностям.
Вообще замечаю, что у многих подобное представление о работе QA.
Скорее всего, ноги растут от печального опыта работы с некорректно поставленным процессом. Ну и сложившихся, в связи с этим, стереотипов.
«Давайте, протестите быстренько в субботу, нам надо релиз в понедельник выпускать» ©
Всем ТС-мужчинам на тему «хочу в IT» можно советовать пол сменить? :)
По сути — подтверждаю, тоже сталкивался с прецедентами, когда брали людей, руководствуясь непонятно какой логикой. Но... Хозяин-барин =\
Все зависит от того, как построен процесс разработки :)
Иногда приходят задачи с заголовком типа «Реализовать функцию n», со статусом «готова к тестированию» и пустым телом.
Когда задействованы сложные бизнес-процессы, и точно не знаешь, что затронула/не затронула реализация остается только втихую материться, идти выяснять подробности к постановщику/ разработчику, в сотый раз напоминать, чтобы описывали задачи более объемно и в итоге самому описывать логику, чтобы в дальнейшем хотя бы иметь возможность в этом разобраться.
Само собой, в нормальных конторах такого наблюдаться не должно :)
Всё-таки, считаю, что при сферически правильном построении процесса выше будет стоять умение определить и хотя бы поверхностно спроектировать минимальный набор тестов на основании спецификации/ТЗ/юзкейсов.
На практике часто приходится и без этого обходиться, опираясь лишь на логику и общее понимание конкретных бизнес-процессов :)
Погуглил нашел форум и стало интересно сколько же находили такие же тестировщики как и я. Некоторые писали 10, а другие 100.Что ж все акцентируют внимание на количестве найденных багов?
Курсы QA вообще не нужны :)