Когда мы переходили на очередную систему управления с командой автоматизированного тестирования, в качестве рабочего инструмента у нас была российская 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, в частности, не решает всех проблем, которые возникают у тестировщиков. Не надо думать, что можно будет целиком избавиться от ручного труда. Какой инструмент тестирования выбрать, зависит от размера команды и её потребностей, срока жизни конкретного проекта. Если вы заточены на использование только ручных тестов, то такая система будет для вас, пожалуй, избыточной.
Мне кажется, что эту систему можно порекомендовать таким командам, у которых много тест-кейсов и которые используют одновременно ручные и автоматизированные тесты. Удобство заключается в том, что эта система совмещает всё это в одном интерфейсе.
Всё это точно упростит вашу работу и сделает её более эффективной. У нас, по крайней мере, это получилось.
Автор: Дмитрий Аверянов
