Как Воплотить Документацию В Жизнь?

Наверное, каждая команда знакома с этой болью — неактуальной документацией.

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

Наша группа тестирования совместно с системными аналитиками решили попробовать оживить нашу конструкторскую документацию.



Как воплотить документацию в жизнь?

В веб-проектах Альфа-Банка используется фреймворк автоматизации тестирования.

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

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

На самом деле мы уже использовали плагин генерации документации с Akita, который проходил шаги в скриптах и загружал их в формат html, но для того, чтобы сделать этот документ актуальным, нам нужно было добавить:

  • скриншоты;
  • значения переменных (файл конфигурации, учетные записи пользователей и т. д.);
  • статусы и параметры запроса.

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

feature. Мы решили добавить динамики, и чтобы не нагромождать плагины поверх плагинов, решили написать свои.

Для начала мы решили выяснить, как можно собирать скриншоты и значения переменных, используемых в тестовых сценариях, из фич-файлов.

Все оказалось довольно просто.

При запуске тестов Cucumber создает отдельный файл огурца.

json для каждого файла функции.

Этот файл содержит следующие объекты:

Как воплотить документацию в жизнь?

Название и ключевое слово набора тестов:

Как воплотить документацию в жизнь?

Массивы элементов — сами скрипты и шаги:

Как воплотить документацию в жизнь?

Поле вывода содержит дополнительную информацию, например, переменные — адреса, ссылки, учетные записи пользователей и т. д.:

Как воплотить документацию в жизнь?

Embeddings содержит скриншоты, которые селен делает при прохождении тестов:

Как воплотить документацию в жизнь?

Таким образом, нам просто нужно пройтись по файлам огурца.

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

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

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

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

В результате мы получили файл в формате Asciidoc — удобный формат файла, немного сложнее аналога Markdown, но имеет гораздо больше возможностей форматирования (можно вставить изображение или таблицу, чего нельзя сделать в Markdown).

Чтобы преобразовать полученный Asciidoc в другие форматы, мы используем Ascii Doctorj, официальную версию Java-инструмента AsciiDoctor. В результате мы получаем готовую документацию в формате html, которую можно загрузить в confluence, отправить коллеге или положить в репозиторий.



Как воплотить документацию в жизнь?



Как подключиться?

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

adoc

.



Что мы хотим улучшить?

  1. Добавьте настраиваемые технические шаги.

    Текущая версия плагина содержит шаги «И был сделан скриншот…».

    Подобные шаги не имеют смысла для документации, и мы хотим их скрыть.

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

    Чтобы уйти от этого, мы планируем такие шаги перенести в файл конфигурации и прописать там те шаги, которые мы не хотим видеть в скриптах.

  2. Сделайте плагин с открытым исходным кодом.



Какие команды выиграют от нашего внедрения?

  • используйте Cucumber (или аналогичный фреймворк);
  • хотите иметь актуальную документацию по фронту и базу знаний;
  • хочу привлечь аналитиков к тестированию.



Результат:

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

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

Кстати, по поводу холивара, нужен БДД или нет, в понедельник проведем специальная встреча .

Теги: #Разработка сайта #тестирование #Тестирование веб-сервисов #Тестирование ИТ-систем #Подготовка технической документации #документация #бдд #gradle #Альфа-банк #акита #огурец

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.