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