Зарегистрируйтесь для доступа к 15+ бесплатным курсам по программированию с тренажером

Этап тестирования Жизненный цикл ПО, место тестирования

Для нас сейчас постоянные обновления приложений на нашем смартфоне, на нашем компьютере или даже смарт-телевизоре, это нормальная реальность. Но так было не всегда. Компьютеры появились только во второй половине 20 века, а персональные компьютеры и того позднее - в конце 20 века. Потребность изменений тогда, на заре информационных технологий, была не такой, как сейчас. Так что водопадная модель разработки была самой первой придуманной и прекрасно удовлетворяла реалиям жизни тогда. Водопадная модель понятна и проста, да и отлично работает, когда есть бюджет и точная идея, что надо сделать.

Тестирование в водопадной модели

Как мы говорили в предыдущем уроке, у водопадной модели есть один важный минус. Чтобы по такой модели сделать качественный продукт, нужно потратить слишком много времени и ресурсов.

Это показывает знаменитый проектный треугольник:

Проектный треугольник

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

Представим, что мы работаем над продуктом для заказчика. Сначала заказчик сформулировал свои требования, а затем мы изучили его требования и спроектировали будущее приложение. Мы завершили этап проектирования и начали разработку.

И тут выясняется, что требования к продукту меняются. Это может произойти по разным причинам:

  • Заказчик не смог точно сформулировать, что ему надо
  • Мы не до конца поняли требования заказчика
  • У заказчика появились какие-то новые условия

В любом случае мы не можем внести правки в проект. Надо сначала завершить первый цикл, а уже потом начинать второй. В водопадной модели порядок этапов важнее всего: нельзя вернуться назад и переделать.

Поэтому все этапы длятся очень долго, ведь нужно все тщательно обсудить и согласовать с заказчиком. В итоге фазы будут огромными:

  • Сначала мы долго проектируем и составляем большой список требований
  • Из-за большого списка требований разработка затянется надолго
  • Из-за долгой разработки придется потратить очень много времени на тестирование

Таким образом, на разработку готового продукта уйдет много времени, сил и денег.

Современные подходы к тестированию

В водопадной модели тестирование идет отдельным этапом, поэтому разработка получается дорогой и долгой. Намного эффективнее работают гибкие методологии, в которых команда тестирует продукт на всех этапах жизненного цикла.

Чем раньше мы начинаем анализировать, тем легче и дешевле исправить ошибки.

Представим, что на этапе проектирования мы забыли про какое-то требование заказчика. В результате программисты не узнают об этом требовании и не разработают нужную фичу. Эту проблему заметит тестировщик на этапе активного тестирования.

Из-за одной маленькой ошибки команде придется проводить еще один цикл проектирования, программирования и тестирования. То есть продукт дойдет до заказчика позже, да и стоимость разработки вырастет.

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

За пределами каскадной модели тестирование внедряется на всех этапах жизненного цикла:

  • Дизайн и требования проверяются до начала разработки — так можно на раннем этапе выявить просчеты и дыры в дизайне
  • Код тестируется прямо на этапе разработки — программисты проводят статическое тестирование, ревью кода и юнит-тестирование
  • Приложение тестируется на разных этапах разработки. Необязательно ждать полностью готовое приложение, ведь все можно проверить заранее. Еще до завершения разработки можно провести тестирование функциональностей, бета-тестирование, а также компонентное, модульное, интеграционное или системное тестирование
  • На этапе приемки проводится еще одно тестирование — приемочное. Во время него приложение проверяется по сценариям, близким к реальным действиям пользователей (такие сценарии называются use cases)

Аватары экспертов Хекслета

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты

Для полного доступа к курсу нужен базовый план

Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.

Получить доступ
1000
упражнений
2000+
часов теории
3200
тестов

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

  • 130 курсов, 2000+ часов теории
  • 1000 практических заданий в браузере
  • 360 000 студентов
Отправляя форму, вы принимаете «Соглашение об обработке персональных данных» и условия «Оферты», а также соглашаетесь с «Условиями использования»

Наши выпускники работают в компаниях:

Логотип компании Альфа Банк
Логотип компании Aviasales
Логотип компании Yandex
Логотип компании Tinkoff
Рекомендуемые программы
профессия
Выполняйте ручное тестирование веб-приложений, находите ошибки в продукте. Узнайте все о тест-дизайне.
4 месяца
с нуля
Старт 28 ноября

Используйте Хекслет по-максимуму!

  • Задавайте вопросы по уроку
  • Проверяйте знания в квизах
  • Проходите практику прямо в браузере
  • Отслеживайте свой прогресс

Зарегистрируйтесь или войдите в свой аккаунт

Отправляя форму, вы принимаете «Соглашение об обработке персональных данных» и условия «Оферты», а также соглашаетесь с «Условиями использования»