Home

Всем привет! Меня зовут Егор Иванов, и я специалист по автоматизации тестирования. Довольно долгое время до этого я проработал в различных компаниях из сферы BI. Я обожаю визуализацию данных и считаю, что без нее невозможно строить рабочие процессы и уж тем более процессы в тестировании. Поэтому хочу, чтобы ее использовали как можно больше людей, так как визуализация данных очень важна, а в виде дашбордов она еще и прекрасна.

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

Многие из нас видят дашборд каждый день. Он пришел к нам из транспорта — это приборная панель автомобиля.

На картинке слева  — как раз такой дашборд. Это панель с различными приборами, которые показывают скорость, топливо, температуру охлаждающей жидкости. В современном автомобиле есть индикаторы, которые показывают, все ли хорошо с машиной, или же там загорается  лампочка «Check engine», и вам надо что-то проверить.

Другой пример (картинка справа) — это информационный дашборд в IT, который показывает, как ведут себя пользователи того или иного продукта. Он тоже представляет собой панель с различными индикаторами. Схожесть между двумя дашбордами не только в том, что это сущности с индикаторами, но и в том, что обе сущности очень важны. Вряд ли вы сядете за руль автомобиля без всех этих индикаторов, собранных на одной панели. А если сядете, то наверняка  случайно нарушите скоростной режим и не заметите, когда закончится бензин.

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

Определение дашборда

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

Еще важно разделять дашборды по типам. Я предлагаю учитывать только два:

• Операционный дашборд предназначен для быстрого предоставления пользователям критически важной информации. Помогает пользователям быть быстрыми, активными и эффективными.

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

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

Наш первый дашборд

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

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

Мы имеем в своем арсенале набор тестовых схем, которые копируют прод. На этих схемах — всегда свежие сервисы. И мы накатываем этот сервис на наши схемы, прогоняем на нем тесты. Если всё ОК, этот релиз идет дальше.

Как всё это выглядит с нашей стороны? В Jira прилетает тикет на проведение интеграционных тестов. Чтобы посмотреть тикет, есть канбан-панель, и флоу подразумевает четыре статуса: «открытый», «в работе», «в ожидании», «закрытый». «В работе» — это когда гоняются тесты. «В ожидании» — это если что-то пошло не так и требуется ручное вмешательство.

Еще у нас есть такой инструмент, как Autorun, который и проводит весь процессинг тикета. Подробнее про это можно прочитать в другой нашей статье тут.

После того, как Autorun берет в работу тикет в Jira, ему нужно выделить отдельный стенд для запуска. Это позволит не прогонять на одном стенде одновременно несколько тестов и заблокировать другой стенд, на котором уже проводятся работы. Для этого у нас есть инструмент под названием Locker.

Autorun обращается к этому инструменту, чтобы получить схему. У Locker тоже есть UI. То есть стенд может быть заблокирован или доступен, и с каким-то комментарием. Если есть комментарий, стенд блокируется.

После того, как Autorun сходит к Locker, он обращается к еще одному инструменту — Pinger, чтобы понять, насколько схема живая. С точки зрения UI-интерфейса, Pinger — это тоже мини-дашборд, на котором представлены все наши сервисы и их статусы: зеленые, если всё в порядке, или красные, если что-то не так. Autorun через API запрашивает у сервиса информацию. Если стенд не в порядке, он сообщает нам об этом и не запускает на нем тесты.

Если Autorun находит доступный для работы стенд, он запускает тесты в Jenkins, и обычно по результату задача улетает с вердиктом, что все хорошо.

Но иногда что-то может пойти не так. Для таких случаев у нас есть дежурный — кто-то один из нашей команды. Он должен разобраться, что именно не так. Раньше для этого ему приходилось идти по всем трем UI, а в случае с Locker и Pinger — еще и по пяти тестовым стендам, чтобы посмотреть, все ли хорошо на всех них. Это занимало время, а хотелось понимать причину сразу же.

Что мы для этого сделали? Конечно же, построили дашборд. Первым дашбордом была обычная HTML-страничка, которая скриптом ходила в API инструментов, запрашивала у них самую важную информацию и отображала ее.

