УЛУЧШЕНИЕ КАЧЕСТВА ТИКЕТОВ В ТЕСТИРОВАНИИ ПО: СНИЖЕНИЕ ВОЗВРАТОВ ЗАДАЧ И УСКОРЕНИЕ ИСПРАВЛЕНИЯ БАГОВ

АННОТАЦИЯ

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

ABSTRACT

The article analyzes recommendations for improving the quality of ticket formatting by a testing specialist. The primary objective is to assess the effectiveness of these methods. Based on the data obtained from the analysis, the article concludes whether these practical recommendations indeed accelerate development time. The methods and practical recommendations described in the article are primarily beneficial for software testing specialists, as well as developers.

Ключевые слова: Тестирование программного обеспечения, Оптимизация процесса разработки, Регрессионное тестирование, Jira, QA

Keywords: Software Testing, Development Process Optimization, Regression Testing, Jira, QA

Введение

Тестирование и разработка программного обеспечения являются ключевыми этапами в жизненном цикле программных систем (SDLC).[7] Эффективность этих процессов во многом зависит от качества взаимодействия между участниками этих этапов. Основное взаимодействие происходит через систему тикетов. Тикеты – это инструмент, используемый для отслеживания задач, ошибок, запросов на функции и других аспектов, связанных с проектом. Система тикетов помогает организовать рабочий процесс и распределение задач среди участников команды.[4]

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

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

Материалы и методы исследования

Тестирование эффекта рекомендаций проводилось с помощью системы баг трекинга Jira. Анализ тикетов происходил на основе наличия или отсутствия pull request, связанного с задачей. Наличие pull request подразумевало изменения в коде, а его отсутствие – недостаток данных и необходимость уточнения.

Все практические рекомендации для тестировщиков были применены с использованием следующих методологий тестирования: Black Box Testing, Regress testing.

В целях автоматизации сбора данных использовался плагин ScriptRunner for Jira. Он позволил собрать тикеты с типом «Баг» и заполненным полем Pull requests.

Описание инструментов и методов

Jira –– это система управления проектами и задачами, которая широко используется в разработке программного обеспечения для отслеживания и координации процессов. Основное назначение Jira заключается в управлении жизненным циклом разработки, начиная с планирования и заканчивая выпуском продукта. Она предоставляет инструменты для создания, назначения и управления задачами, которые чаще всего представлены в виде тикетов (issues).

Jira поддерживает гибкие методологии разработки, такие как Scrum и Kanban [6], и позволяет создавать доски для визуализации задач, что помогает командам отслеживать прогресс в реальном времени. Созданный тикет проходит флоу от создания до его выпуска на production окружение.

Ниже представлен стандартный рабочий процесс задачи при отсутствии необходимости в уточнении или корректировке.             

Рисунок 1. Схема

В случае недостатка данных от тестировщика тикет возвращается разработчику и цикл повторяется

Рисунок 2. Схема

Черный ящик (black-box-testing) –– это подход в тестировании, который фокусируется на проверке функциональности программного обеспечения без знания его внутренней структуры [5] [9]

Регрессионное тестирование — проверяло, соответствует ли функциональность приложения заявленным требованиям и действительно ли исправлены ошибки, описанные в тикете. Также использовалось для проверки того, что новые изменения в коде не привели к появлению новых ошибок. [10] [11]

ScriptRunner for Jira –– плагин для автоматизации и расширения функциональности Jira с помощью скриптов на языке Groovy. Он добавляет специальные функции и фильтры в стандартный Jira Query Language (JQL) и помогает достать специфичную информацию по тикетам.

Для получения всех тикетов за период с типом Баг и заполненным полем Pull Request мы использовали следующий код:

issueFunction in statusChangedTo("Ready for QA") AND issuetype = Bug

AND development[pullrequests].all = 0

AND updated >= "2024-06-01" AND updated <= "2024-09-30"

Таблица 1.

Пример вывода запроса в ScriptRunner

Практические рекомендации

Описание окружения, где происходит баг

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

1. Операционная система, на которой проводился тест
2. Браузер и его версия
3. Состояние сети (например, наличие ограничений скорости соединения, использование сетевого троттлинга)

Данные о пользователе

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

1. Аутентификационные данные (логин и пароль), если это безопасно.
2. Дополнительные специфические условия (например, наличие cookie-файлов или кастомных значений в localStorage, которые могли быть изменены вручную)

Подробное описание ошибки

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

Для фронтенда

1. Скриншот или видео с демонстрацией ошибки на клиентской стороне.
2. Логи из консоли браузера
3. Название компонента или модуля интерфейса, где произошла ошибка

Для бекенда

1. Скриншот или видео с демонстрацией ошибки на клиенте
2. Код ответа запроса, который завершился с ошибкой
3. URL запроса
4. Ответ сервера
5. Логи из систем мониторинга Sentry/AppSignal
6. Логи из AWS Console, если они доступны.

