Это уже вторая часть цикла про тестирование без требований. Простым и понятным языком объясняем, как проверит то, что не до конца понимаешь. Напомним, в первой статье вы могли узнать, чем заменить ТЗ, как использовать оракулы, зачем составлять карту продукта и как выявлять зоны риска.
Сегодня рассмотрим практические инструменты. Давайте честно, все бы мы хотели конкретики, но проекты без ТЗ – привычная ситуация на рынке. Тестировать в таких условиях вполне реально: нужно только выстроить системный подход и не терять в качестве.
Сегодня рассмотрим практические инструменты. Давайте честно, все бы мы хотели конкретики, но проекты без ТЗ – привычная ситуация на рынке. Тестировать в таких условиях вполне реально: нужно только выстроить системный подход и не терять в качестве.
В статье мы делимся практиками, которые помогают справляться с самыми острыми проблемами. Рассказываем, как оперативно фиксировать требования, отслеживать прогресс без громоздкой документации и уберечь команду от лишних переделок. Покажем, как применять Example Mapping для быстрой фиксации правил, использовать сессии вместо устаревающих тест‑кейсов, выстраивать приемку в три контура и вести журнал решений (который будет играть роль памяти проекта). Даем понятные алгоритмы, которые можно сразу применять на практике.
План–перехват требований
Требования не прописаны, а решения каждый день принимают десятками. До тестировщика они просто не доходят в виде понятного текста. Нужны способы вовремя их перехватывать и фиксировать. Ловите эффективные техники.
Example Mapping: как за 25 минут вытащить скрытые правила и вопросы
Example Mapping – простая и очень полезная техника: всего 25 минут работы, четыре цвета карточек – и сразу видно, чего не хватает в задаче. Это метод Мэтта Уинна из команды Cucumber. Мы в компании его активно используем: четверть часа на старте здорово экономит время потом.
Собираем троих – продакта, разработчика и тестировщика (их еще называют «три амиго») – и раскладываем задачу по карточкам.
Все наглядно:
- Желтая карточка – это сама задача. Она всего одна на встречу: коротко и по делу.
- Синяя – правило работы функции. Например: «скидка не суммируется с промокодом». Обычно таких правил получается 3–7 штук, и нередко половину из них до этой встречи вообще никто вслух не формулировал.
- Зеленая – конкретный пример с цифрами. Например: «корзина 5000 ₽, промокод SALE20, статус „серебро“, итог 4000 ₽». Такой пример сразу становится готовым сценарием для теста.
- Красная – вопрос, на который прямо сейчас никто в комнате не знает ответа.
Особенно важны красные карточки. Если их больше трех – значит, задачу рано отдавать в разработку. Это видно сразу: карточки лежат перед глазами, спорить тут сложно. Такой подход помогает договориться еще до начала работ – даже там, где про формальные критерии готовности задачи не слышали.
По нашим данным, на типичную задачу выходит 4–6 правил, 8–12 примеров и 2–4 вопроса. И примерно каждый третий из этих вопросов – как раз тот, который иначе всплыл бы уже на демонстрации и обернулся бы серьезной переделкой.
Из практики: была задача по логистике – пересчитывать стоимость доставки при изменении состава заказа. Казалось, хватит 2 дней. Но на сессии Example Mapping всего за 20 минут выявили семь непроясненных моментов: заказ уже собран на складе, новая цена ниже предоплаченной, сменился тарифный пояс, клиент – юрлицо с постоплатой. В итоге оценку скорректировали до 9 дней. Это помогло не сорвать сроки: нужное время сразу заложили в план, а не столкнулись с нехваткой времени в конце спринта.
Выявление и проработка неоднозначностей с помощью слов–детекторов
Практику проверки на неоднозначность описала Элизабет Хендриксон в книге «Explore It!». В описании задачи часто прячутся непринятые решения – их можно заметить по определенным словам. Мы держим список таких слов на виду и быстро проверяем каждую задачу перед стартом – хватает 30 секунд. И вам советуем.
Правило 15 минут!
Если не понял требование – не гадай. Дай себе 15 минут, чтобы разобраться самому. Если ответа нет – сразу иди спрашивать. Звучит банально, но правило постоянно нарушают. Тестировщику бывает неловко задавать вопросы, и он строит свою гипотезу. Потом заводит по ней баг, а разработчик закрывает его как by design. В итоге обе стороны теряют по полдня. Неловкость уходит, если правило закреплено официально: у нас оно прямо прописано в договоренностях.
Сессии как единицы работы вместо тест‑кейсов
Тест‑кейс плохо справляется с изменениями: он фиксирует конкретные шаги для конкретного поведения системы. Стоит поведению поменяться – и кейс становится бесполезным. В проектах, где продукт обновляется каждую неделю, на поддержку тест‑кейсов уходит больше времени, чем на само тестирование. Знакомая ситуация: есть 180 кейсов, из них реально работают примерно 70, но никто точно не знает, какие именно.
Альтернативу предложил Джонатан Бах еще в 2000 году – это Session‑Based Test Management. Здесь основная единица работы – сессия: отрезок времени с четкой целью и отчетом по итогам.
Краткость чартера – залог эффективности
Чартер – это всего одна строка. Он должен быть коротким: это не план тестирования, а четкая формулировка задачи. По сути, это ответ на три вопроса: что исследуем, с помощью чего и что хотим найти. Хороший чартер отличается от слабого тем, что в нем есть гипотеза – предположение, где может быть ошибка.
# Плохие чартеры (так делали мы первые полгода) Протестировать корзину ← это не цель, это область Проверить, что всё работает ← непроверяемо Регресс личного кабинета ← на 8 часов? на 3 дня? # Рабочие чартеры Исследовать пересчёт корзины при изменении из двух вкладок сразу, чтобы найти рассинхрон итоговой суммы и состава Исследовать оформление заказа при медленном ответе шлюза (задержка 3–10 с), чтобы найти двойные списания
Берутся чартеры из реестра рисков: каждый риск верхних квадрантов превращается в один-два. Цепочка получается прозрачная и объяснимая заказчику: риск → чартер → сессия → отчёт → строка в протоколе приёмки. При этом кейсы никуда не деваются — здоровая пропорция на проекте без ТЗ примерно такая: 15–25% работы в жёстких проверках критичных потоков, остальное сессии.
Чартеры берут из реестра рисков: каждый значимый риск превращается в один‑два чартера. Цепочка получается понятной и прозрачной для заказчика: от риска – к чартеру, от чартера – к сессии, потом – к отчету и строке в протоколе приемки.
При этом тест‑кейсы остаются в работе. На проекте без ТЗ разумно держать такую пропорцию: 15–25 % усилий – на жесткие проверки самых критичных потоков, остальное – на исследовательские сессии.
Когда все‑таки нужны тест‑кейсы (критерии выбора)
Принцип, который способен здорово упорядочить работу: артефакт должен жить не дольше, чем то, что он описывает. Если функцию переделывают каждые две недели, подробный тест‑кейс на нее – просто потраченные время и деньги. А вот модуль расчета НДС не меняется годами – пока не поменяется налоговый кодекс. Тут можно смело писать автотест и не переживать.
Поэтому советуем сортировать задачи по сроку годности: что быстро устаревает – тестируем гибко, что стабильно – автоматизируем.
Отдельно про легаси: характеризующие тесты
Когда кажется, что «знание утеряно», помогает прием Майкла Физерса из книги «Эффективная работа с унаследованным кодом». Смысл в том, чтобы зафиксировать, как система работает в моменте, – так проще будет заметить, если поведение незаметно изменится в будущем.
Берем тысячу обезличенных запросов с продакшена, прогоняем через текущую версию и сохраняем ответы как эталон. Потом с каждой правкой кода снова прогоняем ту же тысячу. Если есть расхождение – значит, либо баг, либо осознанная правка. В любом случае вы узнаете об этом до релиза, а не от клиента. Это подход из семейства approval testing.
Для интеграций есть похожий вариант – контрактное тестирование. Если сервисов много, а описания их взаимодействия нет, контракты собирают из реального трафика – и дальше они работают как техзадание на стыках. Так мы в своей практике восстанавливали правила взаимодействия там, где все описание хранилось в одном чате разработчиков – еще с 2021 года.
Из практики.
Работали с системой расчета комиссий. Представьте восемь лет разработки, три поколения авторов, а документации нет совсем. Задача стояла простая: добавить новый тип комиссии и ничего не сломать. При этом в компании никто не мог даже перечислить существующие типы. Взяли выгрузку за квартал – 240 000 расчетов, – прогнали через текущую версию и сохранили как эталон. При первой же правке всплыло расхождение в 1,8% случаев: оказалось, пересекались старая акция и округление вниз. Ошибка жила в проде четыре года и стоила 3,2 млн рублей недоплаченных комиссий. Нашли ее не люди, а простое сравнение системы с самой собой.
Приемка в три контура
Дошли до главного: все, о чем говорили раньше, нужно, чтобы приемка перестала быть сюрпризом (и чаще всего неприятным). Обычно бывает так: в конце спринта показывают результат, а заказчик говорит, что ожидал другого результата. Начинается непростой разговор. Виноватых нет – просто ожидания нигде не зафиксировали. Через две недели ситуация повторяется.
Проблема в том, что приемка – это единственная точка контроля. А требования меняются постоянно, значит, и сверять их нужно непрерывно. Поэтому предлагаем использовать три контура проверки – с разной частотой и разной ценой возможной ошибки.
Что проверить до начала работ?
На меняющихся проектах полноценный Definition of Ready часто не работает: он либо превращается в формальность, либо тормозит работу. Мы упростили подход и оставили всего три вопроса, на которых нужно ответить до старта. Если ответов нет – не берем задачу в работу.
## Три вопроса готовности задачи 1. Зачем. Что изменится для пользователя или бизнеса, когда это заработает? Одно предложение. Не «сделать форму», а «клиент оплатит без звонка менеджеру». 2. Как поймём, что получилось. Один пример с конкретными данными, где видно, что задача решена. Не критерии приёмки. Один пример. С цифрами. 3. Что точно не входит. Какие смежные случаи мы сознательно не делаем в этой задаче? Самый недооценённый вопрос: снимает половину споров на приёмке.
Протокол приемки, который способен поменять все
Обычный отчет о тестировании отвечает на простой вопрос: «Нашли ли мы баги?» Но он мало что дает – не показывает, чего мы еще не знаем. Протокол приемки решает другую задачу: он помогает понять, на что можно опираться, когда решаешь, выпускать ли релиз. В нем обязательно есть раздел про то, что не успели или не смогли проверить.
ПРОТОКОЛ ПРИЁМКИ · Релиз 2.14 · 12.03 1. ЧТО ПРОВЕРЕНО Оформление заказа с оплатой картой ... 4 сессии, 6 ч Пересчёт корзины ..................... 2 сессии, 3 ч Регрессионный чек-лист ............... 62 пункта, пройден 2. РИСКИ ИЗ РЕЕСТРА Закрыто проверками ... 6 из 10 Передано в мониторинг ... 2 Принято бизнесом без проверки ... 2 (см. п. 4) 3. ЧТО НЕ ПРОВЕРЯЛОСЬ ← раздел, ради которого всё затевалось Мобильные браузеры старше двух лет — нет устройств на стенде Импорт файлов свыше 50 МБ — нет тестовых данных нужного объёма Больше 200 одновременных пользователей — нет нагрузочного стенда Отмена после частичной отгрузки — не успели, риск средний 4. ПРИНЯТЫЕ РИСКИ ← подписывает бизнес, не QA Вёрстка в браузерах старше двух лет (0,4% аудитории) — принял: П. (продукт) Отчёт «Остатки» грузится 40 с на крупных клиентах — принял: П. (продукт) 5. РЕКОМЕНДАЦИЯ Выпускать на 10% трафика, флаг new_checkout, наблюдение 24 ч.
Решение о релизе больше не зависит от эмоций. Не будет фраз вроде «вроде все нормально» – вместо этого есть четкая картина: вот что проверили, вот что проверить не успели, какие риски осознанно приняли и кто это подтвердил. Если потом что‑то сломается, у вас будет документ, который показывает: решение принимали, зная про все слабые места. А тестировщику такая прозрачность помогает защититься от упреков «почему не нашли»: все, что было известно, уже зафиксировано.
Журнал решений: как не терять контекст в условиях постоянных изменений
Отдельная беда проектов без ТЗ – всеобщая амнезия. Договорились на созвоне, все кивнули, через месяц никто не помнит. Хуже – помнят по–разному, причем каждый искренне.
Лечится журналом решений. Идея заимствована у разработчиков, у них это Architecture Decision Records; то же самое, только про продуктовые договоренности. Формат – пять строк, больше никто вести не будет. Наш первый шаблон имел пятнадцать полей, и поэтому прожил всего три недели.
#47 · 14.02 · Промокод и статус лояльности Вопрос: Суммируются ли скидка по промокоду и скидка за статус? Решение: Не суммируются, применяется большая из двух. Принял: Марина (владелец продукта), созвон 14.02 Причина: Суммарная скидка выше 25% уводит заказ в минус Следствие: Чартер C-12 переписан, обновлены 4 автотеста корзины, на баннере акции нужна сноска — задача PROD-882.
Где вести журнал – не так важно: подойдет вики, задача в трекере или закрепленное сообщение. Главное – соблюдать правило 24 часов: решение нужно зафиксировать в тот же рабочий день, а не откладывать на потом.
Никаких лишних статусов, виз и уведомлений: если запись начинает занимать больше минуты – журнал быстро перестают вести. Жесткий срок не просто так: мы полгода замеряли, сколько стоит восстановление забытой договоренности – и цифры убеждают лучше любых слов.
Замеры на одном проекте за шесть месяцев, 84 случая. Абсолютные цифры у вас будут свои, форма кривой та же.
Самое важное из второй части
На проектах без ТЗ главная проблема – не в нехватке тестов, а в том, что договоренности быстро забываются, ожидания у всех разные, а ошибки всплывают уже на демонстрации. Чтобы этого не случалось, нужно фиксировать самое важное – быстро и просто. Например, с помощью Example Mapping за 20–25 минут можно вытащить скрытые правила и пробелы в задаче, а короткий журнал решений (всего пять строк) поможет не потерять принятые договоренности – главное, записывать их в тот же день.
Гибкость в тестировании дают сессии и чартеры: они позволяют адаптироваться к постоянным изменениям, не тратя время на поддержку устаревших тест‑кейсов. При этом стабильные участки системы – например, модули с жесткими правилами расчета – стоит покрывать автотестами: артефакт должен жить не дольше, чем то, что он описывает. Для старых систем отлично работают характеризующие тесты: они сохраняют эталон поведения и сразу показывают, если что‑то изменилось.
Прозрачность приемки обеспечивают три контура контроля и понятный протокол, где четко видно, что проверили, а что осталось за рамками. Так решение о релизе перестает быть эмоциональным, менеджер видит реальную картину рисков, а тестировщик получает защиту от упреков – и все это без лишней бюрократии.
Устали от меняющихся требований и сюрпризов на приемке? Свяжитесь с нами. Поможем навести порядок – без горы документов и лишней бюрократии. В нашей команде – тестировщики, которые умеют работать гибко, без ТЗ и устойчивых требований. Они не просто закрывают задачи, а помогают разобраться: находят скрытые правила, фиксируют договоренности и выстраивают понятные QA–процессы. И это не разовая помощь: с вами поделятся экспертизой – сможете и дальше держать ситуацию под контролем. Начните с бесплатной консультации – всего 30 минут, чтобы увидеть, как превратить хаос в понятные шаги и первые точки роста. Напишите нам прямо сейчас и подберем удобное время.
Тренды и фишки из мира IT,
экспертные статьи и всё о тестировании.
