Testing tools

Для будущих студентов курса Infrastructure as a code in Ansible и всех интересующихся подготовили перевод полезного материала.

Также приглашаем записаться на открытый урок по теме Управление Kubernetes при помощи Kubespray.

• Контроль качества кода terraform fmt -check и terraform validate.
• Предварительный просмотр terraform plan.
• Построение TFLOG=debug terraform apply для дотошной проверки.

Средства статического анализа кода Terraform

• Наличие модульных тестов в конфигурации ресурсов terraform и возможность расширять любой подобный общий список проверок соответствия передовым методам* для определенного поставщика облачных услуг. Кроме того, нас интересуют простые в использовании инструменты, с которыми можно начать работать без промедления.

• Возможность выполнять более нестандартные тесты своего рода отбойник нормативного соответствия, позволяющий ограничивать конфигурацию ресурсов. Эта возможность должна быть разумно расширяемой, чтобы защитить подсети, роли безопасности, нестандартные теги и даже обеспечить включение или выключение флагов определенных функций кластера EKS.

• Требование, определенное в большей степени личным опытом, платформа тестирования по возможности должна сокращать инженерные трудозатраты, а не увеличивать их, с учетом имеющихся навыков. Разумеется, я прекрасно понимаю, что после создания такие тестовые платформы в дальнейшем требуют значительных инженерных трудозатрат на поддержание их работы и расширение.

• Поддержка сообщества важна, когда дело касается программного обеспечения с открытым исходным кодом. Ну и самое последнее, любые выбранные платформы должны быть написаны на распространенном языке программирования, таком как Go или Python. Если понадобится углубиться в платформу и написать собственные методы, найти инженера с опытом работы с одним языком будет, пожалуй, проще, чем с двумя. Любой предыдущий опыт работы с подобными инструментами, который может быть у имеющихся сотрудников группы и организации в целом, также будет полезен. Итак, теперь я готов отправиться на поиски правильного средства тестирования и платформ для выполнения этой работы.

• tflint github.com/terraform-linters
• terrafirma github.com/wayfair/terrafirma
• tfsec github.com/liamg/tfsec
• terrascan github.com/cesar-rodriguez/terrascan (на данный момент отсутствует поддержка TF 0.13)
• checkov github.com/bridgecrewio/checkov
• conftest github.com/instrumenta/conftest

Выбранные средства тестирования

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

Модульное тестирование Checkov от BridgeCrew

Checkov это инструмент статического анализа кода для инфраструктуры как кода.

Он сканирует облачную инфраструктуру, подготовленную с помощью Terraform, Cloudformation, Kubernetes, Serverless или шаблонов ARM, и выявляет неправильную конфигурацию с точки зрения безопасности и соблюдения нормативных требований.

• Установите двоичный файл.
• Инициализируйте каталог terraform командой terraform init.
• Запустите chechov для этого каталога.

Вывод после работы checkov с указанием пройденных и непройденных проверок.

Terraform-compliance

Terraform-compliance это облегченная платформа тестирования, предназначенная для проверки безопасности и соблюдения нормативных требований в terraform для обеспечения совместимости вашей инфраструктуры как кода с отрицательным тестированием.

Предыстория

Тестирование с помощью Terraform-Compliance

• Шаг 1. Инициализируйте каталог terraform:# terraform init
• Шаг 2. Можно быстро сформировать terraform plan следующей командой: #terraform plan -out=plan.out
• Шаг 3. Напишите несколько тестов. Дело нехитрое уже есть папка с примерами. Давайте пройдемся по моим собственным примерам тестов, приведенным ниже, написанным на основе моего вывода terraform plan.

• Шаг 4. Давайте заставим terraform-compliance оценить плат с использованием тестовых сценариев: #terraform-compliance -p plan.out -f ./<test-cases-folder>

Выполнение тестов

Результаты тестов

Итоги

Узнать подробнее о курсе Infrastructure as a code in Ansible.

Записаться на открытый урок по теме Управление Kubernetes при помощи Kubespray.

Нам нужно быть уверенными что при каждом пуше у нас не сломается вся инфраструктура, сможешь сделать? -Легко!

composer require overvoidjs/exotest:dev-master

<?php include_once 'vendor/autoload.php';

<?php include_once 'vendor/autoload.php';$i = new Exo;$url = 'http://localhost:7888/catalog/instrumentyi/';$i->is_ok($url, '<div class="product-card-name">');