Что представляла из себя самая важная информация? Из Jira мы брали только количество задач в каждом из статусов, из Pinger — только красные компоненты, из Locker — статусы схем и пояснение причины лока. То есть фактически мы ничего нового не изобрели, просто сделали общий UI и назвали его «дашборд дежурного», а пользу он принес большую. Скорость понимания того, что происходит, увеличилась в разы. Мы вывели этот дашборд на телевизор в кабинете, и теперь на вопрос, что сейчас происходит, может ответить даже человек, который случайно зашел в кабинет. И для этого ему не надо проводить никаких манипуляций с остальными инструментами.

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

Он значит, что со всеми стендами все отлично, новых задач нет — и можно идти на обед☺

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

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

На самом деле, для построения дашбордов есть множество решений, но некоторые из них входят в целые BI-платформы наподобие ClickView, а некоторые облачные решения, например Google Data Studio, нам не подходят. А Grafana у нас уже была и использовалась в команде мониторинга.

На всякий случай повторю, что такое Grafana.

Это инструмент для построения дашбордов на основе различных источников — от PostgreSQL до Google Sheets. В нашем случае источником был Graphite. Чем он нам был удобен? У нас не было готового хранилища знаний, где лежали бы все нужные данные. Мы сами пушим данные. Соответственно, Graphite — удобное хранилище для таких временных метрик.

Как происходит отсылка этих метрик? В формате StatsD мы отправляем их в Telegraf. Формат такой: название метрики, ее тип и значение. Telegraf за 30 секунд агрегирует метрики в зависимости от типа, который мы передали, и потом отсылает их в хранилище Graphite.

На самом деле, мы даже не особо переживаем и отправляем метрики по UDP, потому что на каждом нашем хосте есть инстанс Telegraf и до него 100% дойдет. Плюс у нас не настолько критичные технические метрики, которые мы отображаем в дашбордах, чтобы переживать, если они не дойдут.

Метрики StatsD бывают четырех типов, которые покрывают полную потребность:

• g (Gauge) — в течение 30 секунд Telegraf отправляет только значение последней метрики, которую получил;

• с (Count) — все полученные за интервал данные будут сложены, то есть Telegraf суммирует все, что к нему пришло;

•  s (Set) — отправляет уникальные значения, пришедшие за это время;

• ms (Timer) — отправляет множество разных метрик по таймеру (среднее время выполнения, count, max, min и т.д.).

Сами метрики отсылаются так же просто. Если у вас Java, Java StatsD Client — в нем создаем сам клиент и через него отправляем метрики. Всё. Отправку из Java мы используем как раз в наших инструментах, содержащих данные, которые надо отослать. То есть Autorun может отправить данные о количестве пришедших задач. Состояние схем может отправлять Pinger.

import com.timgroup.statsd.StatsDClient;
import com.timgroup.statsd.NonBlockingStatsDClient;
public class Foo {
private static final StatsDClient statsd = 
        new NonBlockingStatsDClient("my.prefix", "statsd-host", 8125);
    public static final void main(String[] args) {
    statsd.incrementCounter("bar");
    statsd.recordGaugeValue("baz", 100);
    statsd.recordExecutionTime("bag", 25);
    }
    }

https://github.com/tim-group/java-statsd-client

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

echo "my.prefix.bar:1|c" | nc -w 0 -u statsd-host 8125
echo "my.prefix.baz:25|g" | nc -w 0 -u statsd-host 8125

После отправки всех метрик построить дашборд просто. Мы добавляем новую панель в Grafana, выбираем подходящий визуализатор и создаем запрос, по которому хотим отобразить данные. Потом немного работаем с панелькой — выставляем правильные значения по осям, красиво рисуем, включаем/выключаем легенду и так далее. Повторяем это действие нужное количество раз и получаем дашборд. Дальше — о том, какие дашборды мы получаем.

Дашборд — визуализатор метрик

Самым первым у нас был дашборд по метрикам нашей команды. Так как основной процесс у нас  — это интеграционное тестирование, мы взяли метрики, относящиеся к этому процессу:

