Тестирование без требований: оракулы, карта продукта и риск-ориентированный подход

Что такое ТЗ в QA?

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

Когда эталона нет, роль ТЗ берут на себя оракулы – другие источники истины: закон, договор, поведение прошлой версии, модель данных, ожидания пользователей. Отсутствие ТЗ не означает, что тестировать невозможно – оно означает, что нужно перестать искать один документ и начать собирать критерии, по которым вы будете проверять систему. 

О чём статья?

Мы публикуем очередной цикл экспертных статей. Теперь речь пойдёт о методологии приёмки для проектов без ТЗ, где требования меняются быстрее, чем вы успеваете дописать тест-кейс. Всего будет 3 части и это первая. В ней мы разбираемся, почему отсутствие ТЗ – это не одна проблема, а целых пять, и почему для решения каждой нужен свой подход. 

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

Утро понедельника. Открываешь трекер – «Протестировать личный кабинет, релиз в пятницу». Идёшь за подробностями: чат на 400 сообщений, два макета в Фигме, оба подписаны «финал», а разница между ними – половина экранов. И условный Коля в помощь, который вроде как точно в курсе и передаст контексты, но не факт.

Если у вас так не бывает – вы работаете по ГОСТ 34.602, где требования заморожены. Искренне поздравляем, дальше можно не читать.

Остальных сразу предупреждаем. Статья не о том, как заставить бизнес писать техзадание. Мы пробовали – это работает только там, где за документ платят отдельно. В остальных случаях бизнес по-своему прав: пока продукт ищет форму, подробное ТЗ устаревает быстрее, чем проходит согласование. Речь о том, как выстроить приёмку, которая не разваливается от изменений.

Практики, о которых пойдёт речь, придуманы не нами – на первоисточники мы дадим ссылки. Но имейте ввиду, что они создавались для среды, где в команде есть Product Owner с полномочиями, аналитик и культура письменных договорённостей. У нас чаще иначе: PM, который сам себе аналитик и заказчик, передающий знания голосовыми сообщениями, ну и релиз в пятницу. Поэтому адаптируем под наши реалии.

Почему нет ТЗ: 5 разных причин и что с этим делать

Первая ошибка, которую многие допускают годами, – реагировать на отсутствие ТЗ одинаково. Хватать чек-лист, идти смотреть продукт, писать вопросы. Иногда срабатывает, но чаще нет. На самом деле, отсутствие ТЗ указывает сразу на 5 проблем на проекте. Самое важное, вовремя понять, с чем имеете дело и построить адекватный план. 

Диагноз ставится быстро. Соберите PM, разработчика и того, кто ближе всех к заказчику, и задайте четыре вопроса. 

1. Кто последним менял логику?
2. Где это записано?
3. Кто первым узнает, если поведение изменится?
4. Что будет, если через месяц спросить, почему сделано именно так?

Всё будет понятно уже по реакции на вопросы, даже если вам не ответят вслух.

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

Вы ищете требования, а нужны оракулы

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

Механизм, который позволяет распознать проблему, в теории тестирования называется оракулом. В нынешнем виде термин оформили Джеймс Бах и Майкл Болтон в рамках подхода Rapid Software Testing. Суть простая: спецификация – лишь один оракул из десятка, причём не самый надёжный, ведь документ тоже пишет человек. Отсутствие ТЗ означает потерю одного оракула, остальные остаются на месте. Задача тест-инженера без документации – собрать и явно назвать доступные оракулы. Болтон свёл их в мнемонику FEW HICCUPPS, ниже – наш перевод под российские реалии.

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

Менеджеру это даёт формулировку, которую не стыдно произнести перед заказчиком. Сказать «мы не можем тестировать, дайте требования» – значит поставить команду в позицию жалобщика. Сказать «мы принимаем систему по восьми критериям: закон, договор, поведение прошлой версии, согласованность, данные, ожидания пользователей, назначение и статистика продаж – вот результат по каждому» – значит поставить команду в позицию эксперта. Разница колоссальная. 

Карта продукта: документ, который при правильном подходе не устаревает

Оракулы говорят, по чему сверять – осталось понять, что сверять.

Карта продукта описывает не поведение системы, а перечень того, что в системе есть. Поэтому от изменения требований она не устаревает, только от изменения состава. Структуру карты можно взять из Heuristic Test Strategy Model Джеймса Баха, там она называется SFDIPOT.

Как собрать карту за два дня без аналитика?

Начинайте с самых честных источников и далее уже к разговорам с людьми.

