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