Руководитель QA-подразделения Redmadrobot Илья Горшков рассказывает, как выбирал инструментарий для работы с тест-кейсами.
В процессе работы над любой сложной программной системой создается большое количество проектной документации. Её структурный состав в большинстве случаев практически одинаков – это требования к системе различного уровня, описание ее архитектуры, программный код, документация QA-команды, проектные планы, отчеты и т.д.
Сегодня я расскажу об артефактах QA-команды Redmadrobot, с которыми мы работаем в ходе проектов. Это тест-стратегии, тест-планы, test runs и тест-кейсы, traceability matrix, bug reports, метрики продуктивности и качества, различные отчеты по результатам тестирования и т.д. Все они имеют определенную иерархию, создаются в определенной последовательности и требуют периодической актуализации.
Решить задачу создания единой системы для работы со всеми QA-артефактами можно несколькими способами. К примеру, выбрать Excel и Google Docs, вести все в баг-трекере (используя Test Case как Issue Type) или использовать один из test case management tools, интегрированный с баг-трекером компании. Мы в Redmadrobot выбрали третий вариант, исходя из специфики проектов, объемов задач, типов QA-документации и используемых нами видов тестирования, количества разрабатываемых и выполняемых manual тест-кейсов и различных проектов в работе одновременно.
Следующим этапом для нас стал выбор подходящего test case management tool. Очень важно подойти к этому выбору максимально ответственно, так как цена ошибки при выборе подобного инструмента для компании достаточно высока. QA-команда в Redmadrobot шла к финальному решению в несколько этапов и начинала с разработки критериев, которым необходимый нам инструмент должен соответствовать.
Критерии мы ввели следующие:
- интеграция с баг-трекером компании (JIRA)
- хранение и возможность редактирования тест-кейсов, в том числе импорт тест-кейсов, созданных нами ранее
- простота отслеживания покрытия требований тест-кейсами
- удобное формирование Test Runs/Test Suites и удобный пользовательский интерфейс
- хранение всей информации по Test Development и Test Execution в одном месте и создание единого пространства для работы QA-команды
- возможность создания Traceability Matrix
- возможность распределения задач и назначения их на конкретных инженеров
- простота получения отчетов, метрик, статистики
- удобство установки, внедрения, поддержки
Из чего выбирать:
После выработки критериев мы рассмотрели несколько наиболее популярных на рынке тулов, которые соответствовали нашим ожиданием. Часть тулов была отброшена при более детальном рассмотрении, для оставшихся мы оформили evaluation-лицензии и продолжили исследование. В результате список сократился до трех тулов, на которых были проведены пилотные проекты:
1. Zephyr
2. TestRail
3. Meliora
По завершении пилотов сложилось четкое понимание возможностей и удобства работы в каждом из них, стали понятны фичи каждого тула, их применимость и удобство использования для нас. Вот высокоуровневые характеристики каждого тула:
Zephyr (1 user — $30) — отличительная черта этого тула в том, что это продукт Atlassian, а значит, он должен быть отлично совместим c JIRA, но проблема в том, что это валидно для JIRA Server, а мы пока используем OnDemand, с которым на этапе пилота было много проблем. Помимо этого недостатка Zephyr неудобен в использовании: добавлять тест-кейсы долго и не настолько просто, много лишних действий при создании планов и runs.
Meliora (1 user — $25) — также необходим переход на JIRA Server + сам по себе Meliora довольно громоздкий инструмент, искусственно усложняющий большую часть простых задач, включающий в себя еще и собственный bug-трекер.
TestRail (1 user — $20) — простой и удобный тул. Основной плюс — кастомизация возможна практически во всем, и любые действия интуитивно понятны. Есть возможность импорта/экспорта тест-кейсов.
Проанализировав результаты пилотов и фидбек по каждому тулу, решили сконцентрироваться на TestRail, который включает в себя и позволяет:
- Создание/хранение/редактирование тестовых сценариев, управление тестовыми планами, запуск тестовых циклов, занесение результатов тестирования.
- Четкое описание тестовых сценариев, их ревью, соотношение с требованиями, разделение на области — всё это позволяет оценить как полноту покрытия тестами функционала, так и является необходимым материалом для всей проектной команды.
- Создание отчетов по совершенно разным критериям: Defect Summary, Comparison for Cases, тестовые результаты по проектам/компонентам/майлстоунам и т.д.
- Возможности для полной кастомизации «рабочего dashboard», а также удобное получение статуса работы QA-команды за разные периоды времени (помогает при создании weekly/monthly QA report).
- Легкая интеграция с JIRA.
- Разумная цена.
- Отличный support.
- Легкий и удобный способ импорта тестов из Excel.
Возможность легко импортировать уже созданные ранее тест кейсы для нас была очень важным критерием. Когда мы только начинали развивать QA-практику в Redmadrobot, речи о Test Case Management Tool еще не шло, а для работы с тестами использовали Excel. Но мы сразу подошли к вопросу использования Excel с заделом на будущее и выработали четкий формат тестов, понимая, что через некоторое время будем «скармливать» их в какой-либо тул. Когда мы запустили TestRail в промышленную эксплуатацию, смогли экспортировать «as is» несколько тысяч тест-кейсов, что сильно сократило усилия на внедрение тула.
Ниже я подробно рассмотрю возможности TestRail для различных QA-активностей:
Test Development:
- создание test plans/suits/test cases;
- удобное хранение, обновление и организация;
- импорт/экспорт возможность редактирования;
- легко настраиваемый набор любых атрибутов теста;
- Requirements Traceability.
Test Execution:
- milestones (согласно критерию качества в компании);
- составление test runs;
- заведение дефектов из test runs;
- распределение задач;
- удобная интеграция с JIRA.
Test Management:
- управление активностями;
- распределение ролей;
- назначение задач и контроль выполнения.
Reporting:
- прогресс тестирования;
- результаты тестирования в виде готовых отчетов;
- статистика по проектам;
- многообразие вариантов отчетов;
- метрики продуктивности команды.
Что же в итоге:
Окончательный выбор мы сделали еще в августе. В сентябре перевели в TestRail большую часть QA-активностей по проектам. Продолжаем переводить туда все новые проекты. За все время еще ни разу не пожалели о выборе. Собрали несколько метрик, которые подтвердили наши предположения насчет верности выбора и положительном эффекте от внедрения. Смогли быстро научить инженеров эффективно использовать тул. В ближайшее время закончим работы над внедрением Requirements Traceability для всех проектов и будем развивать использование TestRail дальше.
Автор: redmadrobot
