Что такое TestRail и почему он лучше, чем Google Sheets

Процентов на 70 тестирование состоит из информации об этом самом тестировании. Да, команда тестировщиков должна прогнать тесты руками или средствами автоматизации, но: 1) тест-кейсы нужно где-то хранить; 2) результаты проведения тестирования тоже нужно где-то хранить; 3) баг-репорты нужно где-то создавать; 4) план тестирования новой фичи нужно где-то записать; 5) статистику тестирования нужно где-то подбивать. «По старинке» это все делается в Google Docs и Google Sheets, но спросите любого тестировщика на более-менее крупном проекте – и он расскажет вам, как быстро такая практика превращается в мешанину из файлов в папке общего доступа. Чтобы работать было приятнее, можно воспользоваться функционалом TestRail – утилиты для ведения тестовой документации. Мы не знаем, кто вы – матерый тестировщик или новичок – поэтому материал разбит на 2 раздела: 1) теория тестовой документации; 2) фичи, которые TestRail предоставляет. Если вы только учитесь – читайте оба раздела, если вы ищете конкретно информацию о том, что TestRail позволяет делать – смотрите второй раздел.

Тестовая документация

Что это?

Тестовая документация представляет собой базу данных о тестировании на проекте. Обычно отвечает за тестовую документацию лид отдела, хотя отдельные полномочия могут передаваться сотрудникам ранга пониже – например, лид может отдать задачу по составлению плана тестирования нового релиза senior QA. Тестовая документация состоит из артефактов (объектов): тест-кейс, тест-сьют (их еще называют портфелями), плана тестирования, баг-репортов и так далее. Все эти артефакты и составляют базу данных о тестировании.

Артефакты тестовой документации

Чем тестировщики оперируют при создании тестовой документации:

• План тестирования. Документ, который расписывает критерии начала и окончания тестирования, объекты тестирования техники, платформы и так далее. План тестирования может затрагивать разные модули (микросервисы, клиентские приложение), иметь разные масштабы (тестирование новой фичи или тестирование всего проекта) и располагаться на любом участке срока жизни проекта (регрессионное тестирование, тестирование только что вышедшей фичи, предварительный план тестирования фичи, находящейся в разработке). В общем, план тестирования – это тот документ, который позволяет команде тестировщиков знать, что им нужно делать. Нередко план тестирования разрабатывается в согласовании с другими отделами – с командой разработки, например.
• Тест-кейс. Последовательность действий, приводящая к определенному результату. Основная «единица» тестирования. Чем плотнее функционал покрыт тестовыми кейсами, тем меньше шансов, что баг просочится на продакшн.
• Тест-сьют (портфель). Логически связанный набор тестов – по объекту тестирования, по функциональности и так далее.
• Тест-ран (прогон). Исполнение одного или нескольких тест-сьютов в рамках плана тестирования.
• Юзкейс. Пользовательский сценарий действий, например – «Пользователь зашел на сайт и нажал кнопку логина, после чего его перенаправило на страницу ввода логина и пароля». Юзкейс – частый источник тест-кейсов.
• Чек-лист. Список дел по тестированию. Носит намного менее строгий характер, чем тест-кейсы или тест-сьют, но все же полезен, поскольку позволяет быстро оценить объем работ или не забыть что-нибудь важное.
• Баг-репорт. Отчет о найденной ошибке. Обычно баг-репорту присваивают приоритет (от самого низкого до «бросайте все и бегите фиксить»). В баг-репорте крайне желательно указать последовательность шагов для воспроизведения бага, чтобы разработчику было проще его локализовать.
• Отчет о тестировании. Отчет, содержащий в себе данные о проделанной работе. Может быть промежуточным, может быть итоговым. Какого-то четкого общепринятого формата нет (у каждой команды – свой формат, прописанный во внутренних документах), главное – чтобы отчет давал ту информацию, которая от него требуется.

Зачем это все нужно

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

Именно поэтому придумали все вышеперечисленные артефакты: они позволяют держать весь этот огромный поток информации под контролем. Когда разработчики создали новую фичу – ответственный в отделе QA составляет план тестирования, в котором указано, что именно нужно сделать для того, чтобы считать эту фичу протестированной. Затем план тестирования отправляется тому, кто будет непосредственно этим заниматься. Тестировщик изучает документацию, ищет юзкейсы и составляет чек-листы, на их основе покрывает тест-кейсами фичу и объединяет тест-кейсы в сьюты, чтобы исполнить тест-раны. Если нашлись баги – создаются баг репорты. Когда тестирование закончено – некоторый набор тестов выделяется в отдельный сьют для регрессивного тестирования. Когда все это закончено – создается отчет, в котором указано, насколько хорошо прошло тестирование. Все это получает уникальные ID-шники и ключи в базе, с помощью которых можно быстро вернуться к конкретному артефакту и все перепроверить (очень удобно, когда нужно найти виноватого).

