Для руководителя отдела тестирования важно иметь актуальную информацию об используемых тестовых кейсах, временных затратах на их выполнение, ретроспективную статистику о количестве и успешности прохождения ручных тестов (и, в идеальной ситуации, еще и автоматически извлекать результаты выполнения автоматических тестах в CI/CD), а также иную документацию о процессе тестирования и его результатах и эта потребность была реализована в системах управления тестированием (Test Management System, далее TMS). Н на рынке представлено большое количество коммерческих решений TMS (таких как TestRail, PractiTest, Zephyr Squad for Jira, XQual, Qase, Testiny), которые иногда также покрывают задачи управления требованиями, релизами и оценкой соответствия установленным KPI. В этой статье мы рассмотрим основы использования Klaros TMS (которая может использоваться бесплатно в Community-версии) и поговорим о подходах Local TMS, которые предлагаются Jetbrains. Основная задача системы управления тестированием - подготовка формального описания тест-кейсов, определение зависимостей между тест-кейсами, созданию тестовых наборов для различных видов тестирования (например, регрессионных или смоук-тестов), управление исполнением тестового кода (или редактирование результатов при выполнении ручного тестирования) и накопление результатов прохождения тестов. Обычно TMS поддерживает управление несколькими проектами и предоставляет набор инструментов командной строки и/или API для получения отчетов и управления результатами тест-кейсов. Дополнительно TMS может выполнять привязку тест-кейсов к расписанию релизов, генерировать отчеты о результатах выполнения тестов (например, графики процента успешного выполнения от времени или список обнаруженных дефектов), в некоторых случаях также поддерживаются списки задач и управление релизной документацией (создание отчета о тестировании, регистрация сообщений об ошибках от пользователей). Значительная часть TMS являются коммерческими или облачными решениями по подписке, либо поддерживают бесплатную функциональность с ограничениями (например, Qase или Testiny). Мы рассмотрим некоммерческий продукт Klaros TMS Community Edition, который может быть установлен на серверах организации и использоваться без ограничений. Функционально Klaros TMS обеспечивает основной процесс тестирования и может использоваться как альтернатива TestRail. В некоммерческой версии не поддерживается работа с требованиями и тестовым покрытием, нельзя выполнять планирование запуска тестов и управление проектами. При этом все необходимые функции для управления тест-кейсами, исполнением тестов и сохранением отчета о тестировании, подготовки отчетов будут доступны. Для запуска Klaros TMS мы будем использовать Docker-образ (также доступны установочные файлы для Windows и Linux), для этого склонируем проект с Github и соберем новый образ (будет необходимо установить Docker на Linux или Docker Desktop на Windows / MacOS): После запуска веб-приложение Klaros TMS будет доступно по адресу http://localhost:18080, для первого входа можно использовать имя пользователя и пароль admin/admin. Прежде всего начнем с создания проекта: После создания проекта можно добавить интеграции с системами управления задачами (issue tracker), например поддерживаются Jira, Github, Gitlab и другие: Дальше выбираем активный проект (круглый значок справа от названия проекта) и теперь становятся доступными возможность исполнения тестов и получения отчетов о тестировании. Затем определим систему, которую будем тестировать (в нашем случае это будет консольный калькулятор), Define → Systems Under Test → New. Дальше создадим Test Case: Define → Test Cases → New. При определении тест-кейса можно дополнительно уточнить приоритет (низкий - средний - высокий), статус (черновик, утвержден или временно пропущен), как будет выполняться тест (Manual / Automatic). Сейчас мы создадим два теста - автоматический тест на сложение чисел и ручной тест на вычитание, для возможности редактирования тесты должны быть созданы в статусе “Draft”, который перед запуском тестов нужно будет заменить на “Approved” Для ручного теста нужно будет также заполнить карточку тест-кейса и обозначить предварительные и постусловия, ожидаемый результат, описание шагов выполнения, ссылка на документацию. К созданному тесту в дальнейшем могут быть добавлены issues (созданные из приложения или связанные с внешними системами). Тестовые кейсы могут быть объединены в тестовые наборы (Define → Test Suite → New) Далее попробуем запустить ручной тест, для этого перейдем в Execute → Run Test Case и выберем действие “Execute”. Последовательно для каждого шага теста будет отображаться диалог с возможностью отметить результат прохождения теста (успех-провал) и при неуспешном выполнении дополнительно загрузить вложения (логи, скриншоты) и текстовое описание фактического поведения.  По итогам прохождения теста может быть создан issue (также может быть передан во внешнюю систему учета тикетов).  При запуске автоматического теста будет необходимо загрузить машинно-читаемый файл с результатами исполнения теста и уточнить, какой формат файла был использован и в каком тестовом окружении был запущен тест. Klaros поддерживает большое количество тестовых фреймворков, включая *Unit (формат JUnit XML), ctest, GoogleTest, JMeter, Fitnesse, Valgrind и другие.  Вся история запуска тестов сохраняется и может быть получена в виде HTML/PDF отчета (Evaluate → Reports) по System Under Test, Test Suite, Test Run History. Также может быть получена статистика по запуску тест-кейсов Evaluate → Test Case Results, запуску тестов, статистика по Test Suite. Также представлена общая информация по активному проекту на панели Evaluate → Dashboard. Подход Local TMS подразумевает хранение данных о плане и результатах тестирования непосредственно с исходными кодами приложений в виде Markdown-файлов и он поддерживается в Jetbrains IDE с использованием плагина Test Management  (сейчас в статусе эксперимента, в документации обозначено, что формальная спецификация еще не готова и форматы файлов могут изменяться). Для использования Local TMS после установки плагина необходимо разрешить поддержку Markdown для тестов: Preferences → Tools → TMS → Markdown.  Определение тестов начинается с определения Test Suite (File → New → Test Suite). Создается файл name.t.md, в котором определяются тэги, тест-кейсы и шаги выполнения теста, например: Для определения результатов выполнения тестов необходимо создать файл с отчетом (File → New → Test Case, выбрать соответствующие тесты) и добавить в соответствующие шаги тестирования метки [ok] при успешном выполнении или [fail] при возникновении ошибки. Также могут быть указаны дополнительные метаданные,  например с @ можно добавить логин тестировщика. Для просмотра истории прохождения тестов можно использовать панель View → Tool Windows → TMS, также оттуда можно выполнить связывание тестового кода и тест-кейсы (New Test for Test Cases в контекстном меню), после которого создается заготовка функции тестирования и комментарии для шагов теста: Тест может быть привязан к соответствующему тестовому сценарию, для этого необходимо определить класс-аннотации и использовать эту аннотацию, вместе с идентификатором тест-кейсы (будет записан как последовательность цифр, записанная в md-определении тест-кейсы в ## перед основным описанием, например ## 1 Test subtraction можно будет адресовать как C1): Мы рассмотрели два подхода к созданию TMS: бесплатную версию Klaros TMS (может использовать как автономный инструмент для описания тест-кейсов и сопровождения релизов при организации работы команды тестировщиков как при автоматическом, так и при ручном тестировании) и новый подход к интеграции тест-кейсов и отчетов о тестировании, который организуется непосредственно в исходном коде проекта и использует привычные для разработки и тестирования практики управления версиями и навигации по исходному коду. В заключение приглашаю всех на бесплатное занятие от моих друзей из OTUS по методам тестирования требований. На этом уроке: Изучим конкретные практики тестирования требований. Рассмотрим использование User Story и критериев приемки для тестирования бизнес-требований. Рассмотрим, как выстраивается процесс тестирования требований в Agile командах. Зарегистрироваться можно по ссылке.  Flutter Developer@YandexPro, DevOps, IT Architect