Home

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

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

А ведь десять лет назад релизы происходили раз в месяц, если не реже. Ускорение релизного цикла в сотни раз стало возможным благодаря десяткам новых инструментов и подходов в разработке и эксплуатации. Ломающий барьеры DevOps с облаками, CI/CD системами, контейнерами и мониторингами и рассчитанный на максимальный фокус и скорость Agile применяют (с переменным успехом) порядка 80% IT-компаний.

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

На самом деле, для того, чтобы автоматизированное тестирование работало, придется решить задачи и другого уровня:

1. Как запускать тесты часто, быстро и эффективно? Как сделать тестирование понятным и полезным всей команде. Как сделать так, чтобы тестам верили и реально пользовались результатами прогонов, а не складывали их “в стол” Об этом мы уже писали ранее.
2. Как автоматизировать тесты так, чтобы ручные тестировщики и менеджеры доверяли тестам? Чаще всего автоматизация строится на базе ручного тестирования привыкшего работать в своей TMS (Test Management System). Как подружить имеющиеся инструменты с автоматизацией? Сколько сил и времени потребуется на интеграцию или миграцию?
3. Что делать, если какие процессы начинают буксовать: тесты пишут, но не прогоняют; релиз-менеджеры катят код в продакшн, несмотря на “красные” тесты; метрики тестирования смотрят только тестировщики. Решение таких проблем требует опыта и экспертизы, а игнорирование их часто приводит к тому, что автоматизация клеймится “неэффективной” и становится вещью в себе.

Именно поэтому в Qameta Software разработали Allure TestOps так, чтобы сделать автоматизацию тестирования простой, прозрачной и интегрировать ее на всем жизненном цикле разработки.

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

Для решения этой задачи, Allure TestOps фокусируется на трех подходах, каждый из которых обеспечивается набором инструментов:

• Автоматизация тестирования из коробки.
• Совместимость с TMS.
• Сообщество и экспертиза.

Давайте посмотрим на каждый из пунктов подробнее.

Автоматизация тестирования из коробки

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

Первое, что необходимо сделать после внедрения автоматизации — обеспечить доверие к тестам.

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

Allure TestOps предоставляет набор инструментов для построения понятной и прозрачной автоматизации с нуля: от написания теста до аналитики по результатам десятков прогонов.

Правильно писать тесты

Скорее всего, первым делом будут автоматизироваться ручные регрессионные тесты и валидация. Для этого, сценарии ручных тестов практически полностью переносятся в код, после чего запускаются на CI. В Allure TestOps для этого сеть десятки готовых нативных интеграций с фреймоврками на одиннадцати языках программирования.

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

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

Правильно запускать и исполнять

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

Связано это с несколькими причинами:

• Большинство современного ПО написано на микросервисах. Это значит, что гонять все тесты нужно намного реже, чем делать выборки по фичам или конкретным бранчам в репозитории. На “голой” CI-системе делать такие выборки сложно.
• Сами системы создавались для разработчиков и для многих тестировщиков работать в них непривычно.
• Часто тесты мало просто прогнать: часто упавшие, нестабильные “флакающие” тесты необходимо перезапускать с сохранением настроек и истории. Обычные CI-системы так не умеют, а разработка, настройка и поддержка скриптов может потребовать немало времени и сил.

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

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

Правильно разбирать результаты

Люди — умные, автотесты — глупые. Если в коде или в продукте что-то поменялось, они не думают — они падают. Это создает информационный шум.

По статистике, из 100 автотестов стабильно падать будут штук пять. На разбор каждого падения уходит, допустим, пять минут. Получается, что на разбор всех упавших тестов тестировщику понадобится двадцать пять минут. В целом, это немного.

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

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

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

Правильно анализировать

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

Чтобы тестирование было полезно всем, нужно уметь строить отчеты. Более того, одного отчета скорее всего будет недостаточно! Давайте посмотрим, какие отчеты могут быть полезны:

1. Экспорт отчетов прогона автотестов для коллег-тестировщиков. Можно сколько угодно говорить о том, что ручное и автоматизированное тестирование — это два разных мира, но по факту, все тестировщики работают на единый результат. Постарайтесь сделать отчеты максимально подробно, чтобы коллегам было удобно и понятно.
2. Экспорт результатов (багов и дефектов) в трекер для коллег-разработчиков. Следует стремиться к состоянию, когда разработчики видят ваши тесты, принимают их результаты и понимают, о чем говорят полученные отчеты.
3. Иногда коллегам или руководителям нужны какие-то специфичные данные о ходе тестирования или разработки: покрытие фичи, время прогона суита, количество падений за определнный период, — для того, чтобы отвечать на эти вопросы, нужен инструмент, способный быстро собирать кастомные отчеты из имеющихся данных.

Для этого Allure TestOps хранит и размечает все тесты так, чтобы потом нарезать данные в любом нужном формате. Аналитика для автотестов учитывает много аспектов: стабильность, скорость выполнения, скорость разработки и то, какие проблемы для ваших автотестов встречаются наиболее часто. Любая из этих метрик легко визуализируется и превращается в дашборд.

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

Совместимость с TMS

В крупных компаниях автоматизация внедряется поверх зрелых QA-отделов, где команда уже пользуется инструментами для управления и работы с тестами. Чаще всего такие отделы построены вокруг TMS. TMS — отличное решение для управления ручным тестированием, но встраивание любого «ручного» инструмента в DevOps-пайплайны затрудняется требованиями к скорости и масштабированию.

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

Интеграция с Xray Test Management и TestRail. Эти системы являются стандартом де-факто в области ручного тестирования, широкая функциональность позволяет построить процессы в QA-подразделении управляемыми и понятными. Однако внедрение автоматизированного тестирования с этими инструментами требует дополнительной разработки: необходимо интегрировать CI-системы и все фреймворки с предоставленным API для автотестов.

Allure TestOps построен так, чтобы команда работала в едином пайплайне. Для этого и были разработаны интеграции с классическими TMS, с которыми ручное тестирование окажется не только на одной волне с автоматизаторами, но и получит прямой контакт с командами разработки и эксплуатации.

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

Сообщество и экспертиза

Qameta Software возникла вокруг Allure Report, open-source проекта, которым пользуются сотни тысяч пользователей по всему миру. За 10 лет существования проект собрал огромное сообщество, позволившее Qameta Software сфокусироваться на реализации идей и решений от множества пользователей и контрибьюторов.

Такой эволюционный путь развития привел команду разработчиков к Allure TestOps — универсального инструмента, позволяющего и инновационным стартапам, и крупным бизнесам (банкам, телеком-компаниям, IT-корпорациям) внедрять эффективные процессы автоматизациии находить точки роста в процессах на стыке QA, Ops и разработки.

Кроме того, Qameta Softwareактивно делится опытом в открытых источниках:

• В корпоративном блоге мы делимся практиками тестирования и паттернами проектирования для автоматизаторов.
• Выступаем на международных конференциях и митапах по всему миру.
• Поддерживаем онлайн-школы (OTUS и QA.guru) и образовательные проекты.

Пишите тесты. Allure TestOps позаботится об остальном.

В итоге, главная задача Allure TestOps — позволить команде сосредоточиться на качестве продукта и разработке автотестов, обеспечивая все процессные и инфраструктурные сложности из коробки.

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