Нажимать на кнопки может любой. Зачем тестировщику учиться и чему?
Это распространённое и обидное заблуждение. Хотя есть такой вид тестирования как monkey-testing, когда ты сидишь как обезьянка и тыкаешь по кнопкам без плана и цели, но с намерением что-нибудь да сломать.
Есть спектр знаний, необходимый тестировщику. Во-первых, теория тестирования — тест-кейсы, баг-репорты, чек-листы, граничные значения и классы эквивалентности, какие есть виды и типы тестирования, какие уровни, различные баг-трекеры.
Какие-то из этих пунктов тестировщик ежедневно применяет в своей работе, какие-то — реже. В любом случае, на любом собеседовании обо всём об этом спросят.
Следующий аспект — различные инструменты. Devtools, мобильные утилиты. Необходимо уметь работать с API; полезно уметь пользоваться языком SQL, если работаешь с базами данных; важно уметь работать с командной строкой; с системой контроля версий Git.
Тестировщики — это несостоявшиеся программисты?
Программист и тестировщик — две разные профессии. Это люди с разными типами мышления, во многом, с разными взглядами на мир, но, которые хорошо друг друга дополняют. Я сама учусь на разработчика, чтобы лучше понимать коллег.
Каждый играет свою ключевую роль в проекте. Ответственности и задач у тестировщика не меньше, чем у программиста.
Цель — сделать классный качественный продукт, и мы всячески стараемся друг другу в этом помочь.
Кто руководит тестировщиками? Кто проверяет их на «профпригодность»?
Тестировщиками руководит лид отдела тестирования. Также у него на подхвате старшие тестировщики, которые могут взять под своё крыло джунов и стажеров.
На собеседованиях может присутствовать отдел разработки, продакт-менеджер. Особенно это актуально для стартапов, где только формируется отдел тестирования и лида ещё нет.
Тогда акцент может смещаться со знания теории и методик тестирования на soft-скиллы, знание этапов разработки продукта, понимание, когда нужно включать тестирование, на твой опыт, на проекты, над которыми ты работал.
Тестовые задания часто похожи на реальную жизнь. Интервьюер рассказывает про какую-то фичу и смотрит, какие ты вопросы будешь задавать, как будешь подходить к тестированию. Нужно не бояться рассуждать вслух.
Тестировщику нужно дорогущее оборудование для тестирования?
Смотря, что считать дорогим. У меня далеко не самый дешёвый компьютер, например. Но на самом деле для тестирования достаточно ноутбука или простого стационарного компьютера.
Автоматизированное тестирование хуже ручного?
Не хуже и не лучше — это инструмент, который облегчает рутинные задачи. Автотестами, в основном, покрывается регресс приложения, чтобы постоянно не проверять его с нуля руками после каждого каждого релиза. Это очень дорого.
Но полностью уйти от ручного тестирования практически невозможно, да и не нужно. Бывают кейсы, пройти руками которые гораздо дешевле, чем покрыть их автотестами. К тому же, автотесты тоже нужно поддерживать актуальном состоянии. Стоит измениться какому-нибудь цвету кнопки или названию, — всё, автотест, проверяющий данный функционал, придется переписывать.
Если тестировщик не нашел ни одной ошибки, — это плохой тестировщик?
Это зависит от конкретной задачи. Вот дали первый раз посмотреть на проект — хотя бы один баг ты найдешь. Возможно, его уже до тебя находили, но решили не править.
А когда я тестирую маленькую задачу, бывает, что конкретно в этом месте багов нет. Не стоит перегибать и заниматься избыточным тестированием, чтоб всенепременно что-нибудь да найти.
Не только от тестировщика это зависит. Часть ошибок отлавливается ещё до передачи в тестирование. Бывают скрупулёзные разработчики, у которых находится время на то, чтобы самим немного потестить задачу. Особенно, если это фронтенд, ведь он не пишется вслепую.
Затем — review кода, когда другие разработчики смотрят на код, проверяют его читаемость, стиль, отсутствие ошибок. И только после этого задача переходит в тестирование.
Заказчики, в первую очередь, вешают все пропущенные баги на тестировщика?
Зависит от человека. Конечно, легче всего повесить на тестировщиков и такое случается. Допуск бага на прод — это зачастую совокупность факторов, а не только то, что тестировщик не захотел смотреть или плохо это сделал.
Сломаться что-то может вообще на разных этапах сборки и релиза и уже после тестирования. Особенно на больших проектах, где работает много команд. А баги мобильных приложений вообще часто проявляют себя уже после выкатки и обнаруживаются в ходе проверки на физическом устройстве. Это рабочий процесс.
Есть специфические задачи, которые сложно протестировать руками тестировщиков. Какой-нибудь рефакторинг на бэкенде, например, иногда тестируют сами разработчики.
Если заказчик адекватный и понимает весь этот процесс, он не будет вешать все на тестировщика, потому что у нас командная работа и нет цели спихнуть вину на кого-либо за какую-то ошибку.
Простая истина в том, что багов нет только в том коде, который не написан. Никакой катастрофы в этом нет. Нахождение багов и их исправление в течение жизни продукта — нормальная и привычная процедура.
Попробовать себя в роли тестировщика можно бесплатно в Яндекс Практикум.