В ходе ручной проверки второй сценарий проходит только после выполнения первого. Как доказать, что результат не вызван загрязнением состояния?
Нужно повторить второй сценарий в чистом состоянии и сравнить результат с запуском после первого сценария. Если результат меняется, следует зафиксировать зависимость: определить, какие данные или настройки переносятся между сценариями, и исключить их либо оформить это как дефект.
Практика изоляции проверок появилась из-за состояния приложений, которое сохраняется между операциями: данных в базе, файлов, сессий, настроек, кэша или статусов объектов. Без контроля состояния тестировщик может принять побочный эффект предыдущей проверки за корректное поведение продукта.
Изоляция особенно важна для повторяемости тестов. Она позволяет понять, вызван ли результат проверяемым действием или скрытой подготовкой, выполненной ранее.
Последовательность сценариев может незаметно менять окружение. Например, первый сценарий создаёт пользователя, меняет его роль или переводит заказ в другой статус, а второй сценарий использует уже изменённые данные.
Если такую зависимость не обнаружить, возможны ложноположительные результаты: сценарий проходит только потому, что предыдущая проверка подготовила нужное состояние. Возможны и ложноотрицательные результаты, если предыдущий сценарий оставил данные, блокирующие ожидаемое действие.
Сначала второй сценарий выполняют отдельно, используя заранее подготовленное исходное состояние. Затем его повторяют после первого сценария. Результаты, тестовые данные, пользовательские роли, настройки и состояние объектов нужно сравнить.
Если различие обнаружено, следует локализовать источник зависимости. Проверяют созданные и изменённые записи, статусы объектов, права доступа, сессионные данные, кэш и побочные изменения, предусмотренные шагами первого сценария.
После этого выбирают способ устранения зависимости:
Предпочтительно, чтобы сценарий сам описывал необходимое начальное состояние и мог быть выполнен независимо. Однако полная изоляция не всегда нужна: некоторые сквозные проверки по смыслу требуют последовательного перехода между состояниями. В таком случае зависимость должна быть явной, контролируемой и отражённой в документации.
Важно различать загрязнение тестовых данных и реальную бизнес-зависимость. Если по требованиям заказ можно оплатить только после создания, независимый запуск проверки оплаты без существующего заказа некорректен. Но если результат меняется из-за случайно оставшейся сессии или записи, это уже проблема подготовки или продукта.
Тестировщик проверяет возврат заказа. После сценария оплаты возврат проходит, но при самостоятельном запуске сценария возврата система сообщает, что заказ не найден.
Рассматривались два варианта. Первый — всегда запускать сценарии строго последовательно. Это быстро, но скрывает зависимости и делает результат уязвимым к изменению порядка или данных. Второй — создавать заказ и доводить его до оплаченного состояния в предусловиях сценария возврата. Это требует больше времени, зато делает проверку повторяемой и локализует причину сбоя.
Выбран второй вариант. Дополнительно проверили, что оплаченный заказ действительно существует, принадлежит нужному пользователю и не был изменён предыдущим сценарием. В результате выяснилось, что исходный тест ошибочно полагался на данные, оставшиеся после другого теста; после явной подготовки состояния результат стал воспроизводимым.
1. Достаточно ли один раз запустить сценарий отдельно, чтобы доказать его независимость?
Нет. Один запуск не показывает, что зависимость отсутствует: результат мог случайно совпасть с ожидаемым. Надёжнее выполнить сценарий в нескольких контролируемых состояниях, включая чистое состояние и состояние после потенциально влияющего сценария.
2. Всегда ли различие результатов означает дефект продукта?
Нет. Различие может быть следствием неверных предусловий, устаревших данных, особенностей окружения или допустимого бизнес-процесса. Дефект продукта следует регистрировать после проверки требований и установления, что система некорректно обрабатывает одно и то же исходное состояние или не должна зависеть от посторонних изменений.
3. Что делать, если очистка данных после сценария невозможна?
Нужно изолировать данные другим способом: использовать уникальные сущности, отдельные учётные записи, отдельный тестовый контур или заранее подготовленные снимки состояния, если это доступно процессу. Ограничение следует явно описать в тестовой документации, потому что неконтролируемое накопление данных снижает доверие к результатам и усложняет расследование дефектов.