Ранее мы подробно рассматривали итеративный подход в разработке программного обеспечения, при котором выполнение работ происходит одновременно с непрерывным анализом и корректировкой последних. Модели итеративного/инкрементного жизненного цикла, как следует из названия, сосредоточены на разработке программного обеспечения в виде шагов или инкрементов. Популярные итеративные модели включают методологии гибкого тестирования, такие как Scrum, XP и т. д.
Общей чертой итеративных моделей является то, что в конце каждой итерации на выходе имеется полностью интегрированная рабочая система. Бизнес-функциональность разделена на отрезки.
Каждая итерация предоставляет набор функциональных возможностей, который интегрируется и тестируется. С точки зрения тестирования это выглядит так: группа тестировщиков получает тестируемый продукт в начале его жизненного цикла, в отличие от моделей последовательного типа. Тем не менее, использование итеративных и инкрементных моделей может создать собственный ряд трудностей для команд тестировщиков
Проблемы в тестировании программного обеспечения
Основная проблема для тестировщиков в гибких/итеративных моделях заключается в том, что тестируемая система постоянно меняется. Новый код проверяется регулярно, и при этом тестировщики не могут рассчитывать на то, что работа с продуктом приблизится к конечной стадии в ближайшее время. Для тестировщиков, работающих с подобными моделями, программный продукт является движущейся мишенью. Команда должна использовать различные подходы, инструменты и стратегии для управления подобным уровнем изменений.
В итеративных моделях более важные функции, как правило, встраиваются во время ранних итераций. В последующих инкрементах добавляется больше функционала помимо того, что был создан ранее. Учитывая количество изменений, которые могут появиться в новом билде, риск регрессии высок. Очень важно, чтобы команда провела регрессионное тестирование всех функций, имевшихся ранее, дабы убедиться, что ничего не сломалось.
Еще один интересный аспект итеративной разработки заключается в том, что инкременты могут пересекаться. Обычно не выходит так, что один инкремент завершается полностью до начала следующего. Тестировщики, как правило, тщательно проверяют сборку текущего или предыдущего билда, в то время как команда разработчиков работает над функциями следующего.
Разумеется, хоть тестировщики зачастую и занимаются тестированием новых функций, над которыми разработчики трудятся на данный момент, их главная задача — вдумчивое регрессионное тестирование последнего билда и новых функций, встроенных в него. Такие пересечения могут создать сложности при исправлении багов, найденных командой тестировщиков, а также увеличить необходимое на это время.
Тестировщикам следует обратить внимание, что итеративные модели (например, гибкая модель) не поддерживают особо тяжёлые процессы или формальные методы. Существуют редкие ситуации, когда необходимость тестирования ставится под сомнение. Но ещё раз — это редкость. Большинство опытных команд, работающих с использованием методов гибкой разработки, осознают ту огромную пользу, которую тестировщики могут принести в производстве качественного продукта. Тестировщикам необходимо адаптировать свои методы в соответствии с требованиями мира гибкой разработки.
Тестировщики должны понимать тот факт, что организация не стремится добиться программного продукта, полностью лишённого дефектов. Хоть заказчик и не заявит об этом и продолжит требовать безупречное ПО, он точно не будет готов сделать инвестиции, необходимые для покрытия всех издержек, которые неизбежны при подобном виде работ.
В действительности, при попытках получить безупречное ПО, затраты вырастут до такого уровня (в теории, для вычищения всех багов в системе потребуются неограниченные фонды), что организация сама не пожелает делать подобные инвестиции. Очень важно найти идеальный баланс между затратами и полученной выгодой.