1. Схема базы и миграции. Здесь за 90 минут выясняется, что типов пользователей три, а рассказывали про два.
2. Роутинг и точки входа. Займёт час. Все URL и эндпоинты, включая забытые. Плюс OpenAPI, если живой.
3. Логи за месяц и конфиги. Три часа. Что реально вызывается и как часто, топ ошибок, крон, очереди, флаги. Обычно тут обнаруживается, что в проде ежедневно что-то падает и все привыкли.
4. Тикеты поддержки за квартал. Три часа, самое полезное вложение из списка. Боли живых людей, отсортированные по частоте. Заодно словарь: как пользователи называют то, что в коде зовётся иначе.
5. И только теперь сбор информации у людей. Хватит половины дня. Но сразу приходите с конкретными вопросами и наработками карты продукта.

Осторожно! Никогда не начинайте с разговоров. Человек описывает не систему, а свою модель системы: ту часть, с которой работал, в том виде, в каком запомнил. Придёте с картой и конкретикой – получите уточнения и опровержения. Придёте с пустым блокнотом – получите пересказ счастливого пути и уйдёте в уверенности, что всё поняли. 

Держите карту в вики в виде дерева на 1-2 страницы, чтобы она работала как общий актив: разработчик сможет проверить, не забыл ли админку, PM возьмёт для оценки объёма, новичок за час поймёт устройство продукта. Договоритесь о правиле: карта обновляется в том же PR, где меняется состав системы. Новый эндпоинт – строчка. Это единственный известный нам способ не дать документу устареть. 

Как перестать думать про покрытие и начать говорить о рисках?

Рано или поздно менеджер задаёт неприятный вопрос: какой у нас процент покрытия требований? На проекте без ТЗ честный ответ – знаменателя не существует. Но так отвечать нельзя, после этого разговор о качестве просто заканчивается.

Выход есть, и он лучше: говорить не о покрытии, а о рисках – какие из них мы сознательно принимаем, выпуская релиз в прод. Бизнес это понимает, потому что риски – это про деньги и последствия. Полного покрытия не бывает никогда: даже с идеальным ТЗ вы не проверите всё. Значит, вопрос всегда был не «покрыто или нет», а «чем именно мы решили рискнуть».

Метод называется RiskStorming. Собираете всю команду на час, обязательно с разработчиками – они знают, где тонко.

Каждое действие не больше 15 минут.

1. Каждый молча пишет, что может пойти не так с релизом. По пункту на стикер. Молчать принципиально, иначе первый заговоривший задаст настроение и рамку обсуждения.
2. Раскладываем по карте продукта. Обращайте внимание на перекосы: девять рисков на платежах, а на импорте прайсов ни одного? Это не потому что там безопасно, а потому что про импорт никто не подумал.
3. Раскладываем по двум осям: вероятность и ущерб, по квадрантам, без баллов и формул. Спор тут полезнее результата – команда впервые вслух проговаривает самые острые риски.
4. Решаем судьбу каждого: проверяем, автоматизируем, страхуемся флагом, мониторим в проде или принимаем.

Потом эти риски нужно перенести в таблицу – она станет основой протокола приёмки. Колонок пять: риск, оценка, что делаем, владелец, статус. Строк тоже около пяти, не сорок – иначе реестр не будет читать никто, включая того, кто его составил. Самая важная строка та, где в статусе стоит «принят»: в этот момент ответственность за решение переходит от тестировщика к бизнесу, причём письменно. Запись вида «вёрстка съезжает в браузерах старше двух лет, доля таких пользователей 0,4%, принимаем» – это полноценная строка реестра, и она закрывает вопрос навсегда. 

Что это даёт менеджеру? Разговор о том, почему баг ушёл в прод, превращается из поиска виноватого в сверку по списку. Либо риск был в реестре и его приняли – тогда обсуждаем, верным ли оказалось решение. Либо его там не было – тогда обсуждаем, почему команда его не увидела. Оба разговора продуктивны. А разговор в формате «кто пропустил» не продуктивен никогда.

Вывод

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

Помните, отсутствие ТЗ – это показатель пяти проблем, и каждая решается своим инструментом. Оракулы дают, с чем сравнивать. Карта продукта – что проверять. Реестр рисков заменяет бессмысленный разговор о покрытии тестами. В итоге вы приходите к заказчику не с жалобой на отсутствие требований, а с протоколом: вот критерии приёмки, вот риски, вот что приняли и т.д. Это позиция эксперта и профессионала.

Во второй части будет больше практики. Вы узнаете, как проводить Example Mapping, какие артефакты заводить, как выстроить три контура приёмки и вести журнал решений. Расскажем, на какие метрики смотреть без ТЗ и какие инструменты использовать. Следите за обновлениями!