Xray — приложение для управления тестированием в Jira. Оно помогает связать требование с проверками и увидеть результаты выполнения в контексте поставки. Здесь речь о test management, а не об одноимённых инструментах анализа безопасности. Для QA сильная сторона Xray — трассируемость: можно проследить путь от пользовательского обещания до фактической проверки и дефекта. Но такая цепочка полезна только при корректных связях, осмысленных тестах и правильно выбранном контексте отчёта.
Какие сущности нужно различать
Test описывает проверку, Precondition — переиспользуемую предпосылку, Test Set — логическую группу тестов. Test Execution представляет конкретное выполнение набора, а Test Run хранит результат отдельного теста внутри этого выполнения. Test Plan задаёт планируемый объём и объединяет связанные выполнения. Некоторые сущности представлены Jira-задачами, но Test Run не следует считать отдельной Jira-задачей. Установленные типы и возможности зависят от конфигурации; Cloud и Server/Data Center проверяют по своей документации.
Почему Test Set не заменяет Test Plan
Test Set удобен как коллекция проверок, например «Критические операции платежей». Само наличие теста в таком наборе не сообщает, проходил ли он на текущей версии. Test Plan нужен для отслеживания запланированных тестов и результатов связанных Test Executions. Если использовать набор как отчёт о готовности, легко показать список хороших сценариев без единого свежего выполнения. Задавай сначала управленческий вопрос, а затем выбирай сущность, которая действительно хранит ответ.
Состояние теста и результат выполнения
Статус Jira-задачи Test может описывать жизненный цикл инструкции: черновик, review, готов к использованию. Результат Test Run описывает наблюдение: проверка прошла, упала, не выполнялась либо заблокирована в соответствии с настройками проекта. Это разные измерения. Тест может быть полностью согласован, но падать на новой сборке; устаревший тест может успешно исполняться и не проверять нужное правило. Не связывай эти статусы механически без понимания процесса команды.
Как описывать ручной Test
Формулируй название как проверяемое поведение, предусловия как воспроизводимое состояние, шаги как действия с понятным ожидаемым результатом. Для оплаты укажи валюту, способ оплаты, состояние заказа и способ проверить итог. Если используешь Precondition, убедись, что ссылка не скрывает критичные отличия: новый и существующий пользователь могут иметь разные ограничения. Один длинный кейс на весь checkout плохо локализует сбой. Разделяй проверки по смыслу, сохраняя отдельный критический сквозной сценарий.
Практика: возврат частично оплаченного заказа
Есть история Jira о возврате средств. Правило: вернуть можно не больше фактически оплаченной суммы, повторный запрос не должен создавать двойной возврат. На тестовом стенде подготовлен заказ с оплатой 6000 минимальных денежных единиц и sandbox платёжного провайдера. Нужно подтвердить расчёт, ограничения и повтор операции, а не только наличие кнопки.
- 1.Создай Tests для возврата 2000, превышения доступной суммы и повторного запроса. Свяжи их с требованием и опиши проверяемые побочные эффекты.
- 2.Добавь проверки в Test Plan релиза и создай Test Execution с контекстом сборки и окружения. Ожидается явный планируемый объём и место для новых результатов.
- 3.Выполни возврат 2000. Проверь запись операции и оставшийся доступный остаток 4000; зафиксируй Test Run с фактическими значениями.
- 4.Попробуй вернуть 5000 после первого возврата. Ожидается отказ по правилам продукта без второй денежной операции.
- 5.Повтори исходный запрос с согласованным idempotency key. Ожидается предусмотренная контрактом обработка без второго возврата денег; при дефекте свяжи баг с упавшим выполнением.
- 6.После исправления создай нужную повторную проверку в принятом процессе и запиши новую сборку. Убедись, что отчёт не выдаёт старый результат за свежий.
Покрытие требований и окружения
Трассируемость начинается со связей, но качество определяется содержанием тестов. Проверь, какие Jira-типы считаются требованиями и какие отношения учитывает Xray в проекте. Затем уточни контекст расчёта покрытия: версия, Test Plan, Test Environment и связанные выполнения. Один успешный результат на Chrome не подтверждает мобильный сценарий. Статистика последних результатов также может скрыть ранее упавшую конфигурацию, если команда не договорилась, как разделять окружения и повторные прогоны.
Автотесты, BDD и стабильная идентичность
В Xray можно связывать автоматические проверки и импортировать результаты поддерживаемых форматов. Конкретный импорт и сопоставление зависят от формата, редакции и адаптера. Для BDD согласуй направление синхронизации сценариев: случайное редактирование feature-файла и теста в Jira двумя людьми создаёт конфликт источников истины. Имя метода, ключ Test и идентификатор сценария решают разные задачи. Переименование не должно бесконтрольно создавать новый Test и обрывать историю покрытия.
Проверка интеграции до массовой загрузки
Запусти маленький набор: успешный тест, намеренно упавший и пропущенный. Проверь, в какой Test Execution попали результаты, как отразились шаги и вложения и какие Tests были созданы либо сопоставлены. Для Cloud и Data Center не копируй endpoints и способ аутентификации без сверки. Сохраняй метаданные сборки, но очищай запросы и логи от секретов. Отсутствующий результат означает пробел интеграции, а не автоматический успех проверки.
Как поддерживать историю и базу
Регулярно находи требования без проверок, Tests без владельца и сценарии, которые давно не соответствуют продукту. Изменение теста после выполнения не должно заставлять читателя угадывать, что проверяли раньше: используй доступную историю и прикладывай необходимый контекст. При нескольких проектах согласуй правила доступа и ссылки заранее. Если коллега видит требование, но не может открыть выполнение или вложение, формально существующая трассируемость практически бесполезна для совместного решения.
Ошибки и практический вывод
Типичные ошибки — путать Test Set с планом релиза, считать статус Test результатом прогона и доверять общей зелёной диаграмме без проверки фильтров. Xray не гарантирует полноту покрытия: он показывает данные, которые команда связала и выполнила. Качественный результат — прослеживаемые требования, актуальные Tests и подтверждённые Test Runs на нужной сборке. Тогда QA может объяснить не только «что прошло», но и какие риски ещё остаются перед выпуском.