3 проблемы, которые решает TMS

Стандартная боль тестировщиков: где располагать тестовые кейсы? Часто для этого используют Excel, Word или более продвинутый вариант — Jira. Все эти инструменты уступают специализированным системам управления тестированием по нескольким причинам. Наш QA Lead Карим Аминов на примере Test IT рассказал о трех проблемах, которые способна решить TMS. 

Проблема №1. Нет гарантий сохранности тест-кейсов 

Если проекты ведутся в Jira, все равно приходится покупать дополнительный компонент для хранения тестовой библиотеки. С одной стороны, удобно: ошибки и исправления можно отследить в одной системе. С другой стороны, — способ рискованный. Вот почему: 

• Если Jira упала, то вместе с ней упали и все тестовые кейсы проекта. 
• В рамках компонента нет распределенных доступов, поэтому любой человек с правами доступа может зайти в систему и удалить данные —неважно, случайно, или чтобы устроить диверсию. 
• Если админы что-то начудили и упала не только Jira, а весь сервер, на котором она стоит, — тестировщики остались без тестов. 

Решение — коробочная версия TMS. Поставил Test IT Enterprise на отдельный сервер, и это гарантирует сохранность тест-кейсов проекта в целом. 

Проблема №2. Необходимость нескольких инструментов для прогонов

На всех проектах существуют различные наборы автотестов, которые пишут автотестировщики. Они же чаще всего занимаются запуском этих тестов. Как это происходит? Есть некий написанный или заимствованный фреймворк, например, Pytest. В нем делаешь сборку вручную, либо автоматически запускается инструмент CI/СD, например, Jenkins. Полученные ответы выкладываются в следующую систему, это может быть Allure Report. Чтобы пройти этот путь, необходим доступ к трем системам. 

Test IT поддерживает интеграцию с десятками фреймворков автоматизированного тестирования с помощью собственных адаптеров или CLI. Система позволяет собирать ручные и автотесты в одном месте: делаешь тест-план и видишь, что покрыто автотестами, а что нет. 

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

Проблема №3. Непонимание процессов тестирования со стороны руководства 

Руководители могут не понимать нюансов работы команды QA. Порой сложно объяснить менеджеру, почему на регресс понадобится еще пять дней, хотя формально работа уже закончена. И начинается: «Как пять дней? Откуда? Нужно завтра!»

Решить проблему помогает отчетность в системе управления тестированием — эта функция есть во многих TMS, в том числе и в Test IT. Руководитель может сам проверить отчет, увидеть конкретные цифры и убедиться, что вы не с потолка взяли эти 180 часов на регрессионное или другое тестирование.

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