• количество релизов;

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

• поломанные релизы, в которых была найдена ошибка;

• пропущенные релизы, для которых была проверена только корректность развертывания сборки в тестовой среде (тестов нет).

Мы решили посмотреть, что будет, если построить такой дашборд и смотреть на него каждый день. Какие плюсы мы от этого получили?

Самое интересное — мы поняли, что у нас неправильно считаются метрики. Все они высчитывались по формулам и отправлялись руководству раз в спринт. При ежедневном просмотре мы заметили, что где-то стало выскакивать больше 100%, а где-то поняли: «Ага, были релизы без тестов, а у нас из-за этого почему-то процент просел, хотя этого не должно было произойти». Выяснилось, что у нас ошибка в формулах, и это удалось заметить благодаря тому, что мы просто стали смотреть за данными.

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

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

Дашборд — мотиватор

Помимо того, что все стали видеть проблемы, — все захотели, чтобы в их дежурство было 100% AutoPass. В наше дежурство было много релизов, и мы их хорошо выдержали. Так появилась мотивация устанавливать рекорды.

Мы проверили, насколько дашборд может быть реальным инструментом для мотивации. И нашли проблему, где нам не хватает мотивации — в проведении code review. Самописный бот назначает ревьюеров, коллег из моей команды, и мы проводим ревью тестов и наших инструментов для автоматизации. При этом ревьюер не один, иногда даже не два, а одного «approve» обычно достаточно. То есть если один человек поставил «approve», значит, все хорошо. Тут может получиться так, что кто-то вообще никогда не ревьюит и надеется, что это сделают другие. Чтобы это понять, мы построили дашборд и посмотрели, что изменилось.

Новый дашборд показывал активности ревьюеров: comments, approve, needs work. Такая визуализация меня сильно замотивировала. Я — «желтенький». По рисунку видно, что я более-менее часто ставлю approve, но, например, комментирую не так много. После этого я  старался ревьюить активнее.

Если раньше у нас б в pull request чаще всего стоял один «approve», то сейчас более чем в 90% случаях он стоит как минимум от двух человек. И это не случайные  «approve» — «раз один поставил, то и я тоже», — а осознанные.

Дашборд для анализа

Еще дашборд можно использовать  для анализа. Мы тестировщики и любим анализировать именно тесты.

Лично я больше всего люблю анализировать время выполнения тестов. Иногда кажется: «Ага, у нас тесты что-то очень долго выполняются…» Но как понять на самом деле, долго они выполняются или нет, если ты не знаешь, как они выполнялись вчера, позавчера или в течение года и как это соотносится с количеством тестов? На этот вопрос также сложно ответить без визуализации.

Вот простой пример дашборда, который показывает, что ваше восприятие может быть обманчиво.

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

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

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

Дашборд для экономии времени

Например, у нас есть такая активность — разбор того, насколько хорошо у нас прогнались утренние тесты на подготовку данных. Есть такой механизм — мы заранее подготавливаем тяжелые тестовые данные. То есть пользователи с выпущенными карточками. Это занимает время, и в тест это загружать тяжеловато. Поэтому пул таких пользователей мы готовим утром. Данные готовятся на наших пяти схемах (тестовых стендах, которые участвуют в приемках). Плюс это не один и не два тестовых запуска. И утром по результатам всех этих прогонов прилетает целая куча писем: «На такой-то схеме прошло так-то», «На такой-то схеме прошло так-то». Точнее, раньше прилетали все эти письма — и было тяжеловато.

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

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

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

Небольшое резюме

При внедрении дашборда мы получаем: 

• инструмент для объективной оценки происходящего,

• экономию времени при анализе,

• дополнительную мотивацию,

• новую информацию, которая раньше была незаметна,

• множество данных для анализа в будущем.

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

В заключение добавлю прекрасную цитату Джона Тьюки, американского математика, статистика, одного из основателей визуализации данных и статистического анализа:

«Изображение приобретает особую значимость, если оно позволяет углядеть в нем то, что мы не предполагали увидеть».

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