Когда тест-кейсов десяток, их можно хранить хоть в таблице. Когда их сотни, а прогонов много и команда не одна, нужна специальная система — инструмент тест-менеджмента. Это как трекер, только не для багов, а для тест-кейсов и результатов их прохождения.
Самые известные — TestRail, Qase, Zephyr (последний живёт внутри Jira), есть и другие, попроще и бесплатные. Логика у всех одна, поэтому, освоив один, легко перейти на другой. Разберём, что они дают и как в них устроена работа.
Кейс лежит в наборе, прогон берёт набор на конкретной сборке и вешает на каждый кейс отметку. Упавший кейс тянет за собой ссылку на баг — и связь читается в обе стороны: из карточки кейса видно, в какой сборке он упал и каким дефектом это закрыто, из бага — какой проверкой он найден. Итог прогона система считает сама, по отметкам: «заблокирован» стоит в отчёте отдельной строкой от «упал» — там дефекта нет, там проверять было нечем.
Зачем отдельная система
Хранить кейсы в текстовом документе или Excel можно, но быстро становится больно:
- Непонятно, что уже проверено на этой версии, а что нет.
- Нельзя удобно отметить результат каждого кейса (прошёл / упал / заблокирован) и получить сводку.
- Тяжело вести историю: как этот кейс проходил в прошлых прогонах.
- Неудобно работать вдвоём-втроём над одним набором.
Система тест-менеджмента закрывает всё это разом.
Как устроена работа
Три главных понятия, и они уже знакомы:
- Тест-кейс — карточка проверки с шагами и ожидаемым результатом. Кейсы складывают в разделы/сьюты (например, «Регистрация», «Оплата») — это тест-сьюты.
- Тест-ран (прогон) — берёте набор кейсов и проходите его на конкретной сборке. По каждому кейсу ставите результат: Passed (прошёл), Failed (упал, обычно тут же ссылаетесь на заведённый баг), Blocked (нельзя проверить), Skipped (пропущен).
- Отчёт — система сама показывает итог прогона: сколько прошло, сколько упало, динамику по времени. Это удобный ответ на вопрос «можно ли выпускать».
Типичный день: открываете запланированный ран «Регресс. Оплата», идёте по кейсам, отмечаете результаты, на упавших заводите баги в трекере и привязываете их к кейсам.
Связка с баг-трекером
Тест-менеджмент и баг-трекер — соседи, которые дружат. Кейсы и прогоны живут в TestRail или Qase; баги — в Jira. Когда кейс упал, вы заводите баг в трекере и связываете его с кейсом. Потом по кейсу видно, какие баги он ловил, а по багу — каким кейсом он найден. Zephyr удобен как раз тем, что живёт прямо внутри Jira, так что связка получается совсем бесшовной.
Осваивать ли конкретный инструмент заранее
Заранее — не обязательно: на работе покажут тот, что принят в команде, и это дело пары дней. Важнее понимать механику кейс → прогон → отчёт: инструменты рисуют её по-разному, но делают одно и то же. У Qase и TestRail есть бесплатные пробные версии — за вечер можно завести пару кейсов и прогон и пощупать вживую.
Где это применяется
На сколько-нибудь серьёзном проекте такая система — общая память команды: что проверено на этой сборке и чем закончился прошлый регресс.
Где спотыкаются чаще всего:
- Путают тест-менеджмент и баг-трекер. Кейсы и прогоны — в одном, баги — в другом; они связаны, но это разные вещи.
- Не отмечают результаты прогона аккуратно, и потом непонятно, что реально проверено: отчёт считается по отметкам, а не по памяти.
- Не связывают упавший кейс с багом — история кейса обрывается, и в следующем прогоне никто не помнит, почему он красный.
Коротко
- Тест-менеджмент хранит кейсы, прогоны и результаты; баг-трекер — дефекты. Это разные системы, и они связаны.
- Прогон — это набор кейсов плюс конкретная сборка плюс отметки; без номера сборки результат не к чему привязать.
- «Заблокирован» — не «упал»: проверить было нечем, дефекта у кейса нет, и в отчёте это отдельная строка.
- Связь кейс — баг работает в обе стороны: из кейса видно, какие дефекты он ловил, из дефекта — какая проверка его нашла.
- Отчёт система считает сама, по проставленным отметкам: непроставленный результат означает «неизвестно».
Что почитать дальше
- Как писать тест-кейс — из чего состоит карточка, которая попадает в набор.
- Тест-план и тест-сьюты — как собирают наборы под цель прогона и когда прогон считается законченным.
- Жизненный цикл бага и трекеры — что дальше происходит с дефектом, на который сослался упавший кейс.
- Отчёт о тестировании и метрики — какие числа из прогонов что-то значат, а какие нет.