php test.php

$payload = [  'product_id'=>'3401',  'count'=>'1'];@$cart_id = $i->post_it('http://localhost:7888/api/cart/add',$payload);if(is_int($cart_id)){    echo "API Добавления в корзину ...  Ok \n";} else {   echo "API Добавления в корзину ...  FAIL \n";}

echo "API Добавления в корзину ... \033[32m Ok\033[0m \n";

echo "API Добавления в корзину ... \033[01;31m FAIL\033[0m \n";

//Тут необходим CURL - но думаю он у всех есть$i = new Exo;$url = 'https://site.com/api/sameimg';$payload = [  'data'=>'data'];$post_file_name = 'new_img';$post_file_path = './new_img.jpg';$test = $i->post_it_file($url,$payload,$post_file_name,$post_file_path);

 input type="file" name="new_img" 

Всем привет!

Автотесты под Android это непросто. Чтобы выстроить процесс автотестирования, надо запланировать и решить множество задач. Но самая большая беда заключается в том, что нигде нет полного описания, что вообще включает в себя автотестирование под Android, каковы его основные стадии. Отсутствует цельная картина. Этой статьей мы хотим восполнить пробел.

Она также выступит в роли схематичной дорожной карты работы Avokado Project. Мы верим в то, что в скором времени разворачивание автотестирования будет занимать куда меньше времени, чем сейчас. И активно работаем в этом направлении.

Зачем нужны автотесты?

Есть мнение, что UI-тесты не нужны, если у вас достаточное количество юнит- и интеграционных тестов. Но от следующей метафоры никуда не деться. Представьте, что вы собираете велосипед. У вас есть два хорошо протестированных колеса, протестированная рама вместе с седлом, протестированная система педалей с цепью и рулем. То есть мы с вами имеем хороший набор интеграционных и юнит-тестов. А велосипед-то в итоге поедет? Чтобы это проверить, вы нанимаете ручных тестировщиков, которые перед каждым релизом должны убедиться, что безупречные детали корректно взаимодействуют друг с другом, и велосипед будет ездить и доставлять пользователю удовольствие.

Так же и с любым программным обеспечением для мобилок. К сожалению, в мобильном мире мы не можем откатить неудачные изменения быстро, ведь все обновления идут через Google Play Store и App Store, что сразу накладывает ограничения в виде долгой раскатки в сравнении с веб- и backend-аналогами, обязательной совместимости версий и зависимости от решения пользователя обновляться или нет. Поэтому нам критически важно всегда убеждаться перед релизом, что основные пользовательские сценарии приложения работают именно так, как ожидается.

При этом, когда релизный цикл у вас длиной в несколько месяцев, вполне достаточно работы ручных тестировщиков и некоторого покрытия кода юнит- и интеграционными тестами. Однако во времена, когда релизный цикл стремительно сокращается до одной-двух недель (а то и еще меньше), сил ручных тестировщиков зачастую уже не хватает, что вынуждает или жертвовать качеством проверки, или нанимать больше специалистов.

Все это естественным образом подводит к необходимости автоматизации проверки пользовательских сценариев, то есть написания end-to-end- или автотестов. У Авито есть рассказ о том, как автотесты помогают и сколько они стоят (2019 год). Однако большинство команд такой метод отпугивает своей сложностью и необходимостью вкладывать существенные ресурсы, чтобы выстроить процесс. Это возвращает нас к цели данной статьи и вообще к одной из целей Avokado Project стандартизировать процесс автотестирования в Android и существенно уменьшить его стоимость.

Картина целиком

Итак, обещанная картина целиком.

Если вы чего-то не понимаете, не переживайте. Мы сейчас пройдемся подробно по всем пунктам.

Процесс написания тестов

На первом шаге давайте попробуем написать тесты у себя на машине и запустить их локально.

Выбор инструментов для написания автотестов

Стоит сразу определиться со стеком технологий, который мы будем использовать для написания тестов.

Первая развилка это выбор между кроссплатформенным решением (Appium и т. д.) и нативным решением (Espresso, UI Automator). Много копий сломано в этих спорах. Рекомендуем посмотреть выступление наших коллег, полное драматизма и накала страстей.

Спойлер мы за нативные решения. По нашему опыту, они:

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

Кроме того, Google поддерживает Espresso и UI Automator.

