Мифы о тестировании

Миф 1. Тестировщик просто нажимает кнопки и проверяет, работает ли программа

Со стороны может казаться, что тестирование — это набор действий по готовому сценарию. В реальности «нажатие кнопок» занимает лишь часть времени.

Перед началом тестирования я изучаю требования от аналитика. Иногда они описаны не полностью или допускают разные трактовки, поэтому приходится уточнять детали. Это важный этап: если неправильно понять цель задачи, можно протестировать не то, что действительно нужно.

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

Только после этого начинается проверка функциональности. Если я нахожу отклонение от ожидаемого поведения, нужно:

• воспроизвести дефект,

• зафиксировать шаги,

• описать ожидаемый и фактический результат,

• приложить логи или скриншоты.

Описание дефекта может выглядеть так:

Иногда даже при подробном описании у разработчика ошибка не воспроизводится. Тогда мы вместе в онлайне повторяем сценарий и ищем причину. После исправления дефекта задача снова проходит проверку.

Кроме этого, я пишу тест-кейсы для автоматизированных проверок, использую ИИ-инструменты для подготовки данных и ускорения рутинных операций, участвую в оценке трудоемкости тестирования задач и делюсь опытом в статьях.

Миф 2. Если есть автотесты, ручной тестировщик не нужен

Автоматизация действительно ускоряет процесс проверки функциональности продукта и снимает часть нагрузки. Но она не заменяет ручного тестировщика.

В работе много сценариев, которые сложно или нецелесообразно автоматизировать. Например:

• проверка выдачи ролей пользователям в разных сочетаниях прав;

• создание и изменение групп для обработки запросов;

• отслеживание записей в истории изменений при сложных цепочках действий.

Такие кейсы часто зависят от контекста и нестандартных условий. Ручное тестирование позволяет выявить ошибки, которые могут быть упущены при автоматизированной проверке, а еще увидеть поведение системы шире: не только соответствует ли оно формальным требованиям, но и насколько логично и удобно выглядит с точки зрения пользователя.

Миф 3. Тестировщик должен найти все ошибки

В начале мне казалось, что задача тестировщика — обнаружить каждый возможный дефект. На практике это недостижимо.

Можно и нужно стремиться к максимальному покрытию сценариев, но программное обеспечение всегда остается сложной системой с множеством связей.

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

Это была ошибка доступности услуги с различными ограничениями — по расположению, подразделению или для определенных сотрудников.

Например, если в услуге указана политика «Всем, кроме указанных» и отмечен конкретный сотрудник, то для этого сотрудника услуга не должна быть доступна. В системе есть компонент, который должен учитывать ту же логику ограничений. 

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

Этот опыт показал, что тестирование — это управление рисками, а не гарантия абсолютного отсутствия дефектов.

Миф 4. Тестировщик — это просто человек, который находит ошибки

Со временем я поняла, что поиск дефектов — лишь часть работы. Тестировщик влияет на продукт и до релиза. Он не только находит ошибки, но и помогает предотвратить их появление в будущем, предлагая улучшения в процессе разработки и тестирования.

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

Иногда такие предложения принимаются сразу, иногда откладываются в бэклог. Но сама возможность обсуждать удобство и логику поведения системы — важная часть роли тестировщика.

Миф 5. Тестировщику не нужно знать программирование

Глубокие знания программирования не всегда обязательны для ручного тестировщика, но понимание базовых принципов может быть очень полезным.

Мне, например, помогают поверхностные знания Groovy:

• я могу написать простой скрипт для поиска или создания объектов;

• понимаю структуру логов и быстрее ориентируюсь в ошибках;

• лучше представляю, как система обрабатывает данные.

У меня была задача, связанная с корректировкой логики определения валидного адреса для поля Reply-To при формировании ответного письма. При получении письма и просмотре сведений параметр Reply-To отсутствовал, и было непонятно, при каком условии он формируется.

Проанализировав код модуля на Groovy, я увидела, что добавление параметра Reply-To зависит от заполнения других полей. В нашем случае эти поля при отправке письма не заполнялись, поэтому параметр не формировался.

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

Миф 6. Работа тестировщика скучная и однообразная

На самом деле, ручное тестирование может быть интересным и разнообразным процессом.

Каждая задача — это:

• уточнение требований;

• поиск причин «плавающих» дефектов;

• изучение и тестирование новой функциональности;

• анализ влияния изменений на смежные модули;

• продумывание нестандартных сценариев.

Иногда приходится долго искать причину редкой ошибки, которая проявляется только при определенной последовательности действий. Это требует терпения и системного мышления.

Работа разнообразна именно потому, что продукт развивается, а сценарии использования меняются.

Миф 7. У тестировщиков нет карьерного роста

В начале мне казалось, что развитие ограничивается уровнем «ручной тестировщик». Сейчас я вижу гораздо больше направлений. После ручного тестирования можно перейти в автоматизацию, развиваться в сторону аналитики или уйти в разработку.

Ключевое — интерес к продукту и готовность брать ответственность за качество. В моем окружении есть коллеги, которые сменили направление или стали руководителями команд.

Сейчас я развиваюсь горизонтально: углубляю знания в тестировании и расширяю зону ответственности. Но выбор траектории остается за специалистом.

Что в итоге

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

Если вы только планируете входить в профессию, полезно заранее понимать: тестирование — это не «легкий старт в ИТ», а полноценная инженерная роль с широкой зоной ответственности.