QA Meetup от OneTwoTrip: опыт внедрения Allure TestOps в OneTwoTrip

Продолжаем делиться с вами докладами с QA Meetup, который мы провели в Санкт-Петербурге 11 июля. Сегодня — выступление Дмитрия Водолаго, QA Mobile Lead OneTwoTrip, который рассказал, почему в компании выбрали систему тест-менеджмента Allure TestOps и насколько оправданным оказался переход на неё с TestIT.

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

О спикере

QA Meetup от OneTwoTrip: опыт внедрения Allure TestOps в OneTwoTrip

Дмитрий Водолаго — QA Mobile Lead в OneTwoTrip. В тестировании он более 6 лет, за это время работал как в продуктовых командах, так и в международных стартапах.

В компанию Дмитрий пришёл совсем недавно — к моменту выступления проработал только 4 месяца. И даже за такой короткий срок успел реализовать довольно важный для сервиса проект.

Зачем понадобился переход с Test IT и почему на Allure TestOps

Прежде в OneTwoTrip использовали систему тест-менеджмента (test management system, TMS) под названием Test IT. И всё было хорошо до автоматизации. Но интеграция с автотестами стала работать нестабильно, регулярно возникали ошибки.

Вот в чём именно были проблемы:

  • Интеграция UI-тестов происходила через скрипт. Но после каждого обновления Test IT импорт тестов ломался.
  • Для каждого проекта приходилось писать отдельную интеграцию, поэтому не для всех проектов можно было прокидывать результаты.
  • Не работал запуск автотестов из проекта с кейсами, и их постоянно запускали через Jenkins.
  • Автотесты нельзя было удалить из проекта с кейсами.

Такие сложности, конечно, никого не устраивали, поэтому было принято решение подобрать другую TMS. Мы с командой изучили доступные варианты и остановились на Allure TestOps: из представленных на рынке вариантов она имела больше всех возможностей и удобств (по крайней мере, так было заявлено).

О самой Allure TestOps я рассказал отдельно (3:08). Она довольно серьёзно отличается от обычных TMS, где структура редактируется через drag-n-drop: имеющиеся папки можно просто перетаскивать с места на место. Но в Allure TestOps вместо этого используют атрибуты — и это не слишком привычно. Потребовалось время, чтобы такой подход перестал создавать когнитивную нагрузку, но в итоге мы обнаружили, что это довольно удобно. Когда данных очень много, вместо ручного перетаскивания действительно проще фильтровать их по необходимым атрибутам для переноса. Фактически это следование философии и практикам DevOPS. Работает такой подход хорошо, когда проставлено достаточное количество атрибутов.

Как проходила миграция

План перехода был простым и понятным и выглядел следующим образом. Вот что нужно было сделать:

  • Мигрировать данные.
  • Привести в порядок структуру проекта.
  • Начать использовать новую TMS для ручного тестирования.
  • Настроить интеграцию с автотестами.

На скриншоте, который я показал на 1:45, видно количество тест-кейсов в одном из мобильных проектов.

Для самой миграции данных команда использовала готовый скрипт от TestOPS, который тестировщики несколько раз прогоняли и в процессе настраивали под свои задачи. Кстати, всего было перенесено примерно 1 500 кейсов.

Конечно, возникли и некоторые сложности:

  • Пришлось постараться, чтобы корректно настроить JSON для переноса.
  • В Test IT и TestOPS разная структура формирования проекта, поэтому случился рассинхрон.
  • Из-за разницы в структуре неудачно были перенесены некоторые тексты и изображения.

Решение было довольно простым: ребята перезапускали скрипт, а если что-то по-прежнему переносилось некорректно, структуру и картинки правили вручную. Это заняло некоторое время, в но целом работа была довольно простая.

О пользовательском опыте при работе с Allure TestOPS

О нём можно узнать с 5:40. Первое, что вызвало у нас вопросы, — то, как собираются тест-планы. Есть два варианта: через AQL, внутренний язык запросов, либо выбором вручную. Использовать фильтр дважды, то есть сделать одну выборку, а потом проставить в ней фильтры ещё раз, нельзя. Когда нужно отобрать мало кейсов, это работает нормально, но если кейсов много, подход не слишком удобен.

Ещё один сложный момент в том, что кейсы нельзя расставить в определённом порядке: они сортируются по дефолтным атрибутам — по id, алфавиту, дате создания. Например, поставить букву «б» раньше буквы «а» нельзя — а иногда другая сортировка необходима.

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

Все эти нюансы пока удалось решать частично: что-то спрашивали у службы поддержки TMS (кстати, отвечали очень быстро), другие моменты отправили в feature request, так что, возможно, через некоторое время команда Allure TestOPS учтёт наши пожелания.

А что в итоге?

Повторим, что переход был задуман ради интеграции с автотестами, и с 8:57 можно посмотреть, что же в итоге получилось.

Идеальный сценарий, который мы себе представляли, выглядел так:

  • Простая интеграция с проектом любой из команд.
  • Выборочный запуск автотестов в рамках регресса.
  • Автоматическое обновление изменённых автотестов во время прогонов.
  • Удобное изменение и редактирование автотестов внутри проекта.
  • Совместное использование ручных и автоматизированных кейсов в одном тест-плане.

В целом, практически всё задуманное получилось — учитывая нюансы, о которых я говорил выше. На данный момент Allure TestOPS — не самая идеальная система для ручного тестирования, но над всеми сложностями и развитием работают её создатели.

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

11
Начать дискуссию