Прежде чем начать читать Модель водопада, я бы посоветовал вам проверить этот пост “Жизненный цикл разработки программного обеспечения”
В этом посте вы можете увидеть различные типы методологий разработки программного обеспечения. Я упомянул модель водопада как одну из методологий разработки программного обеспечения.
Я бы также посоветовал вам прочитать о жизненном цикле тестирования программного обеспечения
Давайте подробно рассмотрим, что такое модель водопада и ее преимущества и недостатки.
Модель водопада:
Водопадная модель – это традиционная модель. Это также известный как процесс последовательного проектирования, часто используемый в SDLC, в котором прогресс рассматривается как нисходящий, как водопад, через различные этапы, такие как сбор требований, технико-экономическое обоснование/анализ, проектирование, кодирование, тестирование, установка и обслуживание. Каждая следующая фаза начинается только после достижения цели предыдущей фазы. Эта методология предпочтительна в проектах, где качество важнее графика или стоимости. Эта методология лучше всего подходит для краткосрочных проектов, где требования не изменятся. (например, калькулятор, управление посещаемостью)
Преимущества:
- Требования не меняются, дизайн и код не меняются, поэтому мы получить стабильный продукт.
- Эта модель проста в реализации. Требования завершаются на более ранних этапах жизненного цикла. Так что на следующих этапах не будет никакого хаоса.
- Требуемые ресурсы для реализации этой модели минимальны по сравнению с другими методологиями
- Каждый этап имеет определенные результаты. Это дает руководителю проекта и клиентам полную информацию о ходе проекта.
Недостатки:
- < li>Возврат назад невозможен, т. е. мы не можем вернуться назад и изменить требования после достижения этапа проектирования.
- Изменение требований приводит к изменению дизайна и кода, что приводит к дефектам в проекте из-за наложения этапов.
- Клиент может быть неудовлетворен, если требуемые им изменения не включены в продукт.
- Конечным результатом каскадной модели может быть негибкий продукт.
- С точки зрения тестирования тестировщики участвуют только на этапе тестирования. Требования не проверяются на этапе требований. Его нельзя изменить, даже если мы обнаружим ошибку в требовании на этапе тестирования. Это продолжается до конца и приводит к большому количеству переделок.
- Это не подходит для долгосрочных проектов, где требования могут время от времени меняться
- Модель водопада можно использовать только тогда, когда требования очень хорошо известны и исправлено
Заключительные слова: Тестирование — это не просто поиск ошибок. Согласно модели водопада, тестировщики вовлекаются только почти в конце SDLC. Давным-давно мантра тестирования заключалась в том, чтобы просто находить ошибки в программном обеспечении. Теперь многое изменилось. Реализованы некоторые другие модели SDLC. Другие модели я бы разместил в следующих постах подробно с их преимуществами и недостатками. Ваша команда может выбрать модель SDLC в зависимости от проекта, над которым вы работаете.
TAG: qa
Еще об этом:
150+ ЛУЧШИХ ВОПРОСОВ И ОТВЕТОВ НА ИНТЕРВЬЮ О ТЕСТИРОВАНИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
16 ЛУЧШИХ ИНСТРУМЕНТОВ И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ НА 2022 ГОД
ЛУЧШИЕ ИНСТРУМЕНТЫ АВТОМАТИЗИРОВАННОГО ТЕСТИРОВАНИЯ (БЕСПЛАТНЫЕ И ПЛАТНЫЕ) | август 2022 г.
ТЕСТПРОЕКТ ОБЗОР СРЕДСТВ АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ ПО МАТЕРИАЛАМ ДЛЯ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
СОПРОВОЖДЕНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ЧТО ТАКОЕ СКВОЗНОЕ (E2E) ТЕСТИРОВАНИЕ? | ПОДРОБНОЕ РУКОВОДСТВО
16 проблем тестирования программного обеспечения: как с ними справиться
Метрики Agile-тестирования: чем они могут помочь?
ЛУЧШЕЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ДЛЯ ДИНАМИЧЕСКОГО ТЕСТИРОВАНИЯ БЕЗОПАСНОСТИ ПРИЛОЖЕНИЙ (DAST) В 2022 ГОДУ
90+ ВОПРОСОВ И ОТВЕТОВ ИЗ ИНТЕРВЬЮ LOADRUNNER | ОБНОВЛЕНИЕ 2022 г.
