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

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
30-Сен-2020 17:33

Цитировать

Ведение документации для тестирования в 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 [/url][url=https://hiptest.net/]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
Итак, поиски инструмента продолжились. Следующим был вариант — [/url][url=https://leantesting.com/]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 ([/url][url=https://www.adaptavist.com/doco/display/KT/Test+Management+for+Jira+Server]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%.

Поэтому могу точно сказать, что переход на тест-кейсы с чек-листов оказался для нас эффективным.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_testirovanie_vebservisov (Тестирование веб-сервисов), #_testirovanie (тестирование), #_qa, #_testing, #_testirovanie_vebprilozhenij (тестирование веб-приложений), #_documentation, #_testing_tools, #_checklist, #_cases, #_blog_kompanii_onlajn_shkola_englishdom (
Блог компании Онлайн школа EnglishDom
), #_testirovanie_vebservisov (
Тестирование веб-сервисов
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 19:54
Часовой пояс: UTC + 5