Краткий ответ

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

Исторический контекст

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

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

Постановка проблемы

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

Последствия зависят от ситуации:

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

Главный риск — потеря диагностичности: результат теста перестаёт показывать, какая именно проверка дала сбой.

Подробное решение

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

Надёжный тест-кейс должен одним из способов фиксировать подготовку:

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

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

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

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

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

Ситуация из практики

Тест проверяет отмену заказа. В предусловии сказано: «существует оплаченный заказ пользователя», но идентификатор заказа не указан, а шаги создания оплаты отсутствуют. Один тестировщик получил успешный результат, используя старую запись; другой не смог выполнить сценарий после очистки стенда.

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

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

Что кандидаты часто упускают

Достаточно ли указать в предусловии идентификатор записи?

Нет. Идентификатор делает запись адресуемой, но не гарантирует нужное состояние. Следует зафиксировать значимые свойства: владельца, статус, права доступа, связанные сущности и допустимый срок актуальности данных. Иначе тест может обращаться к той же записи, но проверять уже не тот сценарий.
Можно ли считать тест независимым, если данные подготовлены отдельным тест-кейсом?

Не автоматически. Зависимость всё равно существует, если основной тест запускается только после другого или использует его побочный результат. Такая связь должна быть явной, проверяемой и устойчивой к изменению порядка выполнения. Если зависимый тест падает, основной следует помечать как невыполненный из-за неподготовленного предусловия, а не как дефект продукта.
Почему создание данных внутри теста иногда тоже не решает проблему?

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