Где мы находимся и куда идем? Делаем процесс тестирования прозрачным с Klaros TMS16.01.2023 18:16

Для руководителя отдела тестирования важно иметь актуальную информацию об используемых тестовых кейсах, временных затратах на их выполнение, ретроспективную статистику о количестве и успешности прохождения ручных тестов (и, в идеальной ситуации, еще и автоматически извлекать результаты выполнения автоматических тестах в 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

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

Для запуска Klaros TMS мы будем использовать Docker-образ (также доступны установочные файлы для Windows и Linux), для этого склонируем проект с Github и соберем новый образ (будет необходимо установить Docker на Linux или Docker Desktop на Windows / MacOS):

git clone https://github.com/klaros-testmanagement/klaros-docker
cd klaros-docker/ApacheDerby
docker build -t klaros .
docker run -d --name Klaros -p 18080:18080 -v klaros-data:/data klaros

После запуска веб-приложение Klaros TMS будет доступно по адресу http://localhost:18080, для первого входа можно использовать имя пользователя и пароль admin/admin.

Прежде всего начнем с создания проекта:

Создание нового проекта в Klaros TMS Создание нового проекта в Klaros TMS

После создания проекта можно добавить интеграции с системами управления задачами (issue tracker), например поддерживаются Jira, Github, Gitlab и другие:

Интеграция с Issue Tracker Интеграция с Issue Tracker

Дальше выбираем активный проект (круглый значок справа от названия проекта) и теперь становятся доступными возможность исполнения тестов и получения отчетов о тестировании. Затем определим систему, которую будем тестировать (в нашем случае это будет консольный калькулятор), 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.

Jetbrains Local TMS

Подход Local TMS подразумевает хранение данных о плане и результатах тестирования непосредственно с исходными кодами приложений в виде Markdown-файлов и он поддерживается в Jetbrains IDE с использованием плагина Test Management (сейчас в статусе эксперимента, в документации обозначено, что формальная спецификация еще не готова и форматы файлов могут изменяться). Для использования Local TMS после установки плагина необходимо разрешить поддержку Markdown для тестов: Preferences → Tools → TMS → Markdown.

Определение тестов начинается с определения Test Suite (File → New → Test Suite). Создается файл name.t.md, в котором определяются тэги, тест-кейсы и шаги выполнения теста, например:

# Calculator
Tags: calculator
Meta: app = calculator

## Проверка калькулятора
* Test subtraction
    * Проверить вычитание 12-2=10
    * Проверить вычитание 18-21=-3
    * Проверить вычитание 24-24=0

Для определения результатов выполнения тестов необходимо создать файл с отчетом (File → New → Test Case, выбрать соответствующие тесты) и добавить в соответствующие шаги тестирования метки [ok] при успешном выполнении или [fail] при возникновении ошибки.

# test2

* [fail] Test subtraction
    * [ok] Проверить вычитание 12-2=10
    * [ok] Проверить вычитание 18-21=-3
    * [fail] Проверить вычитание 24-24=0

Также могут быть указаны дополнительные метаданные,

например с @ можно добавить логин тестировщика. Для просмотра истории прохождения тестов можно использовать панель View → Tool Windows → TMS, также оттуда можно выполнить связывание тестового кода и тест-кейсы (New Test for Test Cases в контекстном меню), после которого создается заготовка функции тестирования и комментарии для шагов теста:

Local TMS

class Sub {
    //
    @Test
    fun Test_subtraction() {
        // Проверить вычитание 12-2=10
        assertEquals(10, sub(12,2))
        // Проверить вычитание 18-21=-3
        assertEquals(-3, sub(18,21))
        // Проверить вычитание 24-24=0
        assertEquals(0, sub(24,24))
    }

Тест может быть привязан к соответствующему тестовому сценарию, для этого необходимо определить класс-аннотации и использовать эту аннотацию, вместе с идентификатором тест-кейсы (будет записан как последовательность цифр, записанная в md-определении тест-кейсы в ## перед основным описанием, например ## 1 Test subtraction можно будет адресовать как C1):

annotation class LocalTMS(val value:String)

...
@Test
@LocalTMS("C1")
fun Test_subtraction() {
//...
}

Мы рассмотрели два подхода к созданию TMS: бесплатную версию Klaros TMS (может использовать как автономный инструмент для описания тест-кейсов и сопровождения релизов при организации работы команды тестировщиков как при автоматическом, так и при ручном тестировании) и новый подход к интеграции тест-кейсов и отчетов о тестировании, который организуется непосредственно в исходном коде проекта и использует привычные для разработки и тестирования практики управления версиями и навигации по исходному коду.

В заключение приглашаю всех на бесплатное занятие от моих друзей из OTUS по методам тестирования требований. На этом уроке:

Изучим конкретные практики тестирования требований.
Рассмотрим использование User Story и критериев приемки для тестирования бизнес-требований.
Рассмотрим, как выстраивается процесс тестирования требований в Agile командах.

Зарегистрироваться можно по ссылке.