Дополнительные файлы

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

1. Логи с ошибками. Если объём логов значителен, рекомендуется прикрепить их в виде файла для удобства анализа.
2. Специфические файлы, которые могут влиять на воспроизведение ошибки (например, файлы, связанные с загрузкой).

Повторное прохождение по описанным шагам

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

Результаты исследования и их обсуждение

Для оценки эффективности внедрённых рекомендаций был проведён анализ в течение трёх месяцев после их применения. Результаты отслеживались в конце каждого квартала. Для этого использовались данные, автоматически собранные с помощью инструмента Jira и плагина ScriptRunner, что было описано ранее в методах исследования. Основным показателем для сравнения выступало количество тикетов, возвращённых на доработку, которое сравнивалось с аналогичным периодом до внедрения рекомендаций.

Количественные результаты

В первом квартале, до внедрения рекомендаций, было зарегистрировано 318 тикетов с типом “Баг”. Из них 17% были возвращены на доработку в связи с недостаточной информацией, предоставленной тестировщиками.

Рисунок 3. Показатели по количеству багов

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

В новом периоде, после внедрения рекомендаций, было обработано 273 тикета со статусом “Баг”. Из этих тикетов 8% были возвращены на доработку для уточнения данных.

Рисунок 4. Процент вовзрата тикетов (%)

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

Где:

 — процентное снижение возвратов тикетов на доработку.

 — количество тикетов, возвращённых без изменений в коде, до внедрения практических рекомендаций,

​ — количество тикетов, возвращённых без изменений в коде, после внедрения практических рекомендаций.

Применив данную формулу к нашим данным:

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

Выводы

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

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

Улучшение первоначального описания ошибок тестировщиками способствует более оперативной работе разработчиков, уменьшая общее время на исправление багов.

Эти изменения положительно влияют на общую эффективность командной работы, снижая затраты на доработку и улучшая качество выпускаемого продукта. [12] [8]

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

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

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

Список литературы:

1. Chaparro O., Bernal-Cárdenas C., Lu J., Moran K., Marcus A., Penta M., Poshyvanyk D., Ng V. Assessing the quality of the steps to reproduce in bug reports // Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering [Электронный ресурс]. — 2019. — Режим доступа: https://doi.org/10.1145/3338906.3338947 (дата обращения: 01.10.2024).
2. Cruzes D., Moe N., Dybå T. Communication between Developers and Testers in Distributed Continuous Agile Testing // 2016 IEEE 11th International Conference on Global Software Engineering (ICGSE). — 2016. — С. 59-68. https://doi.org/10.1109/ICGSE.2016.27.
3. Fazzini M., Moran K., Cardenas C.B., Wendland T., Orso A., Poshyvanyk D. Enhancing Mobile App Bug Reporting via Real-Time Understanding of Reproduction Steps // IEEE Transactions on Software Engineering. — 2022. — Т. 49. — С. 1246-1272.
4. Gohil F., Kumar M. Ticketing System // International Journal of Trend in Scientific Research and Development. — 2019. https://doi.org/10.31142/ijtsrd23603.
5. Kaprocki Z., et al. Combined testing approach: Increased efficiency of black box testing // 2015 IEEE 1st International Workshop on Consumer Electronics (CE WS). — 2015. — С. 76-78. — doi: https://doi.org/10.1109/CEWS.2015.7867160.
6. Lei H., Ganjeizadeh F., Jayachandran P., Ozcan P. A statistical analysis of the effects of Scrum and Kanban on software development projects // Robotics and Computer-integrated Manufacturing. — 2017. — Т. 43. — С. 59-67. https://doi.org/10.1016/J.RCIM.2015.12.001.
7. Parihar M., Bharti A. Importance Of Software Testing In Software Development Life Cycle // International Journal of Research. — 2019. — Т. 6. — С. 888-900.
8. Tassey G. The economic impacts of inadequate infrastructure for software testing. — 2002.
9. Verma A., Khatana A., Chaudhary S. A Comparative Study of Black Box Testing and White Box Testing // International Journal of Computer Sciences and Engineering. — 2017. — Т. 5. — С. 301-304. — doi: 10.26438/ijcse/v5i12.301304.
10. Wahl N. An overview of regression testing // ACM SIGSOFT Software Engineering Notes. — 1999. — Т. 24. — С. 69-73. https://doi.org/10.1145/308769.308790.
11. Wong W.E., Horgan J.R., London S., Agrawal H. A study of effective regression testing in practice // Proceedings The Eighth International Symposium on Software Reliability Engineering, Albuquerque, NM, USA. — 1997. — С. 264-274. — doi: 10.1109/ISSRE.1997.630875.
12. Zimmermann T., Premraj R., Bettenburg N., Just S., Schröter A., Weiss C. What Makes a Good Bug Report? // IEEE Transactions on Software Engineering. — 2008. — Т. 36. — С. 618-643. https://doi.org/10.1145/1453101.1453146.