Используете ли вы Test IT для ведения документации

Что проверяют

Работали ли вы с системой управления тестированием на практике и понимаете ли, как в ней устроена документация. Test IT популярен в российских компаниях как отечественная замена TestRail, поэтому вопрос частый. Следом спрашивают, как вы структурировали проект и связывали кейсы с требованиями и автотестами.

Как отвечать

Если работали, опишите устройство, а не преимущества:

• структура: секции по модулям продукта, внутри тест-кейсы и чек-листы. Кейсы для важных сценариев, чек-листы для быстрых проверок и смоука;
• переиспользование: общие шаги для повторяющихся действий вроде авторизации и параметры для одной проверки на разных данных;
• планы и прогоны: тест-план на регресс или релиз, распределение по исполнителям, результаты со скриншотами и ссылкой на баг;
• интеграции: связь кейсов с задачами в Jira, выгрузка результатов автотестов через адаптеры для pytest, JUnit и других фреймворков, запуск из CI;
• отчёты: прогресс прогона и доля упавших проверок для релизной встречи.

Добавьте, как держали документацию актуальной: кто обновляет кейс при изменении требования, как чистили устаревшее. Это отличает реальную работу от знакомства по демо. Объёмы называйте свои: сколько кейсов, как часто регресс.

Если Test IT вы не видели, так и скажите и назовите, в чём работали: TestRail, Qase, Allure TestOps, Zephyr или Xray в Jira. Понятия там общие, освоиться можно за несколько дней. Если TMS не было вовсе, расскажите, где жили кейсы (Confluence, таблицы) и чего в этом не хватало.

Где спотыкаются

Отвечают рекламным списком: «удобно, отчёты, совместная работа». Такой ответ подходит к любому инструменту и ничего не говорит о вашем опыте.

Говорят «использую», но не могут описать структуру своего проекта или объяснить разницу между тест-планом и прогоном.

Считают, что TMS это вся документация. Тест-стратегия, требования и описание стендов обычно живут отдельно, и об этом стоит сказать.