Тестирование в Agile

/Тестирование в Agile

Тестирование в Agile

В последнее время IT компании, занимающиеся разработкой ПО, активно переходят от «Waterfall» , где каждая итерация длится достаточно длительный период времени,  к «Agile«, где итерации могут длиться от одного дня до нескольких недель. В таких условиях тестирование, в привычном формате, испытывает трудности,а следовательно должно адаптироваться к изменяющимся реалиям и используемым методикам разработки.  О некоторых трудностях тестирования в Agile рассказывает Кэти Шерман в своей статье.

Тестирование в Agile:  спринт слишком короткий!

 

Хотя, многим разработчикам Agile нравится, тестировщикам …  не многим. «Невозможно закончить тестирование за один спринт», «Спринт слишком короткий, давайте добавим еще недельку», «нам нужно две или три недели для окончания регресса». Вы слышали что-то подобное? Я — все время.

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

  • Тестирование в момент изменения кода затрудняет стабилизацию baseline.
  • Доработки в конце спринта не оставляют времени на тестирование.
  • Нечастые сборки/развертывания приводят к задержкам и простоям.
  • Не хватает тестеров для планирования, документирования и тестирования.
  • Не хватает времени, чтобы пройти функциональное, интеграционное, регрессионное тестирование, юзабилити, тестирование безопасности и т.д..
  • Нет времени на ревью, исправление и ретестирование дефектов, найденных в конце спринта.
  • Отсутствие знаний и коммуникаций между тестерами, разработчиками, контент-менеджерами и др специалистами.

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

Так что же нам делать? Мы разделяем тестирование на две части: тесты, непосредственно связанные с реальными кейсами использования, разработанные в течении спринта и «все остальное». Затем «все остальное» мы откладываем на конец релиза, который происходит раз в несколько месяцев.

Факт: все, что мы можем сделать во время спринта – это просто функциональное тестирование. Мы не проводим много интеграционного, регрессионного тестирования или тестирования производительности вплоть до релиза. Финальную проверку системы мы называем «Регрессионный спринт» или «Закалочный спринт». Знакомо? Если вы киваете в знак согласия, не переживайте, вы не одиноки. Это очень типичная Agile реализация в индустрии.

К сожалению, это плохая идея.

 

Мы говорим, что пытаемся сгладить вопросы и проблемы Agile тестирования, но на самом деле мы не решаем проблему. Откладывая основное тестирование на конец релиза мы увеличиваем риск, жертвуем качеством и не используем главное достоинство Agile –частые поставки небольшими порциями.

Итак, добавление «закалочного спринта» не решает проблему «слишком короткого спринта». Реальная цель должна заключаться в том, чтобы исключить «закалочный спринт» и закончить все виды тестирования на протяжении спринта, какой бы короткий или длинный не был бы спринт. Таким образом, каждый спринт закончится с набором полностью протестированных функций, которые потенциально могут быть развернуты на продуктиве или отгружены заказчику. Не будет необходимости переключения контекста в конце релиза, не будет дефектов в последнюю минуту и дорогостоящих задержек.

 

 

У вас еще остались закалочные спринты? Вы ощущаете, что спринт слишком короткий?

Давайте начнем новый год с некоторыми важными решениями и обязуемся сделать наши решения по-настоящему гибкими. Давайте улучшать качество и поставлять обновления ПО заказчикам своевременно. Давайте исключим ручные сборки, развертывания и тестирование там, где это возможно сделать, автоматизировать регрессионные тесты и запускать их на ежедневной основе на протяжении спринта. Давайте изменим определение «Done», включающее все виды тестирования. Давайте избавимся от «закалочного» цикла.

 

Давайте завершим все наши тесты в спринте!

 

Ниже представлено практическое руководство без ощущения, что спринт «слишком короткий».

Перевод статьи Кэти Шерман

 

By | 2017-04-14T22:10:30+00:00 Апрель 14th, 2017|Заметки|0 Comments

About the Author:

Leave A Comment