Вот и пришло время опубликовать третью часть цикла о тестировании без требований. Мы уже рассказали об оракулах, карте продукта и риск-ориентированном подходе в первой части и дали конкретные QA-практики во второй.
Теперь поговорим о метриках, российской специфике и плане наведения порядка в QA-процессах за 90 дней. Пристегните ремни, приступаем! Полезно тестировщикам, техлидам и продакт-менеджерам, которые работают на проектах без чётких требований и ТЗ.
На какие метрики опираться?
Трудно измерять то, что не прописано в ТЗ. Привычные способы здесь не работают. Процент покрытия требований посчитать нельзя, количество тест-кейсов не показывает ничего, кроме усердия QA-инженеров, а число найденных багов двусмысленно: их много, потому что тестировщики хорошие или потому что разработка плохая? Мы предлагаем остановиться на 5 честных показателях – всего 30 минут в неделю на сбор и вы получите качественные данные для управленческих решений.
Практика. Про первую метрику хочется сказать отдельно: нам она буквально перевернула приоритеты. Полгода классификации багов на 4 проектах дали среднюю картину – 34% дефектов возникали из-за неправильно понятого требования. Треть работы обеих команд уходила на исправление недоговоренностей. Это поменяло расчет вложений в тестирование, так как автоматизация не уменьшала эти 34% ошибок, а только проверяла реализацию того же непонятого требования. Нашли проблему с Example Mapping за 20 минут. После трёх месяцев работы первого контура доля таких дефектов упала до 12–15%.
Стек в российских реалиях
Обратите внимание, от выбора инструментов все описанное почти не зависит, так как живет в вики, таблице и трекере. Но если инструмент неудобный, то команда перестает им пользоваться и процесс постепенно умирает. Так что постоянно мониторьте рынок на новинки и больше смотрите на функционал, а не на названия.
Кейс: миграция биллинга без актуальных требований и нормального ТЗ
Кейс обезличен (NDA): региональный телеком-оператор, миграция биллинга, 11 месяцев работы.
Ситуация
Заказчик готовился к переезду со старой биллинговой системы, которая работала уже 11 лет, на новую. Подрядчик, создавший первоначальную архитектуру, уже не существовал. Документация состояла из 4 томов 2014 года про систему, с тех пор изменившуюся до неузнаваемости. Людей, помнящих логику, осталось всего двое, но оба уже работали в других департаментах. Требование к проекту было написано одной строкой: «Абонент не должен заметить перехода». За ним стояли 340 тысяч абонентов, 60 тарифов, 14 акций и 11 лет истории начислений с перерасчетами и ручными корректировками.
Что мы предприняли?
Первые два месяца были в режиме Шерлока Холмса: аналитики восстанавливали требования по документам и интервью. Описали 40% тарифной логики, наткнулись на противоречие – и выяснили, что описание расходится с реальностью примерно в каждом пятом случае.
Люди помнили, как задумывалось, а не как получилось после 11 лет правок. Сроки переехали на квартал, подход пришлось менять целиком.
- Сменили диагноз. Начали с утерянных знаний, а лечили чуть другим способом. Эталоном объявили поведение старой системы, а не представления о нем.
- Построили карту продукта по SFDIPOT за 9 дней. Нашли 11 фоновых задач, о которых не знал никто из действующих сотрудников. Например, одна ежемесячно корректировала начисления 900 корпоративным клиентам.
- Собрали дифференциальный стенд. Обе системы получали один поток обезличенных событий за реальный месяц – 47 млн триггеров тарификации. Результаты сравнивались автоматически. Расхождения раскладывали на три корзины: ошибка новой системы, ошибка старой, сознательное изменение. Третья корзина и стала тем документом требований, который не получалось написать заранее.
- Ввели журнал решений. 214 записей для решений, воспроизводим то или иное поведение или исправляем. Журнал позже стал документацией к новой системе.
- Приемку сделали в 9 волн: 200 абонентов на простейшем тарифе, потом 5000, потом сегмент за сегментом. После каждой – сверка начислений.
Результат
Миграция заняла 11 месяцев вместо плановых восьми. Но план строился на основе фантазий о том, что требования можно восстановить всего за два месяца. От смены подхода до финала прошло 9 месяцев без сдвигов. Нашли 1 847 расхождений, из них 1 203 оказались ошибками старой системы, которые годами никто не замечал. Жалоб на начисления за первый месяц – 34 при прогнозе в несколько тысяч.
Из этого делаем вывод, что вся соль не в инструментах. Первые два месяца мы потратили на то, чтобы добыть хоть какие-то данные и документы о старой системе. Отсутствие требований перестает быть проблемой в тот момент, когда вы находите другой источник истины и решаете считать главным именно его.
План внедрения QA-стратегии на проектах без требований на 90 дней
Если вы прочитали все это и подумали, что звучит разумно, но воплощать в жизнь некогда, так как релизы и без того горят – вот последовательность, проверенная на нескольких командах. Обратите внимание, порядок важен. Не нужно перепрыгивать с одного этапа на другой, если хотите сделать все четко и без потери времени.
|
Месяц 1 · Видимость
Ничего не ломаем, только смотрим
Поставить диагноз (раздел 1)
Собрать карту продукта
Начать журнал решений
Размечать баги по первопричине
Результат месяца:
знаете, из чего состоит продукт и откуда берутся дефекты
|
Месяц 2 · Контур входа
Самая высокая отдача на вложение
Три вопроса на каждой задаче
Example Mapping на сложных
Первый RiskStorming на релиз
Показ заказчику раз в 2–3 дня
Результат месяца:
доля дефектов из-за требований падает вдвое
|
Месяц 3 · Форма и защита
Закрепляем и защищаем от отката
Перейти на чартеры и сессии
Ввести протокол приёмки
Фича-флаги на рискованное
Автотесты на стабильное ядро
Результат месяца:
решение о релизе принимается по документу, а не по ощущениям
|
Отдельно про то, как преподнести план команде
Не называйте это методологией, чтобы не вызвать сопротивление. Мы начинали с малого, в стиле «давайте месяц помечать баги по типам причин, интересно же». Это было в легкой непринужденной форме, и через месяц цифры сказали все сами.
Внедряйте первым то, что снимает боль команды, а не вашу. Разработчиков мучают переделки – начинайте с контура входа, и вас поддержат. Бесполезно проводить для всей команды обучающий воркшоп на полдня. У нас не сработало ни разу: люди кивают, а в понедельник работают как раньше. Лучше показывайте на своем примере: делаете задачу и демонстрируете результат. А заодно показываете, как это вам удалось. Обучение происходит органически.
Распространённые ошибки в QA без ТЗ
Четыре ошибки, с которыми сталкиваются почти все. Предупрежден — значит вооружен.
- Отказ приступать к работе без ТЗ – после такой позиции вас перестают звать на ранние обсуждения.
- Тест-кейсы на все подряд: через два месяца их 300, актуальны 100, и все пятницы уходят на выяснение, какие именно действительно нужны.
- Автоматизация первым ходом – на меняющемся продукте UI-автотесты дают обходится очень дорого при сомнительной пользе.
- Баги на все, что не нравится: без ТЗ граница между багом и сомнительным моментом, о котором просто не договорились — размыта. Спорное заводите вопросом в журнал решений.
Теперь важные оговорки
Первая: все описанное не заменяет документацию. Если есть возможность иметь нормальные требования – это надежнее и дешевле. Речь о ситуации, где такой возможности нет, и встречается она чаще, чем принято признавать на конференциях и в профессиональной среде.
Вторая: подход требует QA-инженеров высокого уровня. Прогнать 200 тест-кейсов может человек после двухмесячных курсов. Провести сессию по чартеру, задать правильные вопросы на Example Mapping и понять, что мелочь на экране – это симптом крупной проблемы, может только человек с опытом и знанием предметной области. Если ваша стратегия – набирать джунов на поток и давать им сценарии, то эта методология не подойдет.
И самое важное. Смена подхода здесь про переговорную позицию, а не про шаблоны. Пока тестировщики рассказывают, чего ему не хватает для работы, они находятся в роли жалобщиков. Как только они приносят документ со словами «вот на что мы опирались, вот что проверяли, вот что осталось за бортом, вот риски», то оказывается единственными в проекте, кто видит картину целиком. Отсутствие ТЗ этому не мешает. В некоторых случаях даже помогает.
Нужна помощь с тестированием, когда требований недостаточно? На бесплатной консультации разберем вашу ситуацию, определим основные риски и поможем определиться с первыми шагами к системному тестированию.
Что ещё почитать по теме?
- James Bach, Heuristic Test Strategy Model – SFDIPOT и эвристики Rapid Software Testing. Michael Bolton, FEW HICCUPPS – оракулы с разбором каждого.
- Jonathan Bach, Session-Based Test Management (2000) — сессии, чартеры, метрики T/B/S. Matt Wynne, Introducing Example Mapping.
- ISO/IEC 25010:2023 – модель качества продукта, в редакции 2023 года девять характеристик; годится как чек-лист забытых аспектов.
Тренды и фишки из мира IT,
экспертные статьи и всё о тестировании.