TestRail

Итак, использование TestRail оправдано тогда, когда нужно упростить процесс ведения документации – то есть всегда. Как только вы откроете TestRail, вы увидите дашборд:

Это – место, где вы можете получить данные по всем проектам и перейти в детальную информацию по любому из них. Организация документации в TestRail построена на проектах – репозиториях, в которых хранится информация. Когда вы нажмете на «Add Project», вам на выбор предложат 3 вида проектов:

• Один репозиторий на все кейсы. Самый простой вариант – все тестовые данные хранятся в одном месте. Такая простота помогает командам быстро покрывать тестами существенную часть функционала. Некоторая гибкость в таком проекте все еще сохраняется – за счет тестовых наборов, тест-планов и milestones.
• Единый репозиторий с базовыми линиями. То же, что и предыдущий вариант, но дополнительно можно создавать baselines. Подходит в тех случаях, когда нужно одновременно тестировать несколько версий приложения. Вы создаете мастер-кейсы, которые будут применяться ко всем «веткам», а затем дополнительно добавляете/модифицируете тест-кейсы для каждой отдельной версии приложения. Естественно, этот инструмент управления тестовыми кейсами существенно усложняет ведение документации, потому что по факту вам нужно вести отдельную документацию для каждой версии проекта.
• Множественные test-suites. Еще более усложненная версия репозитория – вы добавляете различные окружения, версии и команды, для каждой из них нужно вести свою документацию. Подходит для очень крупных проектов, в которых к тестированию программного обеспечения привлекаются сразу несколько отделов.

Что касается менеджмента тест-кейсов, TestRail позволяет:

• Создавать тест-кейсы по всем правилам – с уникальным ID, описанием сценария, пред-условиями, ожидаемым результатом, мета-данными, типом, приоритетом, эстимейтом, референсами и типом автоматизации (если есть).
• Группировать кейсы в сьюты, добавлять под-сьюты (подгруппы) в сьюты.
• Быстро перемещать и копировать тест-кейсы (в том числе поддерживается групповое копирование/перемещение).
• Проверять результаты исполнения тест-кейса, логгировать дефекты и смотреть историю кейса.
• Прикреплять любые файлы к конкретному кейсу.

На вкладке «Test runs and results» любого проекта вы можете:

• Создать новый тест-ран, используя все кейсы проекта или определенные, и назначить этот тест-ран конкретному тестировщику.
• Смотреть статус как всего тест-рана, так и отдельных задач, в специальном дэшборде тест-рана.
• Добавлять результаты для каждой задачи: удалось ли пройти тест, сколько времени затратила проверка, был ли найден баг и где он будет зарепорчен (обычно – ID в Jira).

TestRail позволяет интегрироваться с Jira – репортить баги станет намного более удобно:

В том, что касается работы на более высоком уровне, сервис предоставляет 5 инструментов:

• Milestones. Какие-либо важные события в жизни проекта с привязкой ко времени. К каждому milestone можно указать тест-раны, которые к этому времени нужно провести.
• To Dos. Дэшборд сотрудника, в котором последний может отслеживать задачи, которые ему назначили.
• Нотификации. Кто угодно может подписаться на тест-ран, milestone или другое событие, чтобы отслеживать его прогресс.
• Тест-план. Полноценный план на тестирование чего-нибудь крупного, например – нового релиза: можно добавлять milestones, различные тест-раны, сотрудников, окружения и так далее.
• Репорты, статистики, метрики. Формируются автоматически в личном кабинете на раны, проекты, планы, milestones и другие события. Можно различными образами группировать, можно добавлять фильтры – возможностей для кастомизации много.

Кратко о главном

• Тестирование любого более-менее крупного проекта подразумевает наличие тестовой документации.
• Документация состоит из артефактов – тест-кейсов, сьютов, тест-ранов, тест-планов, отчетов и других единиц информации.
• Основная задача тестовой документации – хранить всю информацию обо всем тестировании за всю историю проекта (и это – очень много информации).
• TestRail дает все необходимые инструменты для ведения тестовой документации: можно создавать кейсы, можно объединять их в сьюты, можно запускать тест-раны, можно отслеживать загруженность работников и так далее.