Больше почитать про сравнение вы можете в статьях:

• Appium vs Espresso: Key Differences.
• Appium vs. Espresso: Which Framework to Use for Automated Android Testing.
• Appium vs Espresso: The Most Popular Automation Testing Framework in 2019.

На чистом Espresso и UIAutomator нынче редко кто пишет. Разработчики сделали различные удобные обертки, которые решают их проблемы. Сейчас у нас готовится статья об этих инструментах с классификацией и сравнением. Если кратко, то фреймворк, на который мы делаем ставку, это Kaspresso.

Kaspresso

Kaspresso это фреймворк, который:

• предоставляет DSL, значительно облегчающий написание автотестов;
• дает встроенную многоуровневую защиту от флекающих тестов;
• ускоряет работу UI Automator;
• предоставляет полные логи о том, что происходит в тесте;
• дает возможность запуска любых ADB-команд внутри тестов;
• предоставляет механизм интерцепторов для перехвата всех действий и проверок. На данном механизме построено логирование и защита от нестабильных тестов;
• описывает лучшие практики (исходя из нашего опыта) по написанию автотестов.

Вы можете прочитать о Kaspresso на GitHub и Habr.

Test runner

Вы написали несколько тестов. Теперь их нужно запустить. За этот этап отвечает Test Runner, или просто раннер.

Что нам предлагает Google? Утилиту AndroidJUnitRunner и ее специальный режим Orchestrator. AndroidJUnitRunner делает то, что от него и требуется просто запускает тесты, позволяя еще и параллелить их выполнение. Orchestrator позволяет продолжить выполнение тестов, даже если некоторые из них упали, и дает возможность минимизировать общее состояние между тестами. Так достигается изоляция исполнения каждого теста.

Но со временем требований к раннеру становится все больше. Вот некоторые из них:

• запускать отдельные группы тестов;
• запускать тесты только на определенных девайсах;
• перезапускать упавшие тесты (вторая волна защиты от последствий нестабильных тестов после Kaspresso);
• эффективно распределять тесты по девайсам с учетом истории прогонов и успешности предыдущих запусков;
• подготавливать отчеты о прогоне в разных форматах;
• отображать результаты прогона (желательно Allure based);
• поддержать истории прогонов для дальнейшего анализа;
• просто интегрироваться с вашей инфраструктурой.

На рынке есть несколько сторонних раннеров. Среди всех них, самым перспективным мы считаем Marathon, который довольно быстро настраивается и удовлетворяет части обозначенных выше требований. Например, он поддерживает распараллеливание тестов и подготовку результатов прогона в формате, пригодном для отображения в Allure.

Однако, Marаthon, к сожалению, не обладает некоторыми важными, по нашему мнению, свойствами. В частности, в нем нет:

• Простой и нативной интеграции раннера с инфраструктурой, которая выдает эмуляторы. А еще лучше возможности сразу же запустить ваши тесты в облаке. Впрочем, это проблема не только Marathon к сожалению, ни один известный нам раннер не берет на себя ответственность за получение эмуляторов, это всегда ложится на плечи разработчиков.
• Плотной интеграции с фреймворками типа Kaspresso для получения максимальной, точной и корректной информации о тесте.

Кроме того, мы считаем, что раннер должен быть проприетарным, то есть либо для Android, либо для iOS. Это обусловлено уникальной спецификой каждой ОС и вытекающей отсюда сложностью внесения изменений в раннер.

Поэтому прямо сейчас мы работаем над Avito Runner, в котором хотим собрать все лучшие и зарекомендовавшие себя наработки и идеи. Ждите будущих анонсов!

На чем запускать тесты

Параллельно с вопросом о том, какой раннер выбрать для тестов, перед вами встает другой: а на чем лучше запускать тесты? Есть три опции:

1. Настоящий девайс.
   Плюсы. Покажет проблемы, специфичные для конкретных устройств и прошивок. Многие производители меняют Android под себя как UI, так и логику работы ОС. И бывает полезно проверить, что ваше приложение корректно работает в таком окружении.
   Минусы. Необходимо где-то добыть ферму устройств, организовать специальное помещение под них необходима низкая температура, нежелательно попадание прямых солнечных лучей и т. д. Кроме того, аккумуляторы имеют свойство вздуваться и выходить из строя. А еще сами тесты могут менять состояние устройства, и вы не можете просто взять и откатиться на какой-то стабильный снепшот.
