CC BY
7
8. Пинаева Д.А. Деятельность научных инженерно-технических обществ по активизации рационализаторства и изобретательства в Татарской АССР в конце 1940-х - начале 1950-х годов // Вестник Пермского университета. Серия: История. 2016. № 2 (33). С. 97-107.
9. ЦГА ИПД РТ. Ф. 15. Оп. 7. Д. 941. Л. 18.
10. НА РТ. Ф. Р-7240. Оп. 2. Д. 876. Л. 12.
11. НА РТ. Ф. Р-7240. Оп. 2. Д. 876. Л. 26, 27.
12. НА РТ. Ф. Р-7240. Оп. 2. Д. 920. Л.10, 13.
13. НА РТ. Ф. Р-7240. Оп. 2. Д. 947. Л.22.
УДК 004.05
Ярыгина Е.В. студент магистратуры 2 курса
УГАТУ
Российская Федерация, г. Уфа ОСОБЕННОСТИ ТЕСТИРОВАНИЯ ПРИЛОЖЕНИЙ В УСЛОВИЯХ ГИБКОЙ РАЗРАБОТКИ
Аннотация
В данной статье рассмотрены основные проблемы при тестировании приложений в условиях гибкой разработки, а также такие аспекты тестирования как ведение тестовой документации, разработка регрессионной модели и применение автотестирования. Ключевые слова
Тестирование, гибкая разработка, автотестирование, unit-тесты, Scrum.
Yarygina E. V.
Master of 2years of USATU, Russian Federation, Ufa FEATURES OF APPLICATION TESTING IN AGILE DEVELOPMENT
Annotation
This article describes the main problems of testing applications in Agile development, as well as such aspects of testing as test documentation management, development of a regression model and application of automated testing. Key words
Testing, agile development, automated testing, unit tests, Scrum. Введение
Большинство гибких методологий разработки программного обеспечения (ПО) нацелены на минимизацию рисков чрезмерных затрат на приложение посредством разработки в рамках коротких итераций. Одним из главных принципов гибкой стратегии является возможность быстрого реагирования на возможные изменения, нежели стремление положиться на долгосрочное планирование. Именно поэтому при планировании
тестирования в условиях гибкой разработки необходимо учитывать возможные риски в плане бюджета и правильно распределять усилия [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 - Рентабельность автоматизации тестирования Заключение
В заключении можно отметить, что основными факторами успешного тестирования в условиях гибкой разработки является правильный выбор и ведение тестовой документации, своевременная и актуальная регрессионная модель, использование автотестирования, для сокращения времени тестирования при частых или масштабных изменениях.
Использованные источники:
1. Сазерленд Д. Scrum. Революционный метод управления проектами. -Москва: Манн, Иванов и Фербер, 2017.
2. Юнит-тестирование [Электронный ресурс] - режим доступа: https: //habr.com/post/169381/
3. Методологии тестирования ПО [Электронный ресурс] - режим доступа: https://xbsoftware.ru/blog/metodologii-testirovaniya-po-kakuyu-vybrat/
4. Как автоматизировать тестирование [Электронный ресурс] - режим доступа: http://software-testing.ru/library/testing/testing-automation/2938-desktop-testing
5. G. J. Myers, C. Sandler and T. Badgett, The art of software testing. John Wiley & Sons, 2011.
6. E. Daka and G. Fraser, A survey on unit testing practices and problems, Software Reliability Engineering (ISSRE), 2014 IEEE 25th International Symposium on. IEEE, 2014.
7. Тестирование. Фундаментальная теория [Электронный ресурс] - режим доступа: https : //habr. com/post/279535/
