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