Что такое система управления тестированием

Система управления тестированием (test management system, TMS) - программа для планирования, учёта и контроля тестирования. Она хранит тест-кейсы, объединяет их в наборы, выполняет их в тестовых прогонах, записывает результат каждого выполнения и связывает тесты с требованиями, дефектами и автотестами. В глоссарии ISTQB этот класс программ называется инструментом управления тестированием (test management tool): инструментом, который поддерживает управление тестированием и контроль хода процесса тестирования.

Стандарта, который определял бы, из чего обязана состоять система управления тестированием, нет. Словарь её сущностей взят из глоссария ISTQB и из серии стандартов тестирования ISO/IEC/IEEE 29119: её часть 3 (документация тестирования, текущая редакция 2021 года) описывает документы, которые создаёт процесс тестирования. Системы различаются названиями и деталями, но основные сущности и связи между ними в большинстве из них одинаковы.

Какую задачу решает система управления тестированием

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

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

• один и тот же тест выполняется много раз, а таблица хранит либо описание, либо историю результатов, но не то и другое в виде, по которому можно делать выборки;
• несколько тестировщиков одновременно работают с одним набором тестов, и правки конфликтуют;
• упавшему тесту нужна ссылка на дефект, а дефекту - обратная ссылка на тест и на сборку, где он найден;
• руководителю нужны показатели хода тестирования во время работы, а не после неё, и собирают их вручную;
• вопросы вроде «какие требования проверены на сборке 2.4.1» или «когда этот тест последний раз проходил» требуют поиска по многим файлам.

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

Основные сущности

Сущности ниже есть в большинстве систем управления тестированием. Названия у них разные: тестовый прогон называют также выполнением (test execution) или циклом (test cycle), набор тестов - папкой или разделом.

Тест-кейс и набор тестов

Тест-кейс (test case) - единица описания тестов. Глоссарий ISTQB определяет его как совокупность предусловий, входных данных, действий, ожидаемых результатов и постусловий, разработанную на основе условий тестирования. В системе управления тестированием у тест-кейса есть идентификатор, название, содержание (предусловия, шаги, ожидаемые результаты) и атрибуты: приоритет, статус, автор, теги, пользовательские свойства.

Набор тестов (test suite) объединяет тест-кейсы. Глоссарий ISTQB определяет набор тестов как совокупность тестовых сценариев или тестовых процедур, которые выполняются в определённом тестовом прогоне. Системы управления тестированием обычно понимают это слово шире - как любую именованную группу тест-кейсов: по функции («Оформление заказа»), по компоненту («Платёжный API») или по назначению («Smoke-тесты»). Наборы часто вкладываются друг в друга и образуют дерево.

Тестовый прогон и результат теста

Тестовый прогон (test run) - однократное выполнение выбранного набора тест-кейсов. Прогон фиксирует, что тестировалось (версия или сборка продукта), где (окружение: операционная система, браузер, устройство, конфигурация) и когда. В прогоне по одному результату на каждый включённый в него тест-кейс.

Результат теста относится к одному тест-кейсу и одному прогону. В нём статус (например, пройден или не пройден), фактический результат, комментарии, вложения - снимки экрана и журналы, затраченное время и исполнитель. Непройденный результат связывается с дефектом.

Разделение тест-кейса и результата - центральная идея модели данных. Тест-кейс - спецификация, которая меняется редко. Результат - факт об одном выполнении. У одного тест-кейса со временем накапливается много результатов:

Test case TC-12 "Pay with a saved card"
 |
 +-- Run "Release 2.4.0, Chrome"   -> passed
 +-- Run "Release 2.4.0, Safari"   -> failed  -> Defect BUG-310
 +-- Run "Release 2.4.1, Safari"   -> passed  (confirmation of the fix)

Тест-план

Тест-план описывает, что будет тестироваться, как, кем и когда. В одних системах это документ, прикреплённый к проекту. В других - сущность, которая объединяет несколько тестовых прогонов, например все прогоны одного релиза в разных окружениях, и показывает их общий ход. Назначение документа и его состав по ISO/IEC/IEEE 29119-3 описаны в статье Тест-план и тестовая стратегия.

Дефект и требование

Дефект, в формулировке глоссария ISTQB, - изъян или недостаток рабочего продукта, из-за которого он не соответствует своим требованиям или спецификациям. В системе управления тестированием дефекты либо хранятся как собственная сущность, либо ведутся во внешнем баг-трекере и связываются по идентификатору. В обоих случаях связь двусторонняя: от результата к дефекту и от дефекта к тест-кейсу, прогону и сборке.

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

Как связаны сущности

Схема показывает связи между основными сущностями. Стрелка читается как «содержит» или «связан с».

