Ведение документации для тестирования в 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 https://hiptest.net/
Представлю краткий его обзор:
Преимущества:
- наличие централизованного хранилища результатов тестов от
запуска к запуску в наглядном представлении;
- возможность просмотра шагов теста, при этом если изначально
выбрать хороший стиль написания сценариев, то каждый участник
проекта/команды без проблем разберется в сути теста.
Недостатки:
- создание и редактирование сценариев и 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%.
Поэтому могу точно сказать, что переход на тест-кейсы с чек-листов
оказался для нас эффективным.
