Какая методология используется в вашем проекте?
Если вы тестировщик, важно понимать, на каком этапе вы подключаетесь к работе, будет ли у вас документация и как строится процесс в целом. Как известно, разработка программного обеспечения (далее — ПО) может осуществляться на основании различных методологий и у каждой имеются свои особенности. Но нас, тестировщиков, в первую очередь интересует процесс тестирования в каждой из методологий. Итак, рассмотрим этот вопрос подробнее для наиболее известных из них.
Основные методологии (модели) жизненного цикла разработки ПО:
1. Водопадная или каскадная
2. V-модель
3. Модель прототипа
4. Итеративно-инкрементная модель
5. Спиральная модель
6. Модель большого взрыва
7. Гибкая модель
Сегодня разберём традиционные модели разработки, где процесс строго регламентирован, а тестирование чаще всего — отдельный этап. И покажем, как в каждой из них выстраивается работа тестировщика.
Водопадная или каскадная
Модель предполагает, что сроки и затраты на разработку ПО заранее определены и не могут быть изменены. Все этапы модели выполняются последовательно и не налагаются друг друга. Мы не сможем начать тестирование, пока полностью не будут завершены предшествующие этапы: сбор и анализ требований, проектирование, разработка.
📍 Данная модель может применяться при разработке медицинского, военного, финансового ПО, т.е. в таких проектах, где требования к функциональности, безопасности и точности являются критическими и их последующее изменение не предусматривается. Модель может применяться и при создании отдельной функциональности в рамках разработки ПО по иным моделям или для небольших проектов.
Тестирование является отдельным этапом модели. Оно фактически начинается с середины развития проекта, это касается и изучения спецификаций, подготовки тестовой документации и т.п.
Так как на первоначальном этапе документация проекта прорабатывается весьма детально, то отдельного её тестирование не проводится. После завершения тестирования к нему уже не возвращаются.
V-модель
Суть модели — разработка ПО через тестирование, т.е. сначала пишется тест, который будет проверять код, а затем пишется сам код. Основа модели — V-диаграмма, где левая сторона является этапом верификации, а правая — этапом валидации.
Тестирование в данной модели осуществляется на протяжении всего жизненного цикла разработки и им занимаются как разработчики, так тестировщики.
Стадия сбора и анализа требований этапа верификации коррелирует со стадией приемочного тестирования этапа валидации. Здесь тестировщики согласовывают критерии приемки, определяют пользовательские сценарии, проводят тестирование документации и т.п.
Стадия системного дизайна этапа верификации коррелирует со стадией системного тестирования этапа валидации. На этой стадии мы начинаем готовить необходимую для тестирования документацию, осуществляем проверку прототипов и т.п.
Стадия высокоуровневого и низкоуровневого дизайна этапа верификации коррелирует со стадией интеграционного и юнит-тестирования (unit testing) этапа валидации соответственно. На данной стадии разработчики начинают писать юнит-тесты.
В юнит-тестировании проверки осуществляются только разработчиками, где ими проверяется работа минимально неделимой единицы функциональности (например, модуль, единица измерения или класс в коде). Тестировщики на предыдущем и данном этапе шлифуют тестовую документацию, создают тестовые случаи.
На этапе интеграционного тестирования проверки, в зависимости от проекта, проводятся как разработчиками, так и тестировщиками. На данной стадии мы проверяем, что функциональности, которые были протестированы отдельно, могут быть объединены и корректно взаимодействовать в связке друг с другом.
А вот на стадии системного тестирования проверяется весь функционал ПО на предмет его соответствия требованиям и ожиданиям заказчика.
Завершающим является приемочное тестирование, которое проводится, как правило, в реальной среде предполагаемыми конечными пользователями либо самим заказчиком (исходя из моей практики на данном этапе проводятся в основном позитивные тесты).
| Этап верификации | Этап валидации |
| Анализ требований | Приемочное тестирование |
| Системный дизайн | Системное тестирование |
| Высокоуровневый дизайн | Интеграционное тестирование |
| Низкоуровневый дизайн | Юнит-тестирование |
📍 Данная модель характерна для компаний, занимающихся разработкой ПО для автомобильных систем управления, где необходимо обеспечение тщательного тестирования на каждом этапе разработки.
Такие известные компании как Siemens AG (использует V-модель в своих индустриальных и медицинских проектах) и Bosch GmbH (используют модель в разработке автомобильного ПО).
Модель прототипа
Суть метода — изначально создается прототип, который используется в качестве требования для создания фактического ПО, оно же далее тестируется, как правило, с использованием водопадной (каскадной) модели. То есть основная разработка идёт по водопадной модели, но фокус сначала на визуализации идей, а не на документации.
📍 Яркими сторонниками такой модели являются компании Apple, Tesla, Electronic Arts (там, где важно «пощупать» продукт до финала) известные своим подходом к прототипированию в своей разработке устройств.
Итеративно-инкрементная модель
Данная модель предполагает выпуск на первом этапе MVP в базовой функциональности. А затем уже в продукт в рамках итераций добавляются новые небольшие и легко создаваемые дополнения — инкременты.
Итераций может быть неограниченно много, и в каждой из них будет своя фаза тестирования, где мы тестируем работоспособность добавленного нового инкремента. Проведение регрессионного тестирования также предусматривается, но не в каждой итерации. Тестовая документация составляется по мере загруженности тестировщиков. Если коротко:
- В каждой итерации тестируем новый функционал.
- Регресс — по необходимости (не в каждой итерации).
- Документация пишется, если хватает времени.
📍 Пример тут простой. Берем операционную систему Windows в её изначальном варианте. Это MVP. Дальнейшие обновления — это протестированные инкременты или новые версии, которые добавляют новые фичи в систему.
Вывод
Как видим, в разных методологиях тестирование встраивается на разных этапах и в разном объёме.
Но главное — оно есть всегда. Без тестирования не бывает уверенности в продукте.
Тестирование:
- помогает избежать ошибок ещё на ранних этапах;
- экономит деньги и время;
- повышает качество, а значит — доверие пользователей;
- защищает интересы как конечных пользователей, так и бизнеса.
По сути, тестировщики — это последняя линия обороны.
Если мы не пропустим баг — его не увидит и клиент. А значит, продукт станет крепче, а команда — сильнее. Традиционные модели дают структуру и предсказуемость. Они подходят для крупных и ответственных проектов, когда ошибка может дорого стоить. Но в реальной жизни всё чаще используются гибкие модели, где важно быстро реагировать на изменения и не тратить полгода на согласование документации. Об этом поговорим во второй части в следующий вторник.
