Комментарии 6
Мой довольно скромный опыт подсказывает, что наличие мотивации и амбиций довольно быстро уводит вчерашних тестировщиков в смежные области. Часто есть несколько типовых путей роста:
Тест-дизайнер -> системный аналитик.
Тест-лид -> менеджер проекта.
В моём случае автотесты и произв-ть -> cm(devops)-> разработчик.
Есть и та область, которая кажется тупиком, но по факту это целая пещера с лабиринтами: тестирование уязвимостей.
Встречал, что организация не видит потребности тестировщика в росте и развитии, то зачастую у неё не остаётся тестировщиков вовсе, зато "гибкие методологии разработки". Поэтому совет для тестировщика: определитесь с вашими стремлениями по саморазвитию и как можно скорее донесите их до руководства.
Обычное ручное тестирование может быть творческим и требовательным к скиллам: например, исследовательское тестирование.
Подскажите, по вашему опыту исследовательское тестирование эффективнее, чем регрессионное? Понятно, что цели немного разные, но если область охвата регрессионного включает предполагаемую область исследовательского, то последнее выглядит не таким надёжным, как первое. Да и заказчик зачастую платит только за тестирование по сценариям с понятными протоколами.
Исследовательское тестирование широко используют продуктовые компании типа Google и Microsoft (Уиттакер о них пишет). При регрессионном тестировании может использоваться исследовательский подход.
Заказчик участвует только в приемке, а до приемки ещё нужно дойти.
широко используют продуктовые компании типа Google и Microsoft (Уиттакер о них пишет)
Я бы сравнивал исследовательское у Google, когда отработала SDET команда, что то проверили руками, а потом сами же используют свои продукты (как раз исследовательское тестирование). В наших реалиях "исследовательское тестирование" это отсутствие документации как в разработке, так и экономия в тестировании, даже E2E написанный в ворде даст больше результатов - продукт будет выполнять то, что должен.
он лишь тестировщик (вспомним деление на testing, QA, QC и вот это вот все)
Многие QA Engineer работа QA не всегда достается. Работу QC часто выполнят как раз обычный тестировщик, это финальная проверка перед релизом.
От тестировщика — к QA инженеру. Советы новичкам