Привет, Хабр! Меня зовут Анна Асабина, я занимаюсь тестированием бэкэнда доменного направления в Рунити. В этой статье мы затронем основные понятия Test Management System и поговорим о плюсах и минусах внедрения TMS в проект. Также решим, какие важные черты должны присутствовать в качественной TMS. И, конечно же, я расскажу о нашем пути к TestRail: как внедряли и на каких конкретных примерах используем.
Навигация по тексту:
↪ Особенности качественных TMS
→ TestRail
↪ Особенности внедрения TestRail
↪ Структура тест-кейса в TestRail
↪ Что такое TestRun в TestRail
Основные понятия
Что такое TMS?
Test Management System — это программное обеспечение, которое может как быть десктопным, так и иметь мобильные и веб-версии. Основная задача — управление процессом тестирования ПО или любой веб-разработки. От хорошей системы ожидается плавная интеграция в процессы, хранение ручных кейсов, возможность интегрирования автотестов и хранение всех соответствующих артефактов. Также важна интеграция со всеми необходимыми инструментами, такими как Selenium для автоматизации, Git или системами снятия метрик.
Плюсы внедрения TMS
Ключевое преимущество Test Management System заключается в централизации. Вся документация будет храниться в одном месте, её не придётся искать по различным источникам. Это упрощает процесс внедрения сложных кейсов, проведение регресса и онбординг. Поскольку всё хранится в одном месте, ссылаться на эту документацию становится значительно проще.
Также улучшается организация хранения. Исходя из первого пункта, документация у нас находится в одном месте. Это значит, что её легче поддерживать, делать декомпозицию и расписывать какие-то конкретные тестовые случаи. TMS облегчает процесс тестирования, поскольку все результаты и прогресс находятся в одной системе. К ним всегда можно обратиться, продолжить тестирование, обновить статус или повторить тестовый набор, выполненный в предыдущей итерации.
Test Management System доступна не только тестировщикам, но и всей команде. Таким образом обеспечивается прозрачность процессов тестирования, благодаря чему совместная работа становится более удобной. Тестирование не становится чем-то, что работает «само по себе»: можно показать процесс, и в случае неочевидных или пропущенных дефектов понять, какие кейсы стали «узким местом». Это позволяет модифицировать процесс тестирования и улучшать его в дальнейшем, работая над ошибками.
Большинство современных TMS предлагают красочные графики и различные отчёты, которые хорошо отражают весь процесс. Они отлично смотрятся в презентациях и митапах, а также всегда есть, что показать заказчику — и для него они будут понятными и иллюстративными.
Если на проекте уже есть автоматизация, то интеграция TMS с поддержкой автотестов позволит смотреть прогоны в одном месте. Это облегчает тестирование и экономит время на все процессы, включая проведение регресса и последующий анализ.
Минусы внедрения TMS
Минусы внедрения Test Management System напрямую вытекают из плюсов. В первую очередь, лицензии на большинство TMS довольно дорогие. Кроме того, внедрение любого нового и сложного инструмента подразумевает обучение команды. Это может повлечь за собой необходимость покупки курсов и выделения дополнительного времени на изучение программы, что повлияет на общие процессы разработки.
Переход на новую TMS или её внедрение с нуля — сложный процесс. Предстоит понять, сможет ли система легко интегрироваться и работать в связке с уже существующими на проекте инструментами. Например, внедрение автоматического тестирования может повлечь за собой сложности с настройкой окружения и интеграцией.
Также важен психологический аспект — возможное сопротивление команды. В налаженные процессы начинается внедрение нового продукта, который далеко не сразу принесет очевидную пользу. Когда команда привыкает к использованию определенного инструмента — например, Qase, — она довольно болезненно воспринимает отказ от старого продукта. В такой ситуации сложно привыкнуть к чему-то новому, даже если TMS отвечает всем требованиям разработчиков и тестировщиков. Нужно подобрать совместимый со всем существующим окружением инструмент и настроить отчёты с нуля. Это может повлиять на общую скорость разработки и тестирования. Неправильная настройка метрик или автотестов может нанести вред проекту, поэтому к процессу нужно подходить с определенной долей экспертизы.
Особенности качественных TMS
Мы уже упомянули, что ожидаем от хорошей TMS простоту установки и поддержку со стороны разработчиков. Система должна предлагать стандартную модель управления версиями тестовых артефактов и широкую интеграцию с внешними сервисами — например, Jira, Git и другими. Интерфейс должен быть простым, понятным и дружелюбным, чтобы любой новый тестировщик мог разобраться с проведением ручных тестов, автотестов и другими функциями. Также важна гибкая настройка различных параметров — например, ролей и доступов. Забегая вперёд, скажу, что выбранная нами TMS соответствует всем перечисленным условиям.
Сравнение популярных TMS
Прежде, чем мы перейдём к TestRail, сделаем небольшой обзор на популярные на рынке TMS. В целом, эти системы — аналоги друг друга. Компании выбирают подходящую в соответствии со своими предпочтениями и возможностями. Сравним их по определенному списку параметров: предлагаемые фичи, возможности интеграции, цена, пользовательский интерфейс и техподдержка. Красным цветом на схеме выделены те моменты, которые показались мне критическими.
У меня есть личный опыт работы с некоторыми из этих TMS — например, я настраивала Allure TestOps. Система предлагает довольно красивые отчёты, а также имеет функционал для работы как с ручными тестами, так и с автотестами. Многие TMS по показателям выше выглядят практически идеальными — например, Qase и Zephyr. Что касается TestRail, то мы (и многие другие пользователи) отмечаем довольно «перемудрённый» интерфейс. Однако это не критичная черта — несмотря на то, что он не выглядит современным на фоне других продуктов, разобраться с ним довольно просто. TestRail — «зрелый» продукт, который используется во многих крупных компаниях: отчасти это было нашим критерием выбора.
Интеграция у всех TMS примерно одинаковая: сервисы плюс-минус похожие, поэтому подробно останавливаться на этом моменте не буду. Если говорить о стоимости, то здесь есть решения на любой вкус и кошелёк. Например, Allure TestOps и Azure TestOps — довольно дорогие системы. Остальные, попавшие в наш список сравнения, отличаются более демократичными расценками. И также не стоит забывать, что некоторые TMS ушли с российского рынка — например, Qase. Поэтому при выборе системы следует в первую очередь выяснить, доступна ли она в нашей стране.
TestRail
Наш путь к TestRail
В момент моего прихода в компанию TestRail уже был частично внедрён: мои коллеги перенесли основные кейсы и вели активное тестирование в некоторых проектах через эту TMS. Однако работы по полноценному развертыванию системы предстояло ещё много. Сейчас же внедрение TestRail практически завершено, и работа с этой системой становится привычной во всех командах.
До перехода на TestRail мы пользовались Qase. Сейчас эта система, к сожалению, недоступна пользователям из России. В целом, это и стало решающим фактором для перехода на другую TMS. Сейчас мы полностью довольны TestRail и считаем его мощным инструментом для наших задач. Причины выбора в пользу именно этой TMS такие:
-
TestRail — почти полный аналог Qase;
-
работает в России;
-
зрелый и известный продукт, который выбирают многие крупные мировые компании;
-
активно поддерживается разработчиками и получает регулярные обновления;
-
присутствует интеграция со всеми необходимыми для нас сервисами;
-
в нашей компании есть качественная экспертиза по настройке и использованию инструмента.
Особенности внедрения TestRail
Процесс внедрения TestRail в наши рабочие процессы был довольно долгим и разделялся на несколько этапов. У нас была подготовительная часть, в ходе которой мы провели анализ текущих тест-кейсов на наших проектах. Изучили структуру и формат тест-кейсов из предыдущей TMS. Из них уже выбирали, какие нужно переносить в TestRail, а какие — нет. С этой информацией мы подошли к подготовке данных. Их мы частично экспортировали из старой TMS и загрузили в новые проекты, заранее подготовленные в TestRail. Мы реализовали это именно так, поскольку всё должно идти одновременно — и подготовка данных, и настройка TestRail. После успешного импорта мы начали подстраивать систему под существовавшие ранее тест-кейсы. В каких-то проектах этот процесс удалось автоматизировать, в каких-то из-за объёма пришлось переносить всё вручную.
Предфинальный этап внедрения TestRail в работу — это верификация. Мы проверили, что данные импортировались корректно и все кейсы перенеслись. Далее нам предстоял этап обучения команды, поскольку пользуются TestRail не только тестировщики, но и разработчики. Сейчас мы на завершающем этапе мониторинга и поддержки существующих кейсов, создания новых и сбора данных об использовании TestRail. В дальнейшем, возможно, мы будем расширять какие-либо функции или вносить изменения в процессы — к счастью, наша TMS позволяет это сделать.
Примеры использования
Структура тест-кейса в TestRail
Начнём с того, что структура полностью отвечает тем требованиям, которые мы предъявляем к тест-кейсам. У каждого тест-кейса есть своё название и ID. ID — это важный элемент любого тест-кейса, который позволяет использовать эти данные в автоматизированных прогонах и помогает осуществлять быстрый поиск. Все кейсы мы можем организовывать по определенным секциям и добавлять нужные подсекции. В дальнейшем это облегчает создание тест сьютов и организацию индивидуальных тестирований.
-
Первый блок внутри тест-кейса — тип теста. TestRail предлагает огромное количество вариантов: функциональный, интеграционный, перфоманс-тест, регрессионный и так далее. Тип указывается в зависимости от того, какой тест прогоняется или создаётся.
-
Приоритет — это то, насколько важно выполнение этого теста.
-
Тип автоматизации у нас может быть либо ручной, либо автотест.
-
В TestRail существувет несколько типов автотестов, поскольку всё организовано с точки зрения пирамиды тестирования. Если тест покрыт автотестом на уровне unit, то мы указываем тип unit. Если тест относится к интеграционному тесту, то это будет integration. Если это будет тест на уровне end-to-end, то здесь будет e2e-тест. Это очень удобно, поскольку позволяет оценивать покрытие функциональности с точки зрения пирамиды тестирования. Здесь есть дополнительный параметр — pyramid coverage, который указывает на то, какой тест создан для этого тест-кейса. В нашем примере это backend unit — он относится к unit-тестам, которые лежат в самой основе пирамиды.
Следующий блок структуры тест-кейса — это description. Описание — это опциональное поле, в котором любой тестировщик или разработчик может указать описание для конкретного теста или любую другую необходимую информацию. В хорошем тесте название должно говорить само за себя, однако дополнительные данные также всегда необходимы — вдруг тест нуждается в расшифровке.
Третий блок — поле preconditions. Оно обозначает предусловия — те шаги, которые тестировщик или любой человек, выполняющий тест, делает до выполнения основных шагов. Проще говоря, preconditions — это любые данные, которые необходимы для подготовки тестового окружения, поэтому здесь можно указать любую дополнительную информацию.
Четвёртый пункт — это шаги. Они создаются при помощи специальной кнопки, добавляющей любое количество шагов: ограничений в тест-кейсе по этому поводу не предусмотрено. Мы расписываем шаг и ожидаемый результат, а в качестве иллюстрации можем приложить скриншот или таблицу с данными. Таким образом мы делаем тест-кейс более информативным.
Что такое TestRun в TestRail?
После создания достаточного количества тест-кейсов пора переходить к TestRun. Он представляет собой конкретный набор тестов для выполнения в рамках определенного процесса тестирования. Под индивидуальные нужды могут создаваться различные наборы кейсов. Сделать это достаточно легко при помощи специальной вкладки в TestRail, где мы можем создать индивидуальный TestRun и выбрать то количество тест-кейсов, которые будут выполняться в его рамках.
Цели TestRun в TestRail
Цель TestRun заключается в подробном отслеживании прогресса выполнения тестов. На иллюстрации из нашего примера видно, что TestRun завершён на 63%. 10 кейсов прошли успешно, и ещё 6 остались на ретест. Таким образом, по завершении ретеста TestRun будет закрыт на 100%. Также TestRun позволяет фиксировать результаты тестирования: если мы остановимся на каком-либо этапе, это будет отражено в графике. Мы сможем в любой момент вернуться к этому отчёту и обратиться к его результатам.
TestRun можно переиспользовать любое количество раз. Это довольно гибкий инструмент, который благодаря своей иллюстративности позволяет тестировщику не только понимать выполняемый набор кейсов, но и фиксировать результаты для разработчиков. В любой момент можно обратиться и посмотреть, что делалось в рамках задачи и какие были результаты. Искать отчёты по комментариям зачастую неудобно, а TestRail хранит всё в одной вкладке.
Связи TestRun в TestRail
TestRun иллюстрирует некую связь с определенной версией продукта. В нашем примере приложено ТЗ, а также мы понимаем, что именно выполнялось в рамках этого TestRun. Если возникнут какие-либо вопросы или нужно будет повторить тестирование, этот TestRun можно переиспользовать в любой момент.
Также есть связь с индивидуальным тестированием. Например, если у нас есть определенная задача — здесь это задача доменной команды — то мы собираем нужные проверки и фиксируем их в TestRun. Таким образом мы сразу видим номер задачи, количество проверок и их результаты. Это очень удобно, поскольку довольно ярко иллюстрирует связь функционала с выполняемыми задачами и позволяет в дальнейшем делать процессы тестирования более гибкими.
Ещё один интересный инструмент в TestRail — это MileStone. Он объединяет большое количество TestRun в наборы и выполняет в рамках одного тест-плана. Это хороший инструмент для проведения масштабных регрессионных тестирований, если они актуальны для проекта. Создаётся MileStone по тем же принципам, что и TestRun: вписывается название релиза или задачи, с которой он связан, добавляются нужные тесты в том количестве, в котором они необходимы.
Метрики и TestRail
На наших проектах активно снимаются метрики с тест-кейсов, которые мы заводим в TestRail. Эти результаты выгружаются в Grafana, где на красивых графиках отображается процент покрытия автотестами. Например, в одной из команд он составляет 100%. Также мы смотрим на процент покрытия автотестами по всем командам. Таким образом мы представляем процесс покрытия существующих кейсов автотестами в виде ярких и красивых графиков. Это позволяет нам планировать дальнейшую работу с тест-кейсами. Так, в некоторых проектах до сих пор преобладает ручное тестирование: сверяясь с метриками, мы планируем, нужно ли повышать процент автоматизации или нет. Тестировщикам же это помогает понять, какие важные кейсы у нас находятся на уровне ручных проверок, нужно ли там создание e2e тестов или достаточно будет покрыть эти кейсы unit-проверками.
Ещё одна наша метрика — это актуальное покрытие требований автотестами. Так же, как и предыдущая, она выгружается в виде графика. Здесь довольно иллюстративно показано, как обстоит дело: где-то высокий процент покрытия и зелёный столбик, а где-то всего 5%. Это помогает нам отслеживать процессы и понимать, где процесс идёт не так, как нужно. Настройки интеграции TestRail и Grafana довольно гибкие, что позволяет создавать любые отчёты и графики.
О наших QA-метриках, их внедрении, использовании и анализе ранее подробно рассказывала Ольга Султанова, руководитель тестирования в Рунити.
Результаты внедрения TMS
В статье я подробно рассказала о том, что такое Test Management System и как внедрение TestRail может оптимизировать процессы тестирования в команде. Мы обсудили ключевые преимущества и недостатки TMS, а также выделили основные характеристики, которые должны отличать качественный инструмент для управления тестированием.
Переход на TestRail стал важным шагом для нашей команды, поскольку это решение не только соответствует всем современным требованиям, но и позволяет эффективно интегрироваться с уже существующими процессами. Мы смогли перенести существующие тест-кейсы, настроить метрики и обеспечить непрерывный мониторинг, что сделало процесс тестирования более прозрачным и управляемым.
Благодаря TestRail мы улучшили организацию хранения тестовой документации, что значительно упростило доступ к информации как для тестировщиков, так и для разработчиков. Кроме того, визуализация данных через метрики и интеграция с Grafana позволяют нам отслеживать эффективность автоматизации и улучшать качество продукта.
В завершение, внедрение TMS — это не просто техническая задача, но и стратегическое решение, которое требует внимательного подхода и достаточной экспертизы. Наш опыт с TestRail подтвердил, что управление тестированием может значительно повысить эффективность разработки и обеспечить высокий уровень качества программного обеспечения. Как показала практика, работа с TMS позволяет не только оптимизировать процессы, но и создать более комфортные условия для взаимодействия в команде.
ссылка на оригинал статьи https://habr.com/ru/articles/858504/
Добавить комментарий