Перед запуском V Model я бы порекомендовал вам проверить этот пост “Жизненный цикл разработки программного обеспечения”
В этом посте вы можете увидеть различные типы методологий разработки программного обеспечения, такие как Waterfall Model, Agile и т. д. . Здесь я собираюсь написать о V-модели, о которой я упоминал в этом посте.
Я также рекомендую вам прочитать о жизненном цикле тестирования программного обеспечения
Давайте посмотрим, что такое V-модель и ее преимущества и недостатки. подробно.
V-модель :
V-модель также известна как модель проверки и проверки (V&V). При этом каждый этап SDLC должен быть завершен до начала следующего этапа. Он следует последовательному процессу проектирования, такому же, как модель водопада.
Вы не думаете, почему мы используем эту модель V, если она такая же, как модель водопада. 🙂<р>Позвольте мне упомянуть следующий момент о том, зачем нам нужна эта модель проверки и проверки.
Она преодолевает недостатки водопадной модели. В водопадной модели мы увидели, что тестировщики участвуют в проекте только на последнем этапе процесса разработки.
Если вы не прошли каскадную модель, нажмите здесь.
В этом команда тестирования участвует на ранних этапах SDLC. Тестирование начинается на ранних стадиях разработки продукта, что позволяет избежать нисходящего потока дефектов, что, в свою очередь, снижает количество переделок. Обе команды (тестирование и разработка) работают параллельно. Команда тестирования работает над различными видами деятельности, такими как подготовка стратегии тестирования, плана тестирования и тестовых случаев/скриптов, в то время как команда разработчиков работает над SRS, проектированием и кодированием.
После получения требований, как команда разработки, так и команда тестирования начать свою деятельность.
Результаты параллельны в этой модели. Пока разработчики работают над SRS (спецификацией системных требований), тестировщики работают над BRS (спецификацией бизнес-требований) и готовят ATP (план приемочного тестирования), ATC (кейсы приемочного тестирования) и т. д.
Тестеры будут готовы ко всему. необходимые артефакты (такие как план тестирования, тестовые наборы) к моменту выпуска разработчиками готового продукта. Это экономит много времени.
Давайте посмотрим, как команда разработчиков и команда тестирования участвуют в каждом этапе SDLC в модели V.
1. Как только клиент отправляет BRS, обе команды (тестирование и разработка) начинают свою деятельность. Разработчики переводят BRS в SRS. Группа тестирования участвует в анализе BRS, чтобы найти отсутствующие или неправильные требования, и пишет план приемочных испытаний и примеры приемочных испытаний.
2. На следующем этапе команда разработчиков отправляет SRS группе тестирования для проверки, и разработчики начинают создавать HLD (проектный документ высокого уровня) продукта. Группа тестирования участвует в проверке SRS по сравнению с BRS и пишет план тестирования системы и тестовые примеры.
3. На следующем этапе команда разработчиков приступает к созданию LLD (низкоуровневого проектирования) продукта. Группа тестирования участвует в рассмотрении HLD (High Level Design) и пишет план тестирования интеграции и тестовые примеры интеграции.
4. На следующем этапе команда разработчиков начинает кодирование продукта. Группа тестирования участвует в проверке LLD и пишет план функционального тестирования и сценарии функционального тестирования.
5. На следующем этапе команда разработчиков передает сборку команде тестирования после завершения модульного тестирования. Группа тестирования шаг за шагом проводит функциональное тестирование, интеграционное тестирование, системное тестирование и приемочное тестирование сборки релиза.
Преимущества:
- Тестирование начинается на ранних стадиях разработки продукта, что позволяет избежать нисходящего потока дефектов и помогает найти дефекты на ранних стадиях
- Команда тестировщиков будет готова с тестовыми примерами к тому времени, когда разработчики выпустят программное обеспечение, что, в свою очередь, значительно сэкономит времени
- Тестирование проводится на каждом этапе разработки продукта. Это дает качественный продукт.
- Общие инвестиции меньше из-за меньшего количества переделок или их отсутствия.
Недостатки:
- Первоначальные инвестиции больше, потому что команда тестировщиков вовлекается с самого начала.
- Всякий раз, когда требования меняются, та же процедура продолжается. Это требует больше работы с документацией.
Применения:
долгосрочные проекты, сложные приложения, когда клиент ожидает очень высококачественный продукт в оговоренные сроки, потому что каждый этап проверено, а разработчики и тестировщики работают параллельно
TAG: qa
Еще об этом:
150+ ЛУЧШИХ ВОПРОСОВ И ОТВЕТОВ НА ИНТЕРВЬЮ О ТЕСТИРОВАНИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
100+ ВИДОВ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ – ПОЛНЫЙ СПИСОК
ЛУЧШИЕ ИНСТРУМЕНТЫ ТЕСТИРОВАНИЯ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ В 2024 ГОДУ ДЛЯ ANDROID И IOS
ЛУЧШИЕ ИНСТРУМЕНТЫ АВТОМАТИЗИРОВАННОГО ТЕСТИРОВАНИЯ (БЕСПЛАТНЫЕ И ПЛАТНЫЕ) | август 2022 г.
ЧТО ТАКОЕ ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ | ВСЕ, ЧТО ВЫ ДОЛЖНЫ ЗНАТЬ
ТОП-30 ВОПРОСОВ НА ИНТЕРВЬЮ ПО Agile-тестированию
ВЛАДЕЛЕЦ ПРОДУКТА VS СКРАМ-МАСТЕР: ВСЕ, ЧТО ВЫ ДОЛЖНЫ ЗНАТЬ
ЧТО ТАКОЕ ДЕВТЕСТОПС? ПРОЦЕСС, РЕАЛИЗАЦИЯ И ПРЕИМУЩЕСТВА
ЧТО ТАКОЕ ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (SDLC), ЭТАПЫ, SDLC VS STLC
БЕТА-ТЕСТИРОВАНИЕ – ПОДРОБНОЕ РУКОВОДСТВО
