Qase io что это
Перейти к содержимому

Qase io что это

  • автор:

Qase.io

Qase — современная система управления тестированием объединяющая как ручное, так и автоматизированное тестирование. Для ручного тестирования предусмотрен широкий функционал для управления тест-кейсами, включая возможности по переиспользованию шагов и проведения Test Case Review. Специальный помощник для тестовых прогонов позволит сократить время на проведение ручного тестирования и покажет примерное время необходимое на выполнения тестового прогона. Для автоматизированного тестирования представлена возможность отправки результатов выполнения автотестов и их агрегация в отчетах.

Обзор системы управления тестированием Qase

Тестирование является неотъемлемой часть процесса разработки ПО и от того как он построен зависит множество различных факторов: качество выпускаемого продукта, скорость доставки новых фич до конечного пользователя и другие. Сейчас на рынке есть большое количество различных инструментов, которые помогают командам управлять процессом тестирования: TestRail, Zephyr, TestLink и десятки других. Сегодня речь пойдет об инструменте Qase. Это будет обзорная статья рассказывающая об основных принципах и нюансах работы с приложением.

Что такое Qase?

Qase.io это облачная система управления тестированием позволяющая командам эффективно хранить и систематизировать тестовую информацию по продукту, а так же организовать работу команды. Основной функционал TMS:

  • Управление тестовой моделью
  • Подготовка тест-планов
  • Запуск тестовых прогонов
  • Интеграция с популярными таск-трекерами
  • Управление командой и правами доступа
  • Работа с дефектами
  • Кастомизация полей и интерфейса
  • API и Вебхуки

Проекты

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

Репозиторий

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

Дерево сьютов технически не имеет ограничений на вложенность и количество кейсов хранящихся в них. С помощью функции drag’n’drop можно легко менять порядок кейсов, а так же перемещать их между сьютами. Если кликнуть на название любого кейса, то справа откроется боковая панель с предварительным просмотром, в котором отражена основная информация. При нажатии на название кейса в превью произойдёт переход на страницу с полной информацией по тест-кейсу.

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

Тест-кейсы

Тестовые сценарии лежат в основе любой тестовой модели. В Qase, у каждого кейса есть следующие поля:

  • Title — название тест кейса
  • Description — краткое текстовое описание тестового сценария
  • Suite — к какому сьюту относится кейс
  • Severity — определяет влияние созданного дефекта на основе этого кейса на работоспособность ПО
  • Priority — приоритет исправления выявленного дефекта на основе этого кейса
  • Type — тип кейса (функциональный, тест на безопасность и т.д.)
  • Behavior — поведение тест-кейса (позитивное, негативное, деструктивное)
  • Milestone — релиз в котором добавлен кейс
  • Preconditions — поле для описания того, что нужно сделать чтобы подготовить систему к тестированию
  • Postconditions — поле для описания того, что нужно сделать чтобы привести систему в первоначальное состояние
  • Automation — флаг, который указывает на то что кейс автоматизирован
  • Deprecated — флаг, которым можно отметить устаревшие тест-кейсы
  • Steps to reproduce — шаги по воспроизведению. Каждый кейс может содержать неограниченное количество шагов по воспроизведению. Можно добавлять как обычные шаги, так и общие
  • Attachments — вложения любого типа (файлы, картинки, видео)

В настройках проекта, любое из этих полей можно скрыть.

Общие шаги

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

Тест планы

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

Qase автоматически подсчитает время, необходимое на прогон каждого такого плана на основе исторических данных.

Так же, при составлении набора, можно предварительно указать того, на кого кейс будет назначен при запуске прогона:

Тестовые прогоны

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

Dashboard

На экране дашборда выводится следующая информация:

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

