QA-специалист работает с разными подходами и моделями разработки программного обеспечения. Иногда приходится иметь дело с V-моделью. Давайте посмотрим, что она из себя представляет с точки зрения тестирования.
Тестирование в V-модели разработки
Quality Assurance и V-модель
V-модель – это такой подход в тестировании, когда определенная фаза тестирования реализуется параллельно с соответствующей фазой написания кода. Исторически она возникла после каскадной модели «Водопад», в которой тестирование происходит уже после программирования. Иногда V-модель называют моделью верификации или валидации.
История создания V-модели
Более того, если разрабатывалась сложная система ПО, то можно было упустить важные нюансы еще на этапе требований. Тогда в результате мог получаться IT-продукт, который не соответствовал пожеланиям клиента, и приходилось начинать все сначала.
В ответ на эти вызовы и была разработана V-модель. Ее версии создали в 1980-х годах независимо друг от друга немецкая аэрокосмическая фирма IABG и Национальный совет США по системной инженерии для спутниковых систем (модель VEE). Современной версией считается V-Model XT 2005 года.
Как работает V-модель
V-модель предусматривает вначале постепенную детализацию требований и дизайна: сначала общесистемного уровня, затем интеграционного и, наконец, модульного. Затем производится разработка (кодинг). И после этого начинается тестирование по уровням, причем в обратной последовательности: модульное интеграционное, системное.
Это отображается на схеме V-модели: горизонтальные линии между двумя сторонами «буквы V» визуализируют, как этапы тестирования связаны с аналогичными этапами анализа требований и дизайна.
Главные правила V-модели
- Детализация требований и дизайна ПО возрастает по ходу проекта и не может вернуться обратно.
- Новые версии ПО возникают в результате отладок по «горизонталям» между соответствующими фазами левой и правой сторон «буквы».
- Модель позволяет разбить IT-проект на отдельные шаги, для каждого из которых можно разработать план мероприятий, инструкции и рекомендации.
- Приветствуется участие пользователей в реализации V-модели.
- В сложных проектах для контроля за вносимыми изменениями можно создать проектную комиссию по урегулированию преобразований.
Тестирование в V-модели
Тестирование в данной модели зависит от этапа.
- Модульное тестирование (Unit-тестирование) – сконцентрировано на проверке корректной работы каждого определенного модуля. Планы такого тестирования создаются на этапе Low Level проектирования. Оно может охватывать как функциональное, так и не функциональное тестирование (потребление ресурсов, время отклика, юзабилити и др.)
- Интеграционное тестирование – проводится для проверки взаимодействия модулей. Они должны работать так, как было предусмотрено на этапе верхнеуровневого (High Level) проектирования. Интеграционное тестирование изучает интерфейсы модулей и выявляет дефекты ПО в процессах их взаимодействий.
- Системное тестирование − проверяет ПО как систему. Программное обеспечение должно соответствовать тем требованиями, которые были заложены на самом первом этапе. Системное тестирование исследует работу ПО через призму потребностей и удобства пользователей.
Плюсы и минусы
Плюсы
- Простота в понимании модели;
- Более гибкая, чем каскадная модель Водопада;
- Планирование и организация тестов производятся до кодинга;
- Можно мониторить прогресс разработки, т.к. заранее понятны объемы работ и контрольные точки проекта;
- Меньше неучтенных рисков.
Минусы
- Необходимость пересмотра и обновления всех тестовых документов, если в середине разработки произойдут какие-либо изменения;
- Отсутствуют прототипы, идет сразу непосредственно разработка ПО;
- Не предусматривает распараллеливание разработки.
Когда V-модель эффективна?
- Когда изначально существуют простые и четкие требования к продукту;
- Когда проект небольшого размера;
- Когда разработчики и тестировщики умеют взаимодействовать по уровням модели.
Резюме
V-модель является усовершенствованием модели «Водопад». Применение тестирования по уровням разработки дает преимущество раннего обнаружения дефектов ПО. Вместе с тем, остается все еще жесткой по сравнению с подходом гибкой разработки.
Автор Михаил Кулешов
Михаил, профессиональный партнерский маркетолог, является основателем компании South Media OÜ, которая была создана в 2018 году и базируется в Таллинне. С 2016 года Михаил уехал из Финляндии и жил как настоящий «цифровой кочевник» в IT-индустрии, путешествуя по миру только с ноутбуком. Михаил работает и пишет статьи, связанные с IT-индустрией.
