Системы управления тестированием (TMS): QASE, Test IT, TestRail и баг-трекеры

Что такое TMS и зачем она нужна

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

Допустим, приложение доставки выходит раз в две недели на iOS и Android. В TMS под релиз запускают два прогона регрессии, по одному на платформу, и делят кейсы между тестировщиками. Во время прогона видно, сколько кейсов осталось, а если кейс "Оплата картой при оформлении заказа" упал только на Android, дефект заводят прямо из него, со ссылкой на кейс и прогон. Перед релизом менеджер смотрит отчёт по обоим прогонам, и собирать статусы в чате не нужно.

В программе ISTQB Foundation Level инструменты управления тестированием стоят в одном ряду с инструментами управления требованиями, дефектами и конфигурацией и с инструментами непрерывной интеграции. Там же сказано, что TMS обычно связывают с другими инструментами, чтобы прослеживался путь от требования к тесту и к версии продукта.

Навык работы в TMS часто встречается в вакансиях. Стоит освоить хотя бы одну систему, например QASE или TestRail: устроены они похоже, и опыт переносится на любую другую.

Из чего состоит любая TMS

Названия в системах немного отличаются, но набор сущностей почти везде одинаковый. Ниже он описан по QASE, на которой я показываю работу с TMS в уроке.

У самого тест-кейса в QASE много полей, и почти все необязательные. Заголовок отражает суть проверки. По заголовку "Кнопка регистрации" непонятно, что проверяют, внешний вид кнопки или то, как она работает, а "Пользователь регистрируется после нажатия кнопки регистрации" этот вопрос снимает. Статус кейса бывает actual (актуальный), draft (черновик) и deprecated (устаревший). Поле behavior делит проверки на позитивные, негативные и деструктивные, которые проверяют предел возможностей системы: стресс-тест, XSS-инъекция, очень большое тело запроса к API. Флажок flaky помечает нестабильный тест, а отдельное поле показывает, автоматизирован ли кейс.

Шаги пишут в классическом виде или на языке Gherkin, к шагу добавляют входные данные и ожидаемый результат. Параметр кейса, например список браузеров, при запуске прогона превращается в отдельные проверки для Chrome, Opera и Safari, и копировать кейс не нужно.

• Проект

  Отдельное пространство под продукт. Короткий код проекта становится префиксом в номерах кейсов, а доступ настраивают по ролям: кто может создавать и удалять кейсы, а кто только запускать прогоны.

• Репозиторий и наборы

  Хранилище кейсов, разложенных по тестовым наборам (suite). Наборы вкладывают друг в друга: в общий набор "Авторизация" входят вход по почте, по телефону и по QR-коду. В TestRail и Test IT такие папки называются секциями.

• Общие шаги

  Группа шагов, которая повторяется во многих кейсах, например вход в систему. Её описывают один раз и подключают к нужным кейсам.

• Тест-план

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

• Тестовый прогон (test run)

  Запуск кейсов из плана или выбранных вручную. Каждому кейсу ставят статус, например passed, failed, blocked, invalid или skipped, и по упавшему сразу заводят дефект.

• Конфигурации и окружения

  Конфигурации описывают, на чём тестируют: операционные системы, браузеры, эмуляторы. Окружения описывают, где: локальный стенд, dev, stage, продакшен.

• Milestone

  Ключевая точка проекта с датой, например релиз 1.0. К ней привязывают кейсы, прогоны и дефекты.

• Отчёты и дашборды

  Диаграммы по прогонам и виджеты с метриками, по которым менеджмент видит, как идёт тестирование. Для точного поиска в QASE есть свой язык запросов QQL, похожий на JQL в Jira.

• Интеграции

  Связь с баг-трекером, мессенджером и репозиторием кода, например с Jira, YouTrack, Azure DevOps, Slack и GitHub.

• Шпаргалкастатусы тест-кейса в тест-ране

Пример: от тест-кейса до дефекта в QASE

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

• 1. Проект

  Создают проект с названием и кодом T2, коротким описанием и уровнем доступа: приватный или публичный.

• 2. Набор

  В репозитории создают набор Regression test suite. Если нужна иерархия, набору выбирают родителя, и наборы складываются в дерево.

• 3. Тест-кейс

  Кейс "Login under admin" с приоритетом high, видом regression и поведением positive. Шаг "Open the page" с ожидаемым результатом "The page is opened", логин и пароль в поле входных данных. Хранить данные в TMS удобно, но логинам и паролям от продакшена там не место.

• 4. Ревью

  Кейс отправляют на ревью. Рецензент оставляет комментарии и правки, а автор кейса принимает их, как слияние изменений в Git.

• 5. Тест-план

  Создают план Regression for release one и добавляют в него нужные кейсы.

• 6. Прогон

  Запускают новый прогон по этому плану, выбирают исполнителя и тег full regression. Кейсы подтягиваются из плана сами.

• 7. Результаты и дефект

  Одному кейсу ставят passed, другому failed. На failed открывается окно, где можно оставить комментарий, приложить файл и сразу создать дефект. Его заголовок переписывают по правилу "где, что, когда", выбирают severity и исполнителя, и дефект попадает во вкладку Defects.

• 8. Завершение

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

• СтатьяБаг-репорт: заголовок по правилу "где, что, когда"