Сценарии в прогоне могут иметь следующие статусы:

  • Untested — еще нет результатов по проверке
  • Passed — успешно пройден
  • Failed — обнаружен баг при прохождении / заведен дефект
  • Blocked — дальнейшее прохождение заблокировано (например дефектом в другом кейсе
  • Retest — тест кейс нужно проверить еще раз
  • Skipped — временно пропущен

К любом кейсу можно добавить несколько результатов выполнения:

Если есть необходимость поделиться отчетом по прогону, но не давать доступ к самой TMS, можно включить для него публичную ссылку и любой посетивший ее сможет увидеть страницу аналогичную дашборду с урезанными правами.

Wizard

Для выполнения ручных прогонов в Qase предусмотрен инструмент, который шаг за шагом проведет по тестовому сценариям в прогонах:

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

Дефекты

Qase предоставляет возможность хранения информации о найденных дефектах и управление их жизненным циклом. Если на этапе тестового прогона, найден дефект, визард предложит сохранить информацию о нем:

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

Настройки проекта

Общие настройки

У каждой команды свой подход к ведению тестовой модели и флоу работы с тестовыми прогонами. Qase позволяет настроить используемые поля в тест кейсах и полностью убрать те, которые не нужны. Единственное что нельзя убрать — название тест кейса.

Для настройки поведения визарда во время тестового прогона сейчас есть три возможные опции:

  • Fast pass — позволяет включать/выключать добавление результата прохождения успешного тест кейса (если нужно добавить комментарий или прикрепить скриншот)
  • Auto assignee — автоматическое назначение тест кейса (если он заасайнен ни на кого) на первого открывшего тест кейс. Удобно в том случае, если каждый тестировщик может брать любой кейс на тестирование. Если опция выключена, то потребуется ручное назначение на себя.
  • Step fail — если эта опция включена, то при первом указанном как failed шаге, весь тест кейс будет отмечен как failed и появится модальное окно с описанием дефекта.

Интеграции

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

  • Jira (Server & Cloud)
  • Redmine
  • YouTrack
  • GitHub
  • Slack

При создании нового дефекта, в первых четырех системах будет создана новая задача с описанием как этот самый дефект воспроизвести. Так же интеграции поддерживают заполнение обязательный полей в Jira, Redmine или YouTrack.

Кастомные поля

Функция доступна при наличии подписки на Business план. Позволяет создавать дополнительные поля для тест кейсов. Сейчас поддерживаются поля следующих типов:

  • Число
  • Строки
  • Чекбокс
  • Текст
  • Выпадающий список

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

  • Multiselect
  • User picker
  • Datetime picker

Настройки доступа

Часто встречаются ситуации, когда нужно создать проект, доступ к которому будет только у ограниченного числа членов команды (например проект биллинга). Делается это из раздела “Project Access”.

Сейчас сложно себе представить любое облачное приложение, у которого отсутствует API. В Qase, API является частью платного тарифа Business и для него, как и для вебхуков, требуется подписка. API предоставляет доступ практически ко всем сущностям используемым в приложении и позволяет гибко настроить интеграцию с CI вашего приложения. Полная документация по API доступна по ссылке.

Webhooks

Вебхуки представляют собой запросы, отправляемые с серверов Qase на указанные эндпоинты. Триггером для отправки такого запроса является событие произошедшее в приложении, например запуск тестового прогона или редактирование тест кейса. При создании вебхука можно гибко указать, на основе каких событий его нужно отправлять. Документация по пейлоадам доступна по ссылке.

Команда

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

Роли

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

Единственная роль, которую нельзя редактировать это Owner — владелец команды. Он имеет доступ ко всем проектам и все права. Роль владельца можно передать другому пользователю.

Работа в нескольких командах

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

Заключение

Надеюсь, что после прочтения данного обзора, у вас появилось представление о текущих возможностях системы управления тестированием Qase.io. В дополнение, хочу сказать, что у проекта существует публичный Roadmap, в который каждый может добавить feature request или проголосовать за уже добавленные запросы другими пользователями.

В следующей статье расскажу, как настроить запуск автотестов напрямую из интерфейса приложения.

Qase

Основанная в 2018 году бывшим техническим менеджером Avito Никитой Федоровым компания Qase из США занимается разработкой решений для управления тестированием ПО. Компания предлагает интеграцию с инструментами Asana, Github, Jira, Trello по модели корпоративной подписки и позволяет публиковать задачи на площадках в автоматическом режиме.

История

2021: Привлечение $0,5 млн

В середине августа 2021 года разработчик платформы управления тестированием ПО Qase привлек $500 тыс. в рамках посевного раунда. Раунд возглавил фонд S16VC при участии FinSight Ventures и ExpoCapital. Привлеченные средства позволят компании укрепить свою команду по развитию и маркетингу, а также наладить больше партнерских отношений в США и Европе. Основатель и генеральный директор компании Никита Федоров отметил, что компания планирует удвоить численность своей команды, которая к августу состоит из 10 человек.

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

Разработчик платформы для управления тестированием ПО Qase привлек $0,5 млн

Рассказывая об открытии Qase гендиректор компании Никита Федоров отметил:

Федоров работал над своей идеей два года, прежде чем появилась первая версия Qase, которая почти сразу получила хорошую поддержку. Что касается будущего тестирования ПО, Федоров говорит, что QA-инженеры должны прекратить выполнение ручного тестирования, чтобы сосредоточиться на исследовательском тестировании и общем качестве продукта. [1]

Примечания

Туда, не зная куда: каким мы увидели Qase

Меня все еще зовут Ильмир, и моя тушка продолжает работать в компании inDriver. В статье постараюсь дать краткое описание того, как выглядит система управления тестированием Qase. При этом будут небольшие помарки там, где есть отличия от TestRail, который мы использовали ранее.

А вот тут сразу вторая часть про TMS.

Небольшая предыстория

В один не очень прекрасный день мы начали думать о переходе c TestRail на другую Test Management System (TMS). Все потому, что TestRail стал выдавать неприятные для нас баги.

Поиск новой системы стал неизбежностью. И сразу началось гугление. Большая часть найденных статей описывала каждую систему в общем — это TMS, она позволяет хранить и редактировать кейсы. А вот список ее возможностей. Но этого было недостаточно. Итогом наших недолгих поисков стал Qase.

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

В статье будет небольшой обзор системы. Я кратко коснусь основных вопросов, на которые наша команда хотела знать ответы, и которые мы получили на демо и в процессе перехода.

Общий вид

Вверху видим меню, которое делит ресурс на части:

Меню

  • Project — содержит проекты, которые мы выбираем в списке из созданных. Можно создать свой проект. Тут же находится список кейсов, раны, планы и прочее.
  • Workspace — настройка рабочего пространства (пользователи, пол, роли).
  • Reports — отчеты и запросы.
  • Apps — интеграции.

Проекты могут быть представлены в виде списка или карточек:

СпискиКарточки

Здесь можем создать новый проект, найти его, отфильтровать и добавить в избранное. Последнее позволяет всегда держать выбранные проекты первыми в списке. Для каждого проекта можно выбрать иконку — очень удобно.

Перейдем к более подробному рассмотрению.

Репозиторий кейсов

Вот как выглядит это раздел:

Репозиторий

Что мы здесь видим:

  • Меню действий с кейсами — появляется, только если выбрать несколько кейсов. Действия видны на кнопках.
  • Список кейсов — содержит иконку автоматизации (рука с шестеренкой, которой настраивается уровень автоматизации), ID кейса и название. Внизу есть кнопка быстрого создания кейса. Около названия сьюта 4 кнопки — создание сьюта или кейса, редактирование описания, клонирование и удаление.
  • View — способ отображения кейсов. Все в одну длинную портянку или каждая папка отдельно.
  • Меню действий — экспорт, импорт кейсов. А также крайне удобная корзина. Никакой кейс никогда не удалится, а просто будет в корзине.
  • Список сьютов в проекте — содержит название и количество кейсов в нем.
  • Счетчик кейсов — содержит общее число сьютов и кейсов. Если применить фильтр, будет содержать значения согласно выставленных фильтров.
  • Добавление фильтров.

Кратко о плюсе TestRail по этому разделу — там можно добавить отображение информации о дополнительных полях в список. В Qase такого, к сожалению, пока еще нет.

Как выглядит кейс при разных способах открытия:

Тапнули на название кейса — открылся такТапнули на ID кейса в списке — открывается превью

Режим редактирования представлен в двух скринах:

Редактирование №1Редактирование №2

  • Сверху стандартные системные поля, далее пред- и постусловия.
  • Теги.
  • Кастомные поля.
  • Аттачи.
  • Параметры. Пример использования — ввели 2 параметра, и в прогоне уже 2 идентичных кейса, по одному на каждый параметр. В репозитории по-прежнему всего один кейс.

Для самих шагов и ОР предусмотрена панель инструментов, которая избавляет от необходимости держать маркдаун в голове (всегда мучился с этим в TestRail). Цвет шрифта, тип, 2 вида списка, линки, таблицы, изображение, блок кода и прочее.

Панель инструментов

Shared Steps

Здесь содержится список Shared Steps для проекта. Доступно создание шареда и его редактирование, а также поиск по имеющимся.

Удобно тем, что они хранятся не в общей куче, для каждого проекта свой набор. Их без проблем можно редактировать и тут же создавать. Как можно заметить — отображается количество кейсов, в которых он используется:

Shared Steps

Минус — можно создать шареды с одинаковым названием. И только тут можно сделать его из двух и более шагов.

При создании шареда в режиме редактирования кейса создавать можно лишь из одного шага:

Создание Shared Step

Майлстоуны

Используется для обозначения вехи в разработке. В Qase не смог обнаружить отличия от собрата TestRail. Доступен в рамках проекта, что логично. Мы его практически не используем.

В описании списка содержится базовая информация о нем. К сожалению, на данном экране пока нет фильтрации.

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

Майлстоун

План

Здесь все более интересно:

План

Главное отличие Qase от TestRail — план представляет собой шаблон для будущего рана. В TestRail это была сущность, которая позволяла объединить раны.

План содержит название и предполагаемое время прогона — формируется на основе срока прохождения кейсов (если они прогонялись). Удобно, если хотите дать прогноз по времени прогона.

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

Из минусов — нет динамических фильтров. Если набрали кейсы по условию, а потом они перестали туда входить — план не изменится.

Ассайненные кейсы в плане

Тестовые раны

Как и в TestRail, это набор кейсов для их прогона в рамках релиза или фичи. Особенность — есть визард, своеобразный интерфейс для прохождения рана.

Несколько входных точек для создания рана:

Тестовые раны

  1. Выбрать план — на его основе создать ран.
  2. Зайти в раздел Test Runs — создать там.
  3. Выделить один или более кейсов в репозитории — стартовать при помощи панели действий (кнопка Run).
  • Слева — список кейсов. Можно фильтровать их так, как нужно.
  • Справа — сам кейс. Вверху результат для кейса, под каждым шагом — свой результат.
  • Кнопки View и Edit открывают кейс в новом окне для просмотра и редактирования соответственно. Изменения в кейсе ведут к изменению кейса в ране после обновления страницы.
  • Кастомные поля отображаются в ране над шагами (видим на примере поля AndroidResult).
  • Case Run History — история прохождения кейса. Отображает результат прогона в прошлых ранах.

Из минусов — не видно, что вписали в коммент при прохождении кейса. Нужно открыть общий список кейсов в ране (*закрыв визард) и нажать на лейбл результата. А если не проставить результат каждому шагу кейса — не увидишь шагов в пройденном кейсе.

Мне кажется, в TestRail удобнее, так как можно сразу увидеть во вкладке, что было в прошлом ране.

Вид рана с закрытым визардом

Видим список кейсов, при выделении доступно еще несколько действий. В боковом меню — диаграмма статусов кейсов (при нажатии выполняется фильтрация по выбранному статусу) и немного инфы (кто стартовал и во сколько).

Вкладка Team stats покажет, кто сколько прошел:

Team stats

Настройки

Логично, что содержит настройки проекта:

Настройки

Название, кодик (это и будет ID кейса), описание и тип. Также имеются вкладки интеграции, веб-хуков, конфигурации и настройки.

Особый интерес представляет вкладка Settings — в ней можно задать настройки для запуска и завершения ранов, подтверждения удаления кейса и отображения полей в кейсах проекта.

Рабочее пространство

Здесь мы видим следующее:

Рабочее пространство

  • Members — список участников: их роль, имя и время последней активности. Позволяет блокировать и разблокировать пользователей. Есть фильтры по статусу (активен или заблокирован), роли и типу (full или read only).
  • Invites — приглашения. Содержит список высланных инвайтов. На странице имеется возможность отзыва инвайта.
  • Groups — используется при создании приватного проекта. При создании проекта с выдачей доступа только к определенной группе.
  • Roles — роли в TMS. Регулирует возможности пользователя под определенной ролью. Доступно создание роли, ее удаление или редактирование.
  • Fields — системные и кастомные поля, создание или редактирование, а также удаление.
  • Tags — сущность, доступная для кейса, рана и прочей фильтрации.
  • Attachments — полный список всех аттачей (фото и прочее). Есть возможность поиска, можно указать, в каком проекте задействован тот или иной аттач.
  • Logs — полный лог действий всех пользователей. Доступна различная фильтрация.

Поля и роли

Во вкладке Field мы можем настраивать системные и кастомные поля. Кастомные можем создавать тут же:

Поля

Все поля в одном месте — удобно, для каждого можно настроить видимость того или иного проекта.

Редактировать поле (кастомное или системное) — пожалуйста, кроме системных полей Automated, isFlaky, Status. Также не сможете сменить тип поля (допустим, с Single List на Multi List). Все остальное редактируется удобно и быстро.

Редактирование поля №1Редактирование поля №2

При редактировании задается название (не для системных) полей, направленность (кейс или ран) и тип. Далее выбирается видимость для проекта и дефолтное значение.

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

А теперь расскажу про роли:

Роли

Видим список ролей, тип и то, является ли поле дефолтным. Отображается количество юзеров на каждую роль:

Создание роли

При создании задаем название, описание и выбираем, что доступно для нее.

Репорты

На данной странице можно создать и увидеть:

Дашборд

  • Дашборд — информация о проекте или проектах. Содержится часть информации о кейсах и прочих данных. Создаются один или несколько виджетов для отображения информации по кейсам, ранам или дефектам.
  • Запрос — создается запрос на QQL (аналогичен расширенному поиску в Jira). Выполняется поиск по проектам согласно условиям (статус, проект, название и прочее). Памятка по QQl откроется, если в строке поиска нажать на иконку вопросика.

Каждый запрос можно редактировать так, как вам угодно:

Запросы

  • Сохраненные запросы — здесь хранится список сохраненных запросов:

Сохраненные запросы

  • Профиль. При клике на него увидим следующее:

Профиль

  • Billing — кнопка перехода на оплату. Содержит информацию об оплате текущей подписки, а также историю платежей (доступ зависит от роли).
  • Appearance — выбор темы из предложенных.
  • API tokens — создание API-токена.
  • Profile — настройка профиля, изменение имени, пароля, подписка на уведомления и добавление фото.
  • Help — центр помощи.
  • API docs — документация по API.
  • Roadmap — роадмап продукта. Показывает, какие фичи запланированы, какие в работе, а какие уже реализованы.
  • Status — информация об инцидентах, текущее состояние продукта
  • Sign out — кнопка выхода. Выбор тем

Итог

Безусловно, одной статьи мало для обзора такого большого инструмента. Но, надеюсь, она поможет вам в выборе решения. В будущем постараюсь написать небольшой расширяющий материал о том, как мы перекочевали из TestRail.

Итогом перехода на Qase для нас стало отсутствие критических багов и сохранение спокойствия во время работы. Да, эта TMS не идеальна, но она лучше TestRail. И ее использование это доказало.

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

При переходе на Qase было задано море вопросов, на каждый из которых мы получали подробный и развернутый ответ в течение 1-2 часов максимум. Количество вопросов, как вы понимаете, было огромным. Но нам отвечали со спокойствием сытого тибетского удава.

P.S. Если вам интересна тема, прикрепляю ссылки на YouTube-канал и GitHub Qase, где можно подробнее узнать о возможностях системы.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *