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 дальше.
    • +11
    • 35,6k
    • 7
    Redmadrobot 78,33
    №1 в разработке мобильных решений для бизнеса
    Поделиться публикацией
    Похожие публикации

    Вакансии компании Redmadrobot

    Комментарии 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.

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

              Самое читаемое