Особенности тестирования приложений в условиях гибкой разработки

Большинство гибких методологий разработки программного обеспечения (ПО) нацелены на минимизацию рисков чрезмерных затрат на приложение посредством разработки в рамках коротких итераций. Одним из главных принципов гибкой стратегии является возможность быстрого реагирования на возможные изменения, нежели стремление положиться на долгосрочное планирование. Именно поэтому при планировании тестирования в условиях гибкой разработки необходимо учитывать возможные риски в плане бюджета и правильно распределять усилия [5].

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

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

Если рассматривать работу команды тестирования при работе по принципам Scrum [1], можно выделить несколько основных видов деятельности, в которых постоянно должны принимать участие тестировщики, чтобы придерживаться методологии и поддерживать процесс разработки:

• •    участие в Scrum-активностях (дейли, планинг, ретро) [1];

• •    поддержка юнит-тестирования (если оно применяется);

• •    тестирование пользовательских историй;

• •    сотрудничество с заказчиком и владельцем продукта для определения критериев приема продукта;

• •    поддержка автоматического тестирования (если оно применяется).

В то же время существует несколько особенностей гибкой методологии, которые вызывают определенные сложности для команды тестирования:

• •    необходимо обязательно оценивать все задачи, которые команда берет в одну итерацию на сложность со стороны тестирования;

• •    тестировщик должен постоянно следить за требованиями, поскольку они могут постоянно изменяться;

• •    необходим частый регресс в связи с частыми изменениями в коде;

• •    нужно одновременно планировать тестирование и выполнять тесты;

• •    частые недопонимания между членами команды в случае, если требования не однозначны.

Анализ способов документирования процесса тестирования

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

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

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

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

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

Регрессионная модель приложения

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

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

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

Проблемы автоматизированного тестирования в условиях гибкой разработки

Использование автотестирования на проекте с гибкой разработкой зачастую помогает значительно сократить время на регрессионное и приемочное тестирование. Также возможно использование unit-тестов. Unit-тестирование – процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы [3]. Обычно unit-тесты пишут разработчики, тестировщики только могут систематизированно их поддерживать, т.е. разделять по функционалу и помогать с повторным использованием уже существующих тестов. Использование unit-тестирования позволяет отсечь множество критичных багов уже на этапе написания кода [6].

Кроме unit-тестов, можно использовать GUI-автотесты. GUI-автотесты – это автоматизированное ПО, которое позволяет тестировать приложения через графический пользовательский интерфейс. Такое тестирование имеет несколько плюсов: во-первых, приложение тестируется тем же способом, которым его будет использовать человек, во-вторых, можно тестировать приложение, не имея при этом доступа к исходному коду. Идеальный вариант, это покрытие регрессионной модели GUI-автотестами. При таком варианте, в случае любого крупного изменения не нужно тратить около 4 часов на ручной прогон 15 сценариев, а можно просто запустить автотесты, которые через час дадут однозначный ответ, были ли задеты другие части приложения.

Для оценки рентабельности автотестирования на проекте существуют специальные стратегии, например, “Do pilot” [4]. Как видно из графика на рисунке 2, использование автоматизации дает лучшие результаты при тех же затратах. Но данный график будет актуальным только при автоматизации тестирования больших проектов (общая команда проекта ~100+ человек или более 5 команд), поскольку только в данном случае экономия от использования автоматизации может оправдать и окупить расходы на ее

Рисунок 2 – Рентабельность автоматизации тестирования

Заключение

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