Система управления тест-кейсами Kiwi TCMS: обзор и опыт использования.

В мире управления тестированием выбрать подходящий инструмент — задача не из легких. В этой статье я хочу поделиться честным опытом работы с открытой системой Kiwi TCMS, рассмотреть ее плюсы и, что не менее важно, критические минусы, а также провести сравнение с альтернативами — Unit.tcms и TestOps.

Начать стоит с того, что Kiwi TCMS — это зрелый open-source проект. Первое, что подкупает — это современный и интуитивно понятный интерфейс.

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

Наличие REST API позволяет интегрировать систему с CI/CD «пайплайнами» и трекерами задач, что является обязательным требованием для современной DevOps-культуры.

Опыт использования: что понравилось.

1. Быстрое создание тест-кейсов. Интерфейс действительно интуитивен. Поля "Предусловия", "Шаги", "Ожидаемый результат" — все под рукой. Можно копировать шаги, дублировать кейсы, использовать простое форматирование текста: жирный, курсив, заголовки и списки. Для этого в редакторе есть панель инструментов, как в обычном текстовом процессоре — выделил текст и нажал кнопку "Жирный" или "Маркированный список". Это очень удобно, когда нужно структурировать сложные сценарии с несколькими условиями или выделить важные предупреждения. Экономит уйму времени при создании регрессионных наборов.

2. Удобное выполнение тест-ранов. Запустить выполнение, отметить кейс как "PASS" или "FAIL", добавить комментарий — все делается в пару кликов. Есть даже возможность выполнять кейсы в разных окружениях (например, Chrome/Firefox, iOS/Android), хотя эта функция реализована не очень гибко.

5. История изменений — находка для командной работы. Это одна из самых полезных функций. В Kiwi TCMS каждый тест-кейс хранит полную историю всех правок. Вы всегда можете зайти в карточку кейса и увидеть:

- Кто именно изменил тест (логин пользователя)

- Когда это произошло (точная дата и время)

- Какие именно поля были изменены (например, "Изменились шаги" или "Поменялся ожидаемый результат")

- Старое и новое значение каждого поля

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

6. Интеграция с автотестами: что можно сделать

У Kiwi TCMS есть REST API, и это открывает возможности для связи с автотестами. Вот что теоретически можно настроить:

- Автоматическая загрузка результатов. Вы можете написать скрипт, который после прогона автотестов в Jenkins или GitLab CI отправляет результаты в Kiwi TCMS через API. Система умеет принимать отчеты в формате JUnit XML, преобразовывая их в тест-раны. Это позволяет видеть все результаты — и ручные, и автоматические — в одном месте.

- Привязка автотестов к существующим кейсам. Можно добавить в код автотеста специальный идентификатор (ID тест-кейса из Kiwi TCMS). Тогда при загрузке результатов система сама найдет нужный кейс и обновит его статус. Это удобно, когда у вас уже есть библиотека ручных тестов, и вы постепенно их автоматизируете.

- Экспорт тест-кейсов для автотестов. Через API можно выгружать тест-кейсы в структурированном виде (JSON или XML) и использовать их для генерации каркасов автотестов. Это экономит время на дублирование шагов.

- Обновление статусов в реальном времени. Если настроить веб-хуки, то при изменении статуса тест-кейса в Kiwi TCMS можно триггерить запуск соответствующих автотестов. Например, если разработчик пометил баг как "исправлен", это может автоматически запустить регрессионный набор.

Конечно, все это требует программирования — готовых "волшебных кнопок" в интерфейсе нет. Но технические возможности для такой интеграции заложены. Это дает гибкость, но требует времени на разработку и поддержку скриптов.

Честный взгляд: недостатки, которые были обнаружены.

Теперь перейдем к тому, о чем обычно умалчивают обзоры.

1. Жесткая иерархия: Продукт → План → Кейс

Это не всегда удобно. Представьте, что у вас большой продукт с множеством модулей. Вам нужно создать тест-план для каждого модуля. А внутри плана — тест-сьюты (группы кейсов по функциональности). В Kiwi TCMS сьюта нет, есть только теггирование и фильтрация.

2. Базовые отчеты и отсутствие глубокой аналитики

Если нужны сложные метрики, графики стабильности тестов, графики покрытия по компонентам, количество открытых дефектов на тест-кейс — Kiwi разочарует.

3. Скудные функции для автоматизации

Kiwi TCMS позиционируется как система для ручного и автоматизированного тестирования, однако здесь есть нюансы. Из коробки нет продвинутых инструментов для генерации автотестов из мануальных кейсов или удобного импорта результатов. Kiwi TCMS не предлагает удобных "фич" для управления flaky-тестами или их владельцами. Если тест упал 3 раза подряд по разным причинам — вы просто увидите три записи FAIL в истории без возможности пометить тест как "ненадежный" или автоматически отправить его на карантин.

Сравнение.

Kiwi TCMS vs Unit.tcms

Если Kiwi TCMS — это "олдскульный" open-source, то Unit.tcms — это новичок с амбициями, который пытается занять нишу TestRail. По отзывам, Kiwi TCMS выглядит более стабильным и функционально наполненным на данный момент. Однако Unit.tcms уже предлагает то, чего не хватает Kiwi — например, более современный подход к интерфейсу и некоторые функции "из коробки", которые в Kiwi требуют доработок. Но Unit.tcms пока сырой: багов больше, документации меньше.

Kiwi TCMS vs TestOps (Allure TestOps)

Здесь сравнение похоже на противостояние ветерана и современного комбайна. TestOps — это надстройка над Allure, которая предлагает принципиально иной подход: ручные и автоматические тесты являются равноправными "гражданами" с общей моделью данных.

Ключевые отличия с точки зрения manual+auto инженера:

- Аналитика. У TestOps (Allure) аналитика на голову выше. Это не просто проценты, а графики того, как меняется процент прохождения от билда к билду, гистограммы по типам дефектов, удобные фильтры для истории выполнения. Ты видишь не просто "FAIL", а детальный отчет с вложениями, логами, шагами выполнения. Это экономит часы при анализе упавших тестов.

- Управление статусами. В TestOps есть гибкая система статусов для флаки-тестов ("под карантином", "ненадежный", "требует переписывания"), что помогает командам принимать решение о готовности к релизу. В Kiwi TCMS такого нет.

- Управление владельцами. TestOps позволяет назначать владельцев тестов для распределения нагрузки. В Kiwi TCMS владелец тест-кейса один, и он не меняется динамически. Если тест упал, ты не знаешь, кто его создавал, чтобы спросить, как он должен работать.

- Цена. Kiwi TCMS бесплатен, а TestOps — это коммерческий продукт с подпиской.

Заключение и опыт использования.

Подводя итог, можно сказать, что Kiwi TCMS — это отличный бесплатный инструмент для небольших и средних команд, которые ищут простое и понятное решение для хранения и выполнения ручных тестов. Его легко развернуть (особенно с Docker), он имеет приятный интерфейс и достаточно API для базовой автоматизации.