Как стать автором
Обновить
422.35
Рейтинг
EnglishDom
Лидер в онлайн образовании

Выбор хорошего инструмента для хранения тест документации и сравнительный анализ 3 выбранных инструментов

Блог компании EnglishDom Тестирование веб-сервисов *

Ведение документации для тестирования в Google-доках и Google-таблицах — не лучший способ работы с тестовой документацией. Такой подход имеет свои недостатки.


В этой статье я расскажу, как мы перешли от хранения тестовой документации с Google docs к специализированным SaaS-решениям, сделаю сравнение трех разных инструментов (HipTest, Leantesting, Test Management for Jira) и поделюсь результатами такого перехода.




Меня зовут Татьяна и уже 2,5 года я работаю в компании Englishdom на позиции qa engineer. Мы — онлайн-школа английского языка, и наш IT-отдел разрабатывает уникальную цифровую платформу — учебник для изучения английского, а также несколько приложений для тренировок и домашних заданий. QA-команда тестирует эти продукты и для этого мы ведем документацию.


Использование Google-доков и Google-таблиц имеет свои преимущества: 


  • бесплатные ресурсы без ограничений; 
  • легкая адаптация — так как таблицы — простой и понятный инструмент. 

Но у такого подхода есть и свои недостатки: 


  • увеличение количества тестов когда проект растет, а значит масштабируемость тест-кейсов или чек-листов для проверки функционала и как следствие — сложность в их управлении; 
  • управление тестовыми проверками — например, такие как отметка фактического результата теста при запуске тестов, запуск test cycle и построение отчета о пройденном тестировании; 
  • менеджмент тестовой документации. 

Когда я пришла на работу в проект Englishdom, в качестве тестовой документации мы как раз использовали чек-листы в Google-таблицах и в Confluence. Из-за недостатков, описанных выше, одной из главных задач для улучшения процессов был переход с чек-листов на тест-кейсы. А для этого требовался хороший инструмент для их хранения и управления.
 
Итак, я получила задачу от QA-лида заняться ресерчем этой проблемы. Для поиска хорошего инструмента я просмотрела множество статей, презентаций и информации в различных интернет источниках и провела сравнительный анализ существующих предложений. Также я опросила многих QA-коллег, проанализировала их мнение и  увидела закономерность, что QA действительно не спешат внедрять такие вещи в продукт прежде всего из-за того что: 


  • избегание переезда или нежелание переноса множества тестов на другой инструмент; 
  • дискомфорт при выходе из зоны комфорта и получении непривычного нового опыта; 
  • отсутствие необходимого бюджета, т.к. почти все Test Case Management Tools — платные; 
  • выбор self-hosted, а не saas-cloud решений для Test Case Management System, что также является платным, и может быть проблемой ввиду отсутствия или ограниченности бюджета; 
  • имеются сложности договориться с менеджментом о необходимости или стоимости для такого инструмента.

В нашем случае первоначально стояла задача: найти бесплатный Test Case Management Tool на минимальное количество пользователей, так как на проекте было всего несколько тестировщиков и большое количество юзеров для нас не имело значения, также количество тестовых проверок на тот момент было не слишком большое. Ввиду этого не было необходимости в платном и супер-крутом инструменте. 


HipTest


Дальше настало время экспериментов. Первый инструмент, который мы решили попробовать — это HipTest . Представлю краткий его обзор.

 
Преимущества:


  • наличие централизованного хранилища результатов тестов от запуска к запуску в наглядном представлении;
  • возможность просмотра шагов теста, при этом если изначально выбрать хороший стиль написания сценариев, то каждый участник проекта/команды без проблем разберется в сути теста.

Недостатки:


  • создание и редактирование сценариев и action words (при создании новых  шагов-действий можно квалифицировать их как шаг, ожидаемый результат или многоразовое действие, это называется action words в HipTest) возможно только в HipTest, а редактор там специфичный. Чтобы понять, нужно попробовать и сравнить с блокнотом или, скажем, с google docs/sheets;
  • массовый быстрый рефакторинг сценариев не получится так же, как это легко можно делать в текстовых редакторах;
  • необходимо быть аккуратным с переименованием (случайным или нет) action words, т.к. в случае, если сценарий уже автоматизирован, то переименование только в HipTest приводит к упавшему тесту, потому что в части реализации наш action word остался с прежним именем;
  • нет возможности прикреплять скриншот к step, а только ко всему тест-кейсу.


Пример тестового сценария в hiptest



Изначально интерфейс этого инструмента мне показался очень простым и удобным, я вдохновилась преимуществами и мы начали переезд на этот инструмент. Возникли некоторые проблемы с экспортом чек-листов с google таблиц и confluence и пришлось вручную переписывать их в HipTest. Дальше при презентации команде было принято общее решение все-таки отказаться от этого тула в виду одной и самой большой причины — все-таки сильно неудобно, что в скриншот можно крепить только один ко всему тесту, а не к каждому шагу. В итоге HipTest в работе мы так и не использовали.
 
P.S. В моем рассказе HipTest представлен в том виде, который был на момент нашего использования. На данный момент HipTest объединен с Cucumber под одним брендом, запустив CucumberStudio и новый улучшенный веб-сайт Cucumber.io. Однако теперь инструмент платный. 


LEANTESTING