QASE, Test IT, TestRail и Allure TestOps: чем отличаются

Все четыре системы закрывают основную работу ручного тестировщика: кейсы, наборы, планы, прогоны и отчёты. Различаются они акцентами, и ниже то, что я выделяю в каждой. Цены и условия доступа у всех меняются, поэтому их смотрят на сайте продукта.

• QASE

  Удобна для ревью тест-кейсов и параметров, благодаря которым один кейс прогоняют на нескольких браузерах без копий. Есть конфигурации и окружения, требования, дашборды с виджетами и язык запросов QQL. Дефекты в ней упрощённые и баг-трекер не заменяют, поэтому QASE связывают с Jira, YouTrack или Azure DevOps.

• Test IT

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

• TestRail

  В обзоре 2021 года я назвал её, пожалуй, самым популярным решением для управления тест-кейсами. Кейсы лежат в секциях и подсекциях, у кейса есть шаблон, тип, приоритет и оценка времени. Её большой плюс – интеграция с Jira: в поле References пишут номер задачи, и в Jira видно, какие кейсы к ней привязаны. Отчёты собирают по кейсам, дефектам и прогонам и отдают заказчику в конце итерации.

• Allure TestOps

  Совмещает TMS и TestOps: в одной системе живут ручные кейсы и автотесты, которые запускаются из конвейера CI/CD, а результаты автотестов с логами ошибок смотрят и автоматизаторы, и ручные тестировщики. Прогоны здесь называются лаунчами (launches), шаги бывают с ожидаемым результатом и без него, их можно вкладывать друг в друга. Раньше система была больше заточена под автоматизацию, и в обзоре 2024 года я отметил, что базовые потребности ручного тестирования на проекте она уже закрывает.

• СтатьяCI/CD для тестировщика
• СтатьяАвтоматизация тестирования: с чего начать

Баг-трекеры: Jira, YouTrack и Azure DevOps

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

На проекте это выглядит так. В банковском приложении в Jira заведена пользовательская история "Перевод по номеру телефона", а в TMS к ней привязаны кейсы: перевод себе, другому клиенту банка, на несуществующий номер и сверх дневного лимита. Кейс про лимит падает, потому что перевод проходит, хотя сумма больше лимита. Дефект из прогона уходит в Jira со ссылкой на историю, и, пока он открыт, историю не закрывают как готовую.

Работа в Jira разобрана на странице о баг-репорте. Ещё два трекера я показываю в отдельных обзорах.

• YouTrack

  Трекер и система управления проектами, аналог Jira. Среди типов задач есть эпик, то есть набор ещё не детализированных идей, фича, пользовательская история, задача, баг, тест и улучшение. Задачи связывают между собой (относится к, зависит от, подзадача), ведут на agile-досках со спринтами и бэклогом, а база знаний заменяет вики вроде Confluence. YouTrack я выбрал для практики на своём групповом курсе.

• Azure DevOps

  Платформа Microsoft, где собраны доски задач и спринты, Git-репозитории, конвейеры сборки, требования и баг-репорты. Тест-кейсы ведут в модуле Test Plans: планы, наборы, кейсы и общие наборы параметров. Если логин для тестов поменялся, его правят в наборе параметров, и он обновляется во всех кейсах. Во вкладке Execute результат отмечают сразу у нескольких кейсов, а баг из прогона связывают с пользовательской историей. Azure DevOps любят компании, у которых вся работа построена на сервисах Microsoft вроде Teams и SharePoint, и я работал в нём на двух местах работы.

• СтатьяБаг-репорт: пример в Jira, severity и priority
• СтатьяAgile, Scrum и Kanban для тестировщика

Видеоуроки, шпаргалки и задания

QASE я подробно разбираю в отдельном обзоре на YouTube: проект, наборы, кейсы, ревью, тест-планы, прогоны, дефекты и дашборды. Своим обзорам посвящены Test IT, Allure TestOps, Azure DevOps и YouTrack, а TestRail я показываю в ролике об инструментах тестировщика вместе с программами для скриншотов и схем. В бесплатном базовом курсе по тестированию тема идёт уроком "QASE. Обзор функций", и после теории в нём есть задания.

Шпаргалка о статусах тест-кейса объясняет, что значат Passed, Failed, Blocked и Skipped в тест-ране, а шпаргалка о жизненном цикле бага проводит дефект по статусам трекера. В тренажёре нужно написать тест-кейс, по которому пройдёт другой человек.

• Урок курсаЭтот урок с заданиями – бесплатно
• Мой видеоурокQASE, обзор TMS для тестировщика
• Мой видеоурокобзор функций Test IT
• Мой видеоурокTestRail и другие инструменты тестировщика
• Мой видеоурокбольшой обзор Allure TestOps
• Мой видеоурокAzure DevOps для тестировщика
• Мой видеоурокYouTrack, обзор функций для тестировщика
• Шпаргалкастатусы тест-кейса
• Шпаргалкатест-кейс
• Шпаргалкажизненный цикл бага
• Тренажёртест-кейсы
• СтатьяЧек-лист и тест-кейс: разница и пример
• СтатьяПроцесс тестирования с нуля

Курсы по теме

• бесплатный

  Тестирование ПО с нуля. Теория + Практика. Базовый уровень

  Первое рабочее место тестировщика

  89 уроков113 441

Вопросы и ответы