Представьте два первых рабочих дня. На одном выдают документ на восемьдесят страниц про будущий интернет-магазин: «Читай, тестировать будешь в марте». На другом на второй день присылают сборку с новой кнопкой «Оплатить картой»: проверить к пятнице.
Работа называется одинаково, а выглядит по-разному: команды по-разному проходят одни и те же этапы разработки — требования, проектирование, код, проверка, релиз. Порядок и размер порций и называют моделью разработки; идеальной нет, есть подходящая проекту и договору. Разберём три модели на одном требовании: «покупатель оплачивает заказ картой; нажмёт кнопку второй раз — деньги не спишутся дважды».
Модель не меняет, сколько ошибок сделает команда. Она меняет, через сколько ошибку заметят, — а от этого зависит цена.
Waterfall: сначала описать всё, потом сделать всё
Заказчик хочет знать срок и цену до первой строки кода — значит, надо заранее договориться, что делаем, и описать это целиком. Дальше всё по очереди: весь дизайн, потом весь код, потом проверки, раньше проверять нечего. Этапы падают друг за другом, как вода по каскаду: отсюда водопад (waterfall).
Требование написали в январе, а продукта вы не видите до марта: читаете документ, разбираетесь в предметной области, пишете тест-кейсы по бумаге. Сборка приходит в марте — и только тогда видно, что «деньги не спишутся дважды» все поняли по-своему: аналитик имел в виду блокировку кнопки, разработчик — что второй платёж отклонит банк, а на деле два запроса уходят с разницей в секунду и оба проходят. В январе вопрос стоил бы пятнадцати минут разговора; в марте — правки требования, переделки кода, переписывания кейсов и повторной проверки всего рядом с оплатой.
Передумать в середине дорого: изменение идёт через формальное согласование — требование, дизайн, код, кейсы, сроки, смета; процедура намеренно небыстрая, ведь объём фиксировали заранее. Хоронить водопад рано: в авиации, медтехнике и банках регулятор или контракт требуют документ, где напротив каждого требования стоит доказавшая его проверка. Эту связку называют трассируемостью, и из неё выросла следующая модель.
V-модель: каждой стадии — своя проверка
Читая требование «покупатель может оплатить заказ картой», стоит сразу задать вопрос: а как я это проверю? Нет внятного ответа — требование сформулировано плохо, и видно это задолго до кода. V-модель делает вопрос обязательным на каждой стадии проекта.
По левой ветке буквы V проект спускается от общего к частному: пользовательские требования → системные → архитектура → детальный дизайн → код. По правой поднимается обратно через проверки, и каждой стадии слева отвечает проверка справа, придуманная в тот же момент, а не через полгода.
Верхняя пара: требованию «покупатель оплачивает заказ картой и получает подтверждение» отвечает приёмочная проверка — человек проходит путь от корзины до письма. Пока вы её формулируете в январе, вылезают вопросы: а если карта отклонена? а если нажали дважды? сколько ждать ответа банка? Три дырки в требовании — до первой строчки кода. Ниже масштаб меньше: системные требования ↔ системная проверка, архитектура ↔ интеграционная, детальный дизайн ↔ модульная; из этих четырёх пар выросли уровни тестирования.
Ваш проект почти наверняка не живёт по V-модели, но вопрос «как я это проверю» работает в любой — как задавать его системно, разобрано в статье про требования.
Итерации и инкременты: продукт по кусочкам
Обе предыдущие модели стоят на допущении, что требования известны заранее и не изменятся, — в жизни так редко: заказчик увидит первую работающую версию и половину придумает заново. Поэтому продукт чаще собирают заходами по две-три недели, каждый раз проходя весь цикл от требования до работающего куска.
Инкрементально значит, что заходы добавляют куски: в первом магазин учится принимать оплату картой, во втором появляются возвраты, в третьем — подписки; такой готовый к использованию кусок и называют инкрементом. Итеративно — про другое: половина покупателей не понимает экран подтверждения и бросает заказ, и в следующем заходе команда ничего не добавляет, а третий раз переделывает тот же экран. Итерация не обязана приносить новую функцию: иногда её результат — «то же самое, но теперь понятное».
Итог захода — сборка, она же билд: версия продукта на конкретный момент с номером вроде 1.4.17. Номер не украшение: «воспроизводится на 1.4.17, а на 1.4.18 уже нет» — разговор по делу, разработчик поймёт, в каких изменениях искать причину. Поэтому номер сборки входит в обязательные поля баг-репорта.
Agile — та же итеративная идея: вместо томов документации требование обсуждают втроём (аналитик, разработчик, тестировщик), а тестировщик сидит в команде, а не в отделе, куда «сдают» готовое; изнутри спринта это показано в отдельной статье.
Регресс, который растёт
В первом заходе вы проверяли одну оплату картой и успели за неделю. К четвёртому новая функция снова одна — подписки, — но их код трогает тот же платёжный модуль, и надо ещё убедиться, что вчерашние оплата и возвраты не сломались, а срок захода прежний, две недели.
Проверка того, что ранее работавшее продолжает работать, называется регрессом: его объём растёт с каждым инкрементом, а длина итерации не растёт никогда — продукт прибавляет в размере, календарь нет. Отсюда два ответа: наборы разделяют — быстрый smoke на пятнадцать минут отвечает «сборка живая, есть смысл тестировать?», полный регрессионный гоняют перед релизом (отдельная статья) — и повторяемые проверки автоматизируют. Разговор про автотесты в команде почти всегда начинается с растущего регресса, а не с любви к коду.
Как модель меняет вашу работу
Различия, которые чувствуешь руками, сводятся к трём вещам.
| Модель | Когда подключаетесь | Что получаете на вход | Куда уходит найденный баг |
|---|---|---|---|
| Waterfall | Во второй половине, когда собрана первая версия | Документ с требованиями, продукта нет | В общий список дефектов, чинят с оглядкой на срок сдачи |
| V-модель | С первой стадии, пока как планирование проверок | Требование и вопрос, чем его проверят | Часть находок — правки требований до кода, остальное как в водопаде |
| Итерации и Agile | В каждом заходе, непрерывно | Сборка с номером и задача на две-три недели | В доску захода, чаще всего чинится до его конца |
Тестирование двигается влево, к началу проекта: уезжает не прогон кейсов — выполнить проверку можно лишь на готовом коде, — а разбор требования и проектирование проверок.
Название модели говорит меньше, чем ритм: релиз раз в год-полтора — водопад, как бы его ни называли; раз в две недели — итерации; раз в квартал — гибрид. Гибрид и есть самая частая реальность: спринты по две недели, но релиз раз в квартал и две недели сплошного регресса перед ним. Это не «неправильный Agile», а компромисс: у выката своя цена — регламент, обучение операторов, согласование.
Коротко
- Модель не меняет, сколько ошибок сделает команда, — она меняет, сколько ошибка живёт незамеченной. Руками разница в трёх вещах: когда вас подключают, что дают на вход и куда уходит найденный баг.
- Водопад держится на том, что требования известны заранее; правка в середине тянет всю цепочку документов и идёт через формальное согласование.
- Урок V-модели переносится в любую модель: «как я это проверю» спрашивают при чтении требования, а не когда пришла сборка.
- В итерациях регресс растёт с каждым инкрементом, а срок захода нет; отсюда smoke- и регрессионные наборы и автоматизация.
- Номер сборки не формальность: без него баг-репорт теряет половину смысла, а спринты плюс квартальный релиз с регрессом в конце — самая частая реальность и осознанный компромисс.
Что почитать дальше
- Уровни тестирования — четыре уровня, выросшие из правой ветки V-модели.
- QA в Agile и Scrum — итерация изнутри: спринт, доска, место тестировщика.
- Основы автоматизации — куда упирается растущий регресс и что автоматизируют первым.
- Что такое тестирование — цена бага по этапам: во сколько обходится ошибка требований после релиза.