Для нас сейчас постоянные обновления приложений на нашем смартфоне, на нашем компьютере или даже смарт-телевизоре, это нормальная реальность. Но так было не всегда. Компьютеры появились только во второй половине 20 века, а персональные компьютеры и того позднее - в конце 20 века. Потребность изменений тогда, на заре информационных технологий, была не такой, как сейчас. Так что водопадная модель разработки была самой первой придуманной и прекрасно удовлетворяла реалиям жизни тогда. Водопадная модель понятна и проста, да и отлично работает, когда есть бюджет и точная идея, что надо сделать.
Тестирование в водопадной модели
Как мы говорили в предыдущем уроке, у водопадной модели есть один важный минус. Чтобы по такой модели сделать качественный продукт, нужно потратить слишком много времени и ресурсов.
Это показывает знаменитый проектный треугольник:
По этому треугольнику наглядно видно, что чем больше скоуп, тем больше денег и времени тратится. Почему же так выходит? Дело в том, что все процессы линейны и последовательны.
Представим, что мы работаем над продуктом для заказчика. Сначала заказчик сформулировал свои требования, а затем мы изучили его требования и спроектировали будущее приложение. Мы завершили этап проектирования и начали разработку.
И тут выясняется, что требования к продукту меняются. Это может произойти по разным причинам:
- Заказчик не смог точно сформулировать, что ему надо
- Мы не до конца поняли требования заказчика
- У заказчика появились какие-то новые условия
В любом случае мы не можем внести правки в проект. Надо сначала завершить первый цикл, а уже потом начинать второй. В водопадной модели порядок этапов важнее всего: нельзя вернуться назад и переделать.
Поэтому все этапы длятся очень долго, ведь нужно все тщательно обсудить и согласовать с заказчиком. В итоге фазы будут огромными:
- Сначала мы долго проектируем и составляем большой список требований
- Из-за большого списка требований разработка затянется надолго
- Из-за долгой разработки придется потратить очень много времени на тестирование
Таким образом, на разработку готового продукта уйдет много времени, сил и денег.
Современные подходы к тестированию
В водопадной модели тестирование идет отдельным этапом, поэтому разработка получается дорогой и долгой. Намного эффективнее работают гибкие методологии, в которых команда тестирует продукт на всех этапах жизненного цикла.
Чем раньше мы начинаем анализировать, тем легче и дешевле исправить ошибки.
Представим, что на этапе проектирования мы забыли про какое-то требование заказчика. В результате программисты не узнают об этом требовании и не разработают нужную фичу. Эту проблему заметит тестировщик на этапе активного тестирования.
Из-за одной маленькой ошибки команде придется проводить еще один цикл проектирования, программирования и тестирования. То есть продукт дойдет до заказчика позже, да и стоимость разработки вырастет.
Теперь усложним ситуацию и представим, что даже тестировщик не обнаружил проблему. Тогда ее увидит заказчик в готовом продукте. Это негативно скажется на репутации фирмы-производителя ПО. Более того, если мы разрабатываем ПО для авиации или медицины, такая небольшая ошибка в проектировании может сказаться на безопасности.
За пределами каскадной модели тестирование внедряется на всех этапах жизненного цикла:
- Дизайн и требования проверяются до начала разработки — так можно на раннем этапе выявить просчеты и дыры в дизайне
- Код тестируется прямо на этапе разработки — программисты проводят статическое тестирование, ревью кода и юнит-тестирование
- Приложение тестируется на разных этапах разработки. Необязательно ждать полностью готовое приложение, ведь все можно проверить заранее. Еще до завершения разработки можно провести тестирование функциональностей, бета-тестирование, а также компонентное, модульное, интеграционное или системное тестирование
- На этапе приемки проводится еще одно тестирование — приемочное. Во время него приложение проверяется по сценариям, близким к реальным действиям пользователей (такие сценарии называются use cases)
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
Для полного доступа к курсу нужен базовый план
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