2. Чистый эмулятор.
   Под чистым мы подразумеваем, что вы запускаете эмулятор у себя или где-то на машине, используя установленный на эту машину AVD Manager.
   Плюсы. Быстрее, удобнее и стабильнее настоящего устройства. Создание нового эмулятора занимает считаные минуты. Никаких проблем с отдельным помещением, аккумуляторами и прочим.
   Минусы. Отсутствие упомянутых выше device specifics. Однако зачастую количество тестовых сценариев, завязанных на специфику устройства, ничтожно мало, и они не высокоприоритетные. Но самый главный минус это плохая масштабируемость. Простая задача залить новую версию эмулятора на все хосты превращается в мучение.
3. Docker-образ Android-эмулятора.
   Docker решает недостатки чистых эмуляторов.
   Плюсы. Docker и соответствующая обвязка в виде подготовки и раскатки образа эмулятора это полноценное масштабируемое решение, позволяющее быстро и качественно готовить эмуляторы и раскатывать их на все хосты, обеспечивая их достаточную изолированность.
   Минусы. Более высокий входной порог.

Мы делаем ставку на Docker.
В сети есть разные Docker-образы Android-эмуляторов, мы рекомендуем обратить внимание на следующие:

• Docker image от Avito;
• Docker image от Google;
• Docker image от Agoda.

Как уже было упомянуто выше, подготовка образа требует некоторой сноровки. Плюс зачастую есть желание эмулятор преднастроить: выключить анимацию, залогиниться в аккаунт Google, выключить Google Play Protect и многое другое. Все эти вещи непросто организовать. Поэтому в скором времени мы хотим выкатить подробную документацию о том, как готовить и использовать образы быстро.

Инфраструктура

Вы написали сотни UI-тестов. Часть из них вы хотите запускать в рамках PR, а значит, весь тестовый набор должен проходить в максимально короткие сроки, например, до 20 минут. Вот тут наступает настоящее масштабирование.

Однако эта область темный лес для части Android-разработчиков и автоматизаторов. Оно и немудрено, ведь инфраструктура требует знаний железа, конфигурирования серверов, DevOps-практик и прочего. Поэтому обязательно наладьте контакты с людьми, которые во всем этом разбираются, у себя в компании или вовне, ведь они сильно помогут и уберегут вас от ошибок.

Итак, что вам примерно предстоит:

• Выбор между облачным решением, локальным решением с нуля и локальным решением на базе чего-то, если в компании есть своя инфраструктура по запуску тестов других платформ.
• Самое трудоемкое это развертывание внутренней инфраструктуры с нуля. В этом случае необходимо подобрать железо, которое будет максимально использоваться автотестами. Придется измерять нагрузку на CPU/GPU/Memory/Disk, а еще пробовать разное количество одновременно запущенных эмуляторов и смотреть за стабильностью тестов. Это большая тема, по которой мы хотим провести современные замеры и поделиться с вами своими рекомендациями.
  Дальнейшая накатка необходимого ПО, встраивание в сети и прочее это все за DevOps-инженерами.
• На выходе должен быть какой-то сервис, единая точка, которая отдает вам эмуляторы. Это может быть Kubernetes, может быть облачный сервис типа Google Cloud Engine или какое-то кастомное решение.
  В его настройке опять-таки помогают DevOps-инженеры.
• Связка полученного сервиса с Test Runner.
  Одна из задач AvitoRunner сделать такую связку максимально простой и прозрачной, а также предоставить точки расширения, которые помогут вам легко внедрить свой кастомный сервис.

В ближайшее время мы планируем выпустить AvitoRunner и статьи, которые помогут настроить инфраструктуру.

Остальное

Не забывайте про такие немаловажные моменты, как:

• вывод отчета по прогону тестов (Allure);
• внедрение/синхронизация с TMS;
• интеграция в CI/CD;
• обучение разработчиков и тестировщиков;
• процессы кто, когда, сколько и какие автотесты пишет.

Про все это мы еще обязательно поговорим.

Заключение

Мы постарались описать основные части становления автотестирования под Android. Надеемся, что теперь у вас в головах сложится тот самый пазл, который позволит видеть картину целиком.

Следите за анонсами на нашем сайте и в телеграм-канале.

Ведение документации для тестирования в 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%.

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