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