Привет! Меня зовут Кристина, я тестировщик в ППК «Роскадастр» и ревьюер курса «Инженер по тестированию» в Яндекс Практикуме. В этой статье я расскажу, как правильно оформлять задачи в Jira — так, чтобы тестировщик сразу понял, что от него требуется, и выполнил работу без лишних уточнений и задержек.

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

Стандартный процесс выглядит так: задачи в Jira формирует и согласовывает руководитель проекта или отдела. После этого задача переходит в статус «Протестировать» и попадает в зону ответственности QA-инженера.

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

Знакомство с Jira можно начать со статьи, в которой делятся простой инструкцией к сервису: «Красота не главное: руководство по Jira для нетехнарей».

Как правильно оформить задачу

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

Заголовок задачи

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

Плохо:

Исправить баг в отчёте.

Хорошо: 

Исправить ошибку несоответствия XML-файла XSD-схеме.

Описание задачи

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

Плохо:

Необходимо проверить работу сервиса на тестовом стенде.

Хорошо:

Задача:
Проверить работоспособность:

• экранных форм, 

• попапов 

• и переходов. 

  При обращении к сервису должен отправляться запрос в подсистему приёма №1. Подсистема должна принять и корректно обработать пакет данных. Необходимо протестировать все сценарии и переходы, которые возможны на сайте.

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

  Ссылки:

  • Родительская задача по проектированию;

  • Техническое задание;

  • Инструкция по работе;

  • Окружение и ссылка на тестовый стенд;

  • Страница Confluence.

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

Избегайте двусмысленностей. QA-инженер воспринимает задачу буквально — как это сделал бы обычный пользователь, не знакомый с внутренней логикой сервиса. При тестировании он будет воспроизводить шаги ровно так, как они описаны в сценарии.

Чеклист для хорошей задачи

Перед тем как отправить задачу на тестирование, убедитесь, что она правильно оформлена и в ней есть всё необходимое:

• Подробный тестовый сценарий с шагами и ожидаемыми результатами;

• Ссылки на техническое задание, стенды и документацию;

• Все нужные доступы (и информация о них);

• Чётко обозначенный финальный результат;

• Указание на условия завершения тестирования (например, полный цикл от составления запроса  до получения ответа от базы данных).

Типичные ошибки при постановке задач

«Понял я — поймут и другие». Самая распространённая проблема – судить других по себе. Часто задачи ставятся по принципу, что если это понятно мне, то другой человек тоже воспримет ровно так, как думает автор задачи. Это далеко не всегда так, потому что не каждый исполнитель погружён в контекст, а у разных сотрудников разный опыт.

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

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

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

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

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

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

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

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

Организационные ошибки тоже могут стать причиной срыва релиза. Чтобы их избежать, следует подготовить шаблон оформления задачи и направить его команде. «Рыбой» для шаблона может стать пример выше. Дисциплину отрегулировать поможет кросс-ревью – это best practice бигтехов, когда раз в 1-6 месяцев сотрудники проверяют оформление задач коллег и дают обратную связь.

Коммуникационные проблемы тоже не стоит игнорировать. Казалось бы, что может быть проще и приятнее, чем общение с коллегами? Однако недооценивать роль коммуникации в жизненном цикле продукта не стоит. 

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

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

Полезные ресурсы

Каждый из этих источников содержит полезную информацию для улучшения навыков оформления задач на тестирование в Jira и повысить качество тестирования в целом. 

Рекомендую начать с официальных руководств Atlassian и постепенно расширять кругозор, изучая специализированные интернет-источники для QA-инженеров.

• Подробное руководство по работе с Jira, Atlassian — документация на русском.

• Jira Documentation, Atlassian — документация на английском.

• Как Google тестирует ПО, Хабр — статья-конспект вебинара технического директора по тестированию ПО в Google. 

• Test Case Management Tool, Хабр — статья о том, как выбрать инструментарий для работы с тест-кейсами. 

• Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin, Janet Gregory — книга об Agile-тестировании на английском. 

• Agile-тестирование: Обучающий курс для всей команды, Лайза Криспин, Джанет Грегори — эта же книга в переводе на русский.

• Perfect Software: And Other Illusions About Testing, Gerald M. Weinberg — книга на английском о типичных ошибках в разработке ПО.

• 5 Best Practices in Test Management, Kualitee — статья на английском о лучших практиках.

• Test Documentation: Best Practices with Examples, testRigor — ещё одна англоязычная статья о лучших практиках.

• How to Write Effective Test Cases, TestRail — статья на английском о том, как писать тест-кейсы. С шаблонами.

• IEEE 829 Standard for Software Test Documentation — описание стандарта на английском.

• ISO 29119 Software Testing Standard — описание стандарта на английском.