Project
 |
 +-- Test suites --- contain ---> Test cases <--- linked ---> Requirements
 |                                   |
 +-- Test plan --- groups ---> Test runs
                                     |
                                     +-- Test results (one per test case in the run)
                                              |
                                              +-- linked ---> Defects

В большинстве систем управления тестированием есть и пользовательские свойства (custom properties) - поля, которые команда задаёт сама для тест-кейсов, прогонов или результатов, например «Компонент», «Платформа» или «Уровень риска». Пользовательские свойства используются для фильтрации, отчётов и сопоставления данных между системами.

Роли

Силлабус ISTQB Foundation Level (версия 4.0.1) выделяет две основные роли в тестировании. Роль управления тестированием (test management role) отвечает за процесс тестирования в целом: планирование, мониторинг и контроль, завершение. Роль тестирования (testing role) отвечает за техническую сторону: анализ, проектирование, реализацию и выполнение тестов. Обе роли может выполнять один человек, а в гибких командах часть задач управления тестированием берёт на себя команда.

В системе управления тестированием этим ролям соответствуют разные наборы действий:

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

Процесс тестирования в системе управления тестированием

Силлабус ISTQB делит процесс тестирования на активности. Каждая создаёт рабочие продукты, которые система управления тестированием хранит или вычисляет.

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

Автотесты и CI

Автотесты - это код. Они хранятся в репозитории кода и запускаются в системе непрерывной интеграции (continuous integration, CI) при каждом изменении. Система управления тестированием не заменяет тестовый фреймворк и систему CI. Она получает результаты запусков автотестов и хранит их вместе с результатами ручного тестирования.

Типичный поток данных:

Code repository --> CI pipeline --> Test framework --> Report file
                                                          |
                                                          v
                                        Test management system: test run with results

Самый распространённый формат обмена - JUnit XML. Его распространил проект JUnit, и его поддерживают большинство тестовых фреймворков, систем CI и систем управления тестированием. Официальной спецификации формата нет, и инструменты создают немного разные его варианты. Основная структура при этом устойчива:

<?xml version="1.0" encoding="UTF-8"?>
<testsuites name="checkout" tests="3" failures="1" errors="0" skipped="1" time="4.21">
  <testsuite name="Checkout.Payment" tests="3" failures="1" errors="0" skipped="1" time="4.21">
    <testcase classname="Checkout.Payment" name="pay_with_saved_card" time="1.62"/>
    <testcase classname="Checkout.Payment" name="pay_with_expired_card" time="2.59">
      <failure message="Expected error message was not shown" type="AssertionError"/>
    </testcase>
    <testcase classname="Checkout.Payment" name="pay_with_gift_card" time="0">
      <skipped message="Gift cards are disabled in this environment"/>
    </testcase>
  </testsuite>
</testsuites>

Элемент testcase без вложенного элемента - пройденный тест. failure означает, что не прошла проверка в тесте, error - непредвиденную проблему при выполнении, skipped - что тест не выполнялся.

Чтобы связать автотест с тест-кейсом в системе, его результату нужен идентификатор, известный обеим сторонам. Обычные варианты - полное имя теста (classname и name), идентификатор тест-кейса в имени или в свойстве теста, или таблица соответствия, которую ведёт система. Кроме импорта файлов, системы управления тестированием предоставляют API, через который задача CI создаёт прогон и отправляет результаты напрямую.

Как автотесты распределяются по уровням, описано в статье Уровни автоматизации и пирамида тестов. Как они запускаются в CI и как их результаты попадают в тестовые прогоны, описано в статье Автотесты в CI.

Система управления тестированием, баг-трекер и таск-трекер

Система управления тестированием часто работает вместе с баг-трекером и таск-трекером, и их функции частично пересекаются.

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

Баг-трекер может хранить тест-кейсы как особый тип задачи, и некоторые команды так и делают. Тогда каждое выполнение записывается либо как изменение задачи, и история прежних результатов теряется, либо как отдельная задача, и тесты смешиваются со своими результатами. Система управления тестированием моделирует тест-кейс, прогон и результат как отдельные сущности, поэтому история каждого теста и состояние каждого прогона доступны для выборок напрямую.

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

Термины

Источники

• ISTQB Certified Tester Foundation Level Syllabus v4.0.1, ISTQB, 2024(откроется в новой вкладке) (на английском)
• Глоссарий ISTQB(откроется в новой вкладке) (на английском)
• ISO/IEC/IEEE 29119-3:2021, Software testing, Part 3: Test documentation(откроется в новой вкладке) (на английском)
• Common JUnit XML format and examples, Testmo(откроется в новой вкладке) (на английском)