Когда мы переходили на очередную систему управления с командой автоматизированного тестирования, в качестве рабочего инструмента у нас была российская TMS TestIt. Мы не занимались ни деплоем, ни конфигурацией, только интенсивно использовали. Сейчас расскажу, на что похожи ощущения.

Системы управления тестированием (они же — TMS) значительно упрощают жизнь команде тестирования. Их десятки разных на рынке. Они нужны для ведения тестовой модели и описания кейсов, их версионирования, интеграции с автотестами и их запуска, сбора данных с них, составления и прохождения тест-планов, формирования разнообразных отчётов.

При большом количестве кейсов (а у нас их несколько тысяч) в тест-плане как автоматизированных, так и ручных тестов без TMS не обойтись.

Именно оптимизация рутины в части вариаций запусков, получение результатов на лету, отказ от Allure и получение единого отчёта дали нам выигрыш во времени, который ежемесячно может предоставить команде пару лишних дней на то, чтобы автоматизировать что-то ещё. Например, чтобы не снижался процент покрытия автотестами при постоянном расширении функционала и появлении новых фич и сервисов.

Зачем нам понадобилась интеграция с TMS

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

Также это даёт возможность сделать прозрачным и понятным процесс и улучшить планы тестирования в будущем.

Ещё из удобств — все тестовые модели, тестовые прогоны, результаты тестов и отчётность находятся в едином пространстве и легко доступны.



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

Почему TestIt

TestIt подходил под наши задачи. Разработан для тестировщиков такими же тестировщиками, имеет русский интерфейс и русскую же поддержку.

TestIt поставляется либо в виде Enterprise-решения, которое разворачивается локально на мощностях клиента, либо в виде облачного SaaS-решения, при этом клиенты не тратят ресурсов на поддержку собственной архитектуры и мощностей. В нашем случае использовалось Enterprise-решение.

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

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

TestIt активно развивается и сейчас имеет библиотеки интеграции для разных языков и платформ.

На момент нашей интеграции такого не было.

Можно работать с наиболее популярными фреймворками: TestNG, Cucumber, JUnit (подключаются через адаптеры). При этом поддерживаются клиентские библиотеки для интеграции с помощью таких языков, как JavaScript, Python, C#. Есть интеграция с Jira, Jenkins, GitHub и другими инструментами.

Сценариями автоматизированных тестов можно управлять через один интерфейс. А их запуск можно осуществлять напрямую из разных разделов.

Удобный функционал работы с тест-планами в запусках и формирование экранов с различными форматами отображения отчётности.



Реализована ролевая модель разграничения доступов.



Гибко, удобно, понятно.

После того как побороли очередную группу плавающих ошибок и стабилизировали результаты запусков имеющихся у нас к тому времени автотестов, решили начать интеграцию нашего проекта с TestIt.

Этапы интеграции, их особенности

Процесс интеграции был разбит на три этапа.

Этап 1

Изучили API TMS. Реализовали привязку автотестов к ручным тестам, запуск из CI по тегам, выгрузку отчётов.

С этого момента наши автотесты линковались с ручными тестами в TestIt. Идентификатор запуска приходилось забирать вручную и отправлять самим запрос на CI. Выгрузка отчётов происходила после завершения всех тестов. Случались и неприятные ситуации, например, прекращение обработки результатов прогона тестов при редактировании плана, по итогу на время прогона пришлось принудительно блокировать план.

Этап 2

Реализовали запуски через вебхуки. Параметризация.

Сразу после появления возможности использования вебхуков настроили параметры запросов до TeamCity и реализовали скрипт для выбранных тестов с возможностью запуска на разных контурах.

Следом обеспечили возможность работы с параметрами, т. е. одни и те же кейсы с различными вариантами значений параметров.

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

Этап 3

Добавили различные плюшки в систему (линки, скриншоты, логи, архивы) для того, чтобы было быстрее и проще анализировать результаты и, в частности, падения.

В итоге получили дополнительную и наиболее приятную возможность запуска тестов из ТestIt.

Преимущества и ограничения автотестов

Одним из преимуществ использования интеграции с TestIt является возможность применять для кейсов различные наборы параметров. Интеграция с ТestIt параметризированных тестов с использованием конфигураций — удобное визуальное представление результатов и гибко настраиваемый запуск вариаций тестов.

Создавать под каждый вариант значений параметров новый кейс (а от их части ещё и отказываться в итоге) нерационально. В TestIt можно создать конфигурации с произвольным числом пар ключ-значение и использовать их для одних и тех же кейсов. Информацию о конфигурациях и их параметрах для запуска параметризированных тестов можно получать из API TMS. Результаты тест-рана обрабатываются и отображаются в разрезе разных конфигураций.

Плюсы и минусы интеграции с TestIt

Ну и в итоге — раздача слонов. Тут вот небольшой списочек из достоинств, которые мы отметили при интеграции с TestIt:

• Простота выбора тестов и их запуска.
• Возможность видеть результаты тестирования не только по завершении полного прогона или после формирования отчёта в Allure, но и в режиме реального времени по мере того, как будут проходить тесты.
• Возможность хранения в одном месте всех отчётов, поскольку всю аналитику можно провести в TestIt. Здесь можно увидеть детальную историю тест-ранов и анализ причин падения. Также доступны сводные отчёты по категориям ошибок.

Что же касается недостатков, то мы в своей работе отметили следующее:

• Проблема использования категорий ошибок и тегов. Мы не смогли воспользоваться этим полезным функционалом из-за того, что они не привязаны к проектам и видны всем внутри TestIt. С этим связан риск их потери или видоизменения.
• Невозможность работы с параметризированными тестами «из коробки».
• Отсутствие группировки тест-планов при хранении и просмотра трендов. Это усложняет сравнение похожих сценариев, чтобы иметь возможность анализа систематических ошибок.

Рекомендации по работе с TestIt

Какие можно дать рекомендации на основании нашего опыта использования такой системы?

Можно выбрать абсолютно любые автоматизированные тесты, добавить к ним нужные конфигурации и параметры и посмотреть, как это работает.

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

Когда нужна TMS и когда без такой интеграции можно обойтись

Никакая система TMS и TestIt, в частности, не решает всех проблем, которые возникают у тестировщиков. Не надо думать, что можно будет целиком избавиться от ручного труда. Какой инструмент тестирования выбрать, зависит от размера команды и её потребностей, срока жизни конкретного проекта. Если вы заточены на использование только ручных тестов, то такая система будет для вас, пожалуй, избыточной.

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

Всё это точно упростит вашу работу и сделает её более эффективной. У нас, по крайней мере, это получилось.