Почему работа тестировщика сложнее, чем кажется
О тестировщиках часто говорят как о специалистах, которые просто проверяют готовые сценарии и ищут ошибки. Из-за таких представлений работа тестировщика со стороны может казаться довольно простой и предсказуемой.
Когда Диана только приходила в тестирование, у нее тоже были свои ожидания от профессии. Но уже в первые месяцы работы стало понятно, что все устроено гораздо сложнее и интереснее.
Поговорили с Дианой о том, как на самом деле выглядит работа тестировщика.
Что оказалось самым большим заблуждением о тестировании?
Мне казалось, что работа тестировщика довольно простая: проверить сценарий, найти ошибку и передать задачу дальше. Но довольно быстро стало понятно, что сама проверка — только часть работы.
Перед тестированием нужно разобраться в требованиях, продумать сценарии, подготовить тестовые данные и понять, как изменения могут повлиять на другие части системы. Иногда уже на этапе анализа появляются вопросы или находятся противоречия в логике задачи.
Почему «найти баг» — это не самая сложная часть?
Потому что сам дефект еще нужно правильно описать и воспроизвести. Недостаточно написать, что что-то не работает. Нужно зафиксировать шаги, ожидаемый и фактический результат, приложить логи или скриншоты. И даже после этого бывают ситуации, когда ошибка у разработчика не воспроизводится.
У меня был случай с массовыми инцидентами: ошибка возникала только при определенной последовательности действий и сопровождалась исключением в логах. Пришлось вместе с разработчиком проходить сценарий шаг за шагом и искать, в какой момент система ведет себя неправильно.
Правда ли, что автотесты постепенно заменяют ручное тестирование?
Нет. Автоматизация закрывает часть задач, особенно регрессионные проверки, но есть сценарии, которые сложно или нецелесообразно автоматизировать.
Например, проверки ролей и ограничений доступа, сложные цепочки изменений или нестандартные пользовательские сценарии. В таких задачах важно не только проверить формальную логику, но и посмотреть на систему глазами пользователя: насколько поведение выглядит понятным и ожидаемым.
Бывали ситуации, когда ошибку все-таки пропускали?
Да, и это нормально для сложных систем. Однажды я тестировала дополнительные настройки услуги и проверила основной функционал, но не повторила те же проверки в связанном компоненте. В результате ограничения доступа работали не полностью: часть сотрудников получала доступ к функциональности, которой не должна была пользоваться.
Этот случай показал мне, что тестирование — это не попытка найти абсолютно все ошибки, а работа с рисками и внимательностью к связям внутри системы.
Насколько тестировщику важно понимать код?
Глубокие знания программирования нужны не всегда, но базовое понимание сильно помогает в работе. Например, у меня была задача, связанная с логикой формирования поля Reply-To в письмах. В интерфейсе было непонятно, почему параметр не появляется. После просмотра Groovy-кода стало ясно, что он зависит от заполнения других полей при отправке письма.
Такие вещи помогают быстрее находить причину проблемы и проще общаться с разработчиками.
Как со временем изменился твой взгляд на профессию?
Наверное, главное изменение — понимание того, насколько сильно тестировщик влияет на качество продукта. Это не роль «человека, который ищет ошибки». Тестировщик участвует в обсуждении логики, помогает замечать слабые места в сценариях и смотрит на систему с точки зрения пользователя.
И именно поэтому тестирование оказалось для меня намного интереснее, чем я представляла в начале.
