Тестовые данные: кто их описывает и почему «на тестовом всё работает»

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

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

Почему на стенде всё работает

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

Аналитик описывает состояния, а не записи

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

• часть «Дано» каждого критерия приёмки — это и есть нужное состояние;
• исключения сценария — каждое требует данных, при которых оно возникает;
• жизненный цикл сущностей из модели данных — по одному объекту в каждом статусе, включая редкие и конечные.

ТЕСТОВЫЕ ДАННЫЕ ДЛЯ TASK-2140 (возврат товара)
Д-1  заказ доставлен 14 дней назад           граница срока, критерий 1
Д-2  заказ доставлен 15 дней назад           граница срока, критерий 2
Д-3  заказ в пути                            отрицательный случай, критерий 3
Д-4  заказ с комплектом по BR-12             расчёт суммы, сценарий 3а
Д-5  заказ, уже частично возвращённый        расчёт суммы, остаток
Д-6  заказ 2021 года, без часового пояса     старые данные, критерий 4
Д-7  покупатель с 1200 заказами              длинный список, скорость

По такому списку тестировщик или разработчик готовит данные сам. А аналитик видит, какие критерии проверить нечем, ещё до тестирования.

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

Время как данные

Половина правил в продуктах завязана на сроки: 14 дней на возврат, пробный период, закрытие месяца. Ждать две недели ради проверки никто не будет, поэтому на стенде нужен способ «сдвинуть время»: создать запись с датой в прошлом или переставить системные часы для теста. Если такого способа нет, критерии со сроками будут проверяться только на проде — пользователями.

Отдельно стоит проверить границы календаря: последний день месяца, 29 февраля, смену года, переход на летнее время там, где он есть. Именно там «в течение 14 дней» неожиданно превращается в 13 или 15.

Копия прода — не решение

Соблазн понятен: взять копию боевой базы, и на стенде будет всё как в жизни. Но у копии три проблемы:

• Личные данные. Имена, телефоны и адреса покупателей на стенде, куда есть доступ у всей команды и подрядчиков, — нарушение и обещаний пользователям, и закона. Копия допустима только обезличенная.
• Нужного случая там может не быть. На проде миллион заказов, но ни одного, доставленного ровно 14 дней назад, именно сегодня.
• Её нельзя повторить. Тест, прошедший на копии от вторника, в пятницу может упасть — данные изменились. Хороший набор восстанавливается одной командой в одно и то же состояние.

Работающая схема обычно смешанная: обезличенная копия даёт объём и «грязь», а намеренно созданные записи — конкретные состояния из списка.

Признак, что тестовых данных нет: перед каждой проверкой тестировщик полчаса создаёт заказ руками — и каждый раз немного иначе.

Проверка за пятнадцать минут

Возьмите критерии приёмки ближайшей задачи и для каждой части «Дано» спросите: есть ли такая запись на стенде прямо сейчас? Если нет — можно ли её создать за минуту? Критерии, для которых ответ «нет» дважды, будут проверены поверхностно или не будут проверены вовсе.

Что дальше

Всё, что не поймали на стенде, встретится с настоящими данными в день релиза. Последняя проверка идёт уже на проде — и к ней тоже надо готовиться заранее.