atesting.ru Блог Модель V в жизненном цикле разработки программного обеспечения

Модель V в жизненном цикле разработки программного обеспечения

Прежде чем запускать V Model, я бы порекомендовал вам проверить этот пост «Жизненный цикл разработки программного обеспечения»

В этом посте вы могли увидеть различные типы методологий разработки программного обеспечения, такие как модель водопада, Agile и т. д. . Здесь я собираюсь написать о V-модели, о которой я упоминал в этом посте.

Я также рекомендую вам прочитать о жизненном цикле тестирования программного обеспечения

Давайте посмотрим, что такое V-модель и подробно о его преимуществах и недостатках.

 V-модель в жизненном цикле разработки программного обеспечения

V-модель:

V-модель также известна как модель проверки и подтверждения (V&V) . При этом каждая фаза SDLC должна быть завершена до начала следующей фазы. Он следует последовательному процессу проектирования, так же, как и модель водопада.

Не думаете ли вы, почему мы используем эту модель V, если она такая же, как модель водопада. 🙂

Позвольте мне упомянуть следующий момент о том, зачем нам нужна эта модель проверки и проверки.

Это преодолевает недостатки водопадной модели. В каскадной модели мы видели, что тестировщики участвуют в проекте только на последней стадии процесса разработки.

Если вы не проходили каскадную модель, нажмите здесь.

< p>В этом команда тестирования участвует на ранних этапах SDLC. Тестирование начинается на ранних стадиях разработки продукта, что позволяет избежать нисходящего потока дефектов, что, в свою очередь, сокращает количество переделок. Обе команды (тестовая и разработка) работают параллельно. Команда тестирования работает над различными видами деятельности, такими как подготовка стратегии тестирования, плана тестирования и тестовых примеров/сценариев, в то время как группа разработчиков работает над SRS, дизайном и кодированием.

После получения требований команда разработчиков и тестировщиков начинают свою деятельность.

В этой модели результаты параллельны. Пока разработчики работают над SRS (Спецификация требований к системе), тестировщики работают над BRS (Спецификация бизнес-требований) и готовят ATP (План приемочных испытаний) и ATC (Сценарии приемочных испытаний) и так далее.

Тестировщики будут готовы со всеми необходимыми артефактами (такими как план тестирования, тестовые наборы) к тому времени, когда разработчики выпустят готовый продукт. Это экономит много времени.

Давайте посмотрим, как команда разработчиков и группа тестирования задействованы на каждом этапе SDLC в модели V.

1. Как только клиент отправляет BRS, обе команды (тестирование и разработка) начинают свою деятельность. Разработчики переводят BRS в SRS. Группа тестирования проверяет BRS, чтобы найти недостающие или неправильные требования, и пишет план приемочного тестирования и примеры приемочного тестирования.

2. На следующем этапе группа разработчиков отправляет в SRS команду тестирования для проверки, и разработчики начинают создавать HLD (документ высокого уровня) продукта. Группа тестирования участвует в проверке SRS на соответствие BRS и пишет план тестирования системы и тестовые примеры.

3. На следующем этапе команда разработчиков приступает к созданию LLD (Low Level Design) продукта. Группа тестирования участвует в рассмотрении HLD (High Level Design) и пишет план тестирования интеграции и тестовые примеры интеграции.

4. На следующем этапе команда разработчиков начинает кодирование продукта. Группа тестирования участвует в проверке LLD и пишет план функционального тестирования и сценарии функционального тестирования.

5. На следующем этапе команда разработчиков передает сборку группе тестирования после завершения модульного тестирования. Команда тестирования поэтапно выполняет функциональное тестирование, интеграционное тестирование, системное тестирование и приемочное тестирование.

Преимущества:

  • Тестирование начинается на ранних стадиях разработки продукта, что позволяет избежать нисходящего потока дефектов и помогает найти дефекты на ранних стадиях.
  • Тестирование команда будет готова с тестовыми примерами к тому времени, когда разработчики выпустят программное обеспечение, что, в свою очередь, сэкономит много времени.
  • Тестирование проводится на каждом этапе разработки продукта. Это дает качественный продукт.
  • Общие вложения меньше из-за меньшего количества переделок или отсутствия переделок.

Недостатки:

  • Первоначальные вложения больше, потому что команда тестирования задействована с самого начала.
  • Всякий раз, когда есть изменение в требованиях, продолжается та же процедура. Это ведет к большему количеству работы с документацией.

Приложения:

Долгосрочные проекты, сложные приложения, когда заказчик ожидает продукт очень высокого качества с в установленные сроки, потому что каждый этап тестируется, а разработчики и разработчики; тестировщики работают параллельно

TAG: qa