№1 в разработке мобильных решений для бизнеса
123,44
рейтинг
27 января 2015 в 15:17

Разработка → Test Case Management Tool: как правильно сделать выбор и не пожалеть об этом



Руководитель 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
REDMADROBOT
рейтинг 123,44
№1 в разработке мобильных решений для бизнеса

Комментарии (7)

  • 0
    Спасибо за обзор!
    В своем проекте остановились на www.testlodge.com/, очень простой инструмент, хорошо подходит для маленькой команды и пока не очень крупного проекта как у нас. Правда, интеграция очень примитивная. Мы используем трелло для всех тикетов, и TestLodge может создавать тикеты при зафейленных тест-ранах, но нельзя даже выставить label для тикета.
  • 0
    TestRail и правда оказался замечательным. Мне также порекомендовали TestLodge — я сравнил их — TestRail почти по всем показателям выигрывает — а главное — по удобству работы с большим количеством тест кейсов.
  • 0
    Ребят, а как вы добились такого вида отчётов как на последней картинке?
    Из коробки TestRail даёт возможность собирать отчёты только в zip и с помощью ссылок при пересылке на email.
  • 0
    Сами отчеты легко сгенерировать через вкладку Reports в Test Rail, выбор типа отчета в данном случае Runs(Summary). Далее готовый отчет просто копируется в clipboard (выделяем нужную часть отчета) и вставляется в новое письмо.

    Кроме того при создании отчета мы заполняем поле Description, добавляя туда наш вердикт по смоку и другие реккомендации от команды (next steps, critical issues found).
  • 0
    Вопрос к автору, а среди изначальных вариантов рассматривали ли вы qTest?
    • 0
      Добрый день!

      qTest рассматривали не так давно. Интересный тул, но по многим параметрам для нас TestRail выходит интереснее. Заметили, что qTest достаточно медленно работает сам по себе, схема работы с большими сьютами и ранами не очень удобна и привычна нам, как бывшим почитателям связки Bugzilla и Testopia. У TestRail больше нравится работа с дефектами из JIRA (недавно был большой апдейт на эту тему). Пока остаемся на рейле, но ждем когда выйдет что-то крутое и милое нашему сердцу))) В остальном набор базового функционала у qTest и TestRail очень похож.

      Кстати, Рейл радует частыми полезными апдейтами и отличной командой поддержки по любым вопросам. С момента публикации данного топика еще с парой киллер-фич Рейла успели познакомиться, но об этом скорее всего расскажем отдельно.
      • 0
        Спасибо! Будем пробовать =) По крайней мере на первый взгляд TestRail кажется значительно более удобным, чем Zephyr.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка