Home

Автор: Руслан Ахметзянов, Qameta Software

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

За Allure TestOps с самого начала тянется немало мифов. В некоторые из которых в начале пути мы верили и сами (например, в пятый!). В этой статье мы поделимся наиболее частыми заблуждениями и постараемся развеять их.

Миф 1. Allure TestOps — еще одна TMS

Пожалуй, чаще всего мы сталкиваемся именно с этим заблуждением. Обычно такая точка зрения озвучивается людьми, не изучавшими систему в деталях. Действительно, базовый набор функций типичной TMS есть в Allure TestOps: создание тест-кейсов, управление планами тестирования, назначение тестов на конкретных специалистов, прогон тестов и аналитика по результатам их выполнения. И все это отлично работает для ручных тестов, а для автоматизации есть набор API-интерфейсов, с которыми вы можете сами написать базовую интеграцию для используемой технологии.

Правда в том, что в случае Allure TestOps эта функциональность не является основной! Мы построили систему вокруг управления процессом тестирования по принципам DevOps:

1. Автоматизируйте все, что можно автоматизировать: тесты, тестовую документацию, запуски и перезапуски, разбор результатов, генерацию аналитики и отчетов. Тест-кейсы в автоматизации должны быть маленькими, а их обновление — автоматическим.
2. Общайтесь и обменивайтесь фидбеком: Как только происходят изменения в автотесте, они отображаются в системе и документации. И наоборот — как только вы изменили тест-кейс из UI — коллеги-автоматизаторы или разработчики получат автоматически сгенерированное ТЗ на обновление теста.
3. Будьте прозрачны: очень часто тестовые системы строятся таким образом, что польза от очередного прогона ясна только тем, кто его делал. В TestOps результаты каждого прогона со всеми деталями (вложения, стектрейсы, версии и переменные окружения) доступны всей команде и хранятся в понятной структуре с сохранением истории.

Эти принципы, реализованные на базе Allure TestOps, позволяют строить тестирование с заделом на будущее.

Миф 2. Чтобы пользоваться Allure TestOps, надо уходить с привычных инструментов

Такое мнение чаще всего становится выводом из первого мифа — если Allure TestOps является TMS, то нам придется переезжать с нашей привычной системы управления тестами. Однако все не совсем так.

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

За примером далеко ходить не надо: Allure отлично уживается рядом с TestRail у многих наших клиентов, выступая в качестве простого решения для управления всеми автоматизированными тестами — так получается проще, чем писать и поддерживать зоопарк интеграций с CI-системами и фреймворками для тестирования.

Для таких пользователей в планах развития у нас есть плотная интеграция с TestRail и другими популярными TMS.

Миф 3. Allure TestOps не подходит командам с ручным тестированием

Сравнивая Allure TestOps с TMS, многие ручные тестировщики отмечают множество неочевидных и "странных" решений: ярким примером здесь является логика хранения тест-кейсов в дереве (почему так, я писал отдельно). На самом деле, часто подобные замечания оказываются верны — поскольку Allure TestOps является automation first системой, решения для ручных тестировщиков реализованы непривычно.

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

Это не значит, впрочем, что такие решения не подходят командам с большим штатом ручных тестировщиков — Allure TestOps умеет делать с ручными тестами все, что должна уметь классическая TMS:

• Управление тест-планами, тест-кейсами и чек-листами
• История результатов тестов
• Автоматическое распределение тестов на QA-инженеров
• Аналитика и статистика (по юзеру, по команде или по чему угодно)
• Автоматические и ручные запуски тестов
• Двусторонняя интеграция с JIRA

Миф 4. Allure TestOps дорого обходится

Мир инструментов для QA-подразделений все еще зелен и юн — многие считают, что покупка инструментов — это дорого, а для всего остального есть Mastercard. :)

Стоимость Allure TestOps составляет $30 в месяц за пользователя. Много ли это? Давайте попробуем разобраться, почему нам такая оценка кажется разумной.

Первая проблема оценки заключается в том, что нас (в результате Мифа 1) сравнивают с TMS. И некоторые из них действительно на первый взгляд выглядят дешевле. Чтобы не быть голословным, приведу сравнительную таблицу с прайсами систем, с которыми нас чаще всего сравнивают:

Правда в том, что Allure TestOps сверху функциональности умеет еще кое-что. Кое-что важное, а именно — полноценное нативное управление автоматизированным тестированием. Так что к ценам выше придется прибавить стоимость разработки и поддержки самописных интеграций с тестовой инфраструктурой или вот такими инструментами вроде Katalon Runtime Engine / Studio.

Более того, за счет оптимизации процессов и тонкой настройки тестирования в долгосрочной перспективе Allure TestOps позволяет сильно сократить расходы на QA по двум направлениям: штат сотрудников (а это не только ЗП, но и офис, оборудование, расходы на найм и удержание и еще много чего) и расходы на тестовую инфраструктуру (оптимизированный под большие нагрузки Allure TestOps построен так, чтобы не перегревать инфраструктуру и каналы). Но про это можно написать отдельную статью.

Миф 5. Мы сами напишем свой TestOps за пару месяцев

Не самый распространенный миф, с которым мы периодически сталкиваемся на конференциях, в тематических чатах и других "общественных" местах. Оно и понятно, в чем проблема забутстрапить очередной CRUD-сервис, гоняющий результаты тестов в БД и отображающий красивую аналитику на базе любого JS-фреймворка?

Как говорится в известном анекдоте: есть нюанс. Allure TestOps построен на базе Allure Report, так что давайте начнем с него. Чтобы построить подобную систему, придется:

• Определиться с моделью данных. Начнем с самого базового — придется работать с метаданными тест-кейса, его содержимым, а также контекстом. Выбор модели данных является важным шагом, который повлияет на всю разработку в будущем.
• Разработать commons API для обеспечения интеграций необходимыми данными. Важно сделать его достаточно универсальным, чтобы вы могли заточить его по тестирование бэкенда, фронтенда, протоколов их взаимодействия и кто знает, чего еще. (в этот момент несколько очень головастых разработчиков потратили на проект несколько месяцев).
• Готовить интеграции с тестовыми фреймворками, находящимися в проде, когда API готовы и доступны. Кажется, что мы на финишной прямой, однако радоваться рано. Каждый фреймворк работает с данными по-своему, так что готовить интеграции посредством CMD+C → CMD+V не получится. Посмотрите на реализацию интеграций Allure Framework c JUnit и TestNG. И это все Java, интеграцию с тестами на другом языке придется переделывать со второго шага, надеясь на то, что не придется фиксить еще и модель данных (нам иногда приходилось).
• На каждую интеграцию, по нашему опыту, приходится порядка месяца работы разработчика, специализирующего на таком коде. А еще их надо поддерживать, и иногда обновлять API, не ломая обратную совместимость. Так что на поддержку 5-6 фреймворков закладывайте год-два.
• Погрузиться в задачи параллелизации и concurrent context sharing, поскольку выполнять автотесты в один поток просто не получится.

Хорошо, теперь мы умеем собирать данные! Следующее, с чем придется столкнуться — реализация протокола передачи результатов. По сути, у вас будет два глобальных пути: асинхронный обмен батчами и синхронизированные http-запросы. К слову, по второму пути идут практически все TMS, не даром у TestRail есть ограничение на 300 запросов в минуту (5 в секунду). Если для ручных тестов такой подход работает, то 10 000 автотестов надо будет ждать как минимум полчаса.

Значит, идем по асинхронной передачи тестовых данных. Вот только в батчах наши данные потеряют контекст (который хорошо передается в синхронном режиме) — надо подумать, как хранить его на стороне сервиса или передавать в батчах, синхронизировать с историческими данными и обрабатывать так, чтобы ничего не разваливалось. Для нашей команды эта задача оказалась одной из наиболее сложных.

В общем, пятый миф уже тянет на отдельную статью, так что просто скажу, что мы еще не дошли до проблем сериализации результатов, UI/UX, политиками доступа и безопасности. В заключение хочется сказать, что в Allure-сообществе есть крутые ребята, которые пилят "свой TestOps", и проекты получаются классные, рекомендуем посмотреть, какая нужна кодовая база, чтобы агрегировать несколько отчетов: Allure-Server и Allure-EE. А если мы вас не переубедили — заходите в ТГ-чат @allure_ru, поможем, подскажем!

Выводы

На этом список мифов подходит к концу, хотя его можно продолжать еще долго.

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

Пробуйте, смотрите и тестируйте: мы для этого предоставляем месячный trial-период Allure TestOps, в рамках которого саппорт будет помогать вам с настройкой и эксплуатацией системы, а также настройкой процессов под ваши требования.

Обсудить в форуме