Итак, поиски инструмента продолжились. Следующим был вариант — https://leantesting.com/ (по сути это бесплатный аналог Test Rail, однако есть возможность приобрести расширенные возможности за дополнительную плату. Сейчас мы рассмотрим особенности бесплатной версии.
 




Пример тестового сценария в LeanTesting
 
Преимущества:


  • неограниченное количество пользователей;
  • неограниченное количество проектов;
  • неограниченное количество тестов и тест сайклов;
  • удобные отчеты;
  • в новом обновлении Lean Testing может запускать автоматизированные тесты с Selenium.

Недостатки:


  • интеграция с другими вебхуками (например, Slack, GitGub, BitBucket ) платная;
  • настройка пользовательских статусов и типов ошибок также платная;
  • нет интеграции с какими-либо системами баг-трекеров (в нашем случае Jira);
  • скриншот можно прикрепить только к тест-кейсу в целом, но не к шагам;
  • нет возможности импортировать тест-кейсы из других Test Case Management Tools или Excel.

Изначально приняв решение о переходе на этот инструмент, мы видели одно большое преимущество — более удобный пользовательский интерфейс, чем в HipTest, но спустя год активного использования все-таки решили уйти от Lean Testing. Главной причиной для нас на тот момент стало отсутствие интеграции с Jira (на проекте мы активно ее используем для ведения всех задач и, конечно же, было бы удобно хранить все в одном месте) и возможность прикреплять скриншот только ко всему тест-кейсу, а не к каждому шагу. Также на тот момент в бесплатной версии было ограничено количество создаваемых кейсов. 

То есть изначально при выборе инструмента, мы не задумывались о таких вещах как интеграция с Jira, но впоследствии пришли к выводу, что это было бы очень удобно и полезно для тестирования и разработки. Мы не думали про то, что проект будет так стремительно расти, а с ним и количество наших тестов. Изначально мы просто хотели перенести документацию только для части функционала, а остальную оставить в Confluence. Но со временем, пощупав удобство пользования тест-кейсами в специальной системе их хранения, мы решили переносить туда и другие тесты. 


Test Management for Jira (TM4J)


Спустя какое-то время поиска выбор пал на Test Management (https://www.adaptavist.com/doco/display/KT/Test+Management+for+Jira+Server) — встраиваемый в Jira инструмент, простыми словами — плагин. 

Преимущества:


  • красивые и понятные отчеты в виде диаграмм (но довольно простенькие);
  • добавление и удаление статусов к тест-кейсам, тест прогонам и результатам;
  • возможность проставлять лейблы, компоненты, приоритеты в каждом кейсе;
  • возможность добавлять скрины в каждый шаг тест-кейса (!);
  • связь с Jira.

Недостатки:


  • плагин платный, оплачивается дополнительно и не входит в лицензию Jira;
  • нет возможности настроить сортировку тестов по порядку в тест-сайкле -  при просмотре сьюта у вас будут тесты по порядку, а при добавлении этого сьюта в тест-сайкл внутри папки такого удобного порядка уже не будет.

Для нас главным и приоритетным преимуществом выбора инструмента стала все-таки связь с Jira. Это значит, что во время прохождения тест-сайкла на регрессии перед релизом вы заводите баг и прикрепляете прямо к тест-кейсу, указываете на каком шаге фейлится тест, разработчик заходит сразу в тест-кейс и видит нужную информацию — это же круто, экономия времени). Еще вариант использования: продакт-менеджер создает задачу, qa прикрепляет тест-кейсы к задаче, разработчик сразу видит тест кейс и шаги к нему, которые ему необходимо пройти перед передачей функционала на тестирование. И несмотря на то, что плагин платный, мы поняли, что эти преимущества очень важны для нас и помогут улучшить процессы в тестировании.



Визуализация тест сайклов



Визуализация создания тест-кейса (скрин1)



Визуализация создания тест-кейса (скрин2)


Сравнительный анализ трех инструментов приведен в таблице





Итоги


Методом проб и ошибок мы сменили инструмент, выбрав тот, который оказался самым удобным для нашего проекта, изменили подход к ведению тестовой документации, ее хранению и управлению, забыв про чек-листы в Google-таблицах и полностью перейдя на тест-кейсы в специальной системе Test Management. За все время использования еще ни разу не пожалели о выборе. Ведение тестовой документации прямо в Jira оказалось неимоверно удобным. Такой подход планируем использовать и в будущем.


Совет для тех, кто еще не решился — уходите из Google-доков и переходите на специальные инструменты для тестовой документации. Какой — решать вам, предложений по инструментам действительно много, но точно найдется вариант под ваш проект и ваши цели. Я лишь поделилась историей опыта нашего qa-отдела. Могу сказать, что это сэкономило нам немало времени. Пара примеров: актуализация, формирование тест-сайкла и распределение ответственных qa раньше занимало приблизительно час, сейчас 40 мин. Также создание бага — раньше занимало до 15 мин, сейчас около 5 мин времени. Итого, экономия времени составила до 30%. 
 
Поэтому могу точно сказать, что переход на тест-кейсы с чек-листов оказался для нас эффективным.

Теги:
Хабы:
Всего голосов 7: ↑7 и ↓0 +7
Просмотры 5.1K
Комментарии Комментарии 5

Информация

Дата основания
2010
Сайт
www.englishdom.com
Численность
1 001–5 000 человек
Дата регистрации