Пять моделей, которые спрашивают на собеседовании, и Agile-манифест целиком. Для каждой модели – не пересказ схемы, а ответ на вопрос "что это меняет лично для тестировщика". Ниже есть подбор модели под проект.
Строгая последовательность. Фаза закрывается, документ подписывается, дальше её не трогают. Модель держится на допущении, что требования известны заранее и верны.
Схему в 1970 году нарисовал Уинстон Ройс в статье о разработке больших систем. Слова "водопад" там нет, а линейную схему Ройс привёл как рискованную и тут же предложил её чинить: прогонять цикл дважды и добавить обратные связи. Разошлась модель без этих оговорок. В армейском стандарте США DOD-STD-2167A (1988) водопад стал фактически обязательным, а сменивший его MIL-STD-498 (1994) итеративность уже разрешил.
В чистом виде почти нигде. Остаётся там, где заказчик покупает результат по фиксированному ТЗ: госконтракты, тендеры, аутсорс с fixed price. Часто "у нас водопад" на деле означает V-модель или итерации с тяжёлой документацией.
Ты подключаешься последним, когда код уже написан. Дефект требования, внесённый в январе, находится в июне и стоит в разы дороже. Твою фазу режут первой: разработка съедает буфер, а дата релиза не двигается.
| Документ слева | Уровень тестов справа | Что проверяем |
|---|---|---|
| Требования бизнеса и заказчика | Приёмочное (UAT) | Тот ли продукт сделали, решает ли он задачу заказчика |
| Системные требования | Системное | Система целиком делает то, что записано в спецификации |
| Архитектура (high-level design) | Интеграционное | Модули и внешние сервисы стыкуются так, как задумано |
| Дизайн модулей (detailed design) | Модульное (unit) | Отдельная функция или класс работает по своей спецификации |
Тестирование не фаза, а вторая половина каждого шага. Пишешь системные требования – тут же пишешь системные тесты. Пока кода нет, тесты уже спроектированы, и они же служат проверкой самих требований: невозможно придумать тест на требование "система должна быть удобной".
Левая ветвь – верификация: делаем ли продукт правильно, соответствует ли реализация документу. Правая ветвь – валидация: тот ли продукт делаем, нужен ли он заказчику. Пара "требования заказчика ↔ приёмочное" отвечает как раз за валидацию.
Медтехника, авиация, автомобильный софт, железнодорожная автоматика, банки под надзором регулятора. Причина одна: нужно доказать документом, что каждое требование покрыто проверкой. Отсюда же растёт матрица трассируемости.
Ты нужен с первого дня и читаешь требования как исходник тест-кейсов. Противоречие, найденное в спецификации, стоит копейки, то же противоречие в проде – десятки тысяч. Минус остаётся водопадный: требования заморожены, и если они меняются, переделывать надо обе ветви V.
Продукт растёт кусками. Внутри итерации проходят все те же работы, что в водопаде, только за две-шесть недель и на маленьком объёме. К концу итерации есть что показать и что потрогать.
Инкремент – это новый кусок к тому, что уже есть: был вход, добавили каталог. Итерация – возврат к сделанному, чтобы сделать его точнее: тот же каталог переписали после отзывов. На практике работают обе оси сразу, поэтому модель и называют двойным словом.
Основа всего современного. Классический пример реализации – RUP с фазами Inception, Elaboration, Construction, Transition. Agile-фреймворки тоже стоят на итерациях, только добавляют к ним свой набор ценностей и правил.
С каждой итерацией регресс растёт, а срок итерации не растёт. К четвёртой-пятой ручной прогон уже не влезает. Поэтому автоматизация тут не "когда будет время", а часть плана со второй итерации. Второй риск: без внятного критерия готовности инкремент превращается в "почти работает", и его тащат в следующую итерацию.
Дорогое решение принимают только после того, как проверили риск. Каждый виток начинается с целей и обязательного анализа рисков: что может убить проект и как это выяснить дёшево, до того как в код вложат полгода.
Порядок витков задаёт не бэклог фич, а список рисков, отсортированный по цене. Прототип – штатный артефакт, и его нормально выбросить: он был ответом на вопрос, а не куском продукта.
R&D, новая технология, большие системы с дорогой архитектурой. Модель тяжёлая: каждый виток – это ещё и аналитика рисков, и прототип в мусор. Маленькому проекту такое не окупится.
Ты участвуешь в анализе рисков наравне с архитектором: у тебя лучше всех видно, где система ломается. Тестируешь прототипы, которые пойдут в корзину, и цель тут не список багов, а ответ на конкретный вопрос: держит ли эта схема нагрузку, стыкуется ли этот протокол.
Четыре ценности и двенадцать принципов – весь документ. Ни ролей, ни встреч, ни артефактов там нет: их приносят фреймворки. Отсюда и путаница на собеседованиях, когда Agile называют то методологией, то синонимом Scrum.
Отдельной фазы тестирования нет. Есть Definition of Done, внутри которого проверка уже учтена: не проверено – значит, не сделано. Требования живут в user story и уточняются на груминге, там же ловятся дыры. Регресс приходится автоматизировать: вручную двухнедельный цикл не закрыть.
Формулировки из официального русского перевода манифеста.
Официальные формулировки, серым – что каждый принцип означает для твоей работы.
Четыре вопроса, по которым модель выбирают на практике. Отвечай про реальный проект, а не про идеальный. Результат – модель, разбор, почему так, и что это значит для твоей работы.
Модели различаются не схемой на слайде, а ответами на эти шесть вопросов. Подбор выше подсвечивает в таблице свою строку.
| Модель | Требования | Когда подключается тестировщик | Цикл обратной связи | Цена изменения | Документация | Где встречается |
|---|---|---|---|---|---|---|
| Водопад | Заморожены до старта | В самом конце, после кода | Один раз, на приёмке | Запретительная | Тяжёлая, подписывается | Госконтракты и тендеры по фиксированному ТЗ |
| V-модель | Заморожены, но проверяются рано | С фазы требований, пишет тесты параллельно | На каждом уровне тестов | Высокая | Тяжёлая, обязательна для регулятора | Медтехника, авиация, авто, банки |
| Итеративная | Уточняются между итерациями | Внутри каждой итерации | Раз в итерацию, недели | Средняя | Умеренная | Крупные долгие продукты, RUP |
| Спиральная | Уточняются по мере снятия рисков | С анализа рисков и прототипов | Раз в виток | Средняя, риск оплачен заранее | Много аналитики рисков | R&D, новые технологии, дорогая архитектура |
| Agile | Живут в бэклоге и меняются всегда | С первого дня, проверка внутри Definition of Done | Каждые одну-две недели или чаще | Низкая, в этом и смысл | Минимально достаточная | Продуктовые команды, веб, мобильные приложения |