Кирилл Раткин, тестировщик Контур.Экстерна, расскажет как повысить эффективность тестирования с их помощью и не уйти в крайности.

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

Как вы можете охарактеризовать свои рабочие процессы и практики? Они хорошие? Плохие? Насколько? Почему вы так решили?

Не удержусь и процитирую слова лорда Кельвина:

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

Никакой процесс не может считаться зрелым пока не станет прозрачным и управляемым.

Я видел две крайности:

1. Люди считают, что у них все хорошо/плохо и без радаров. «Ну это же и так понятно»(с).
2. Каждый шаг обвешан цифрами, но большая их часть лежит мертвым грузом и никак не используется.
   

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

Метрики нужны для:

• Повышения объективности. Например, ничто не сможет охарактеризовать стабильность ваших автотестов точнее сухих цифр процента прохождения.
• Визуализации.
• Оценки динамики изменений. Если вы не можете сделать все, что запланировали, то выбирайте из списка более эффективные задачи. Чтобы принять взвешенное решение, нужно понимать какие практики обладают более высоким КПД.

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

Метрики автотестов

Собираясь вводить метрики в автотесты, вы должны понимать, для чего это вам.

Специфика наших автотестов:

• Наличие гуевых пользовательских сценариев.
• Интеграционные проверки с тестовыми стендами сторонних сервисов.
• Кроссбраузерность.
• Конфигурирование CI и тестовых виртуалок.
• Предоставление наших продуктовых АТ другим сервисным командам.

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

Метрики дежурного по автотестам

Мы начали обращать внимание не только на стабильность теста и время прогона, но и на:

• время красного прогона
  Показывает как долго тест падает. Прогоны, которые долго падают, держат очередь на виртуалках. Иногда WebDriver кидает исключения, и такие тесты могли висеть часами. Такие ситуации решаются уровнем выше и для всех тестов, а вот от некорректных таймаутов и ожидалок можно избавиться лишь потрогав конкретный тест. Мы в обязательном порядке разбираемся с прогонами, у которых эта метрика более 20 минут.
• эффективность теста по времени
  Сколько агент тратит на реальный прогон, а не на нестабильность. Эта метрика про шумящие тесты. Мы хотели понимать сколько времени уходит на зеленые и красные прогоны, и посчитать соотношение. Тесты с низкой эффективностью стоят первыми в очереди на рефакторинг.
• относительное потерянное время
  Эта метрика показывает сколько минут теряется на каждый прогон этого теста из-за нестабильности. В нашей команде она считается второй по важности после стабильности.

Плюс, учли ряд специфичных для нас особенностей:

• Уникальным ключом для нас служило не имя теста, а пара тест — браузер.
  Один и тот же UI-тест ведет себя по-разному в быстрых и медленных браузерах, разных JS-интерпретаторах и т.д. Поэтому тестировщик правит не Test1, а Test1 в Browser1.
• Некоторые агенты с вроде бы идентичным окружением (ОС, браузер и т.д.) отличались друг от друга по стабильности прохождения тестов.
  Есть сложности с генерацией абсолютно идентичных окружений. Плюс виртуалки не закрыты от разработчиков или тестеров, которые хотят «что-то подебажить». Поэтому пока не решены эти проблемы, приходится делать выборки по прогону тестов в разрезе каждого агента. Если какой-то тест проходит на конкретном агенте заметно хуже, то это триггерит дежурного на более тесное общение с данной виртуалкой.

Поиск испорченных виртуальных машин

Большинство команд могут собирать метрики с помощью CI. Нам этого не хватило — слишком хитро мы настроили свои категории и запускалки. Пришлось написать небольшую оберточку, которая в TearDown’е отправляла в БД мету билда со всеми показателями.

Наши цели:

1. Оценка ситуации
2. Информация для адресного реагирования

Метрики позволили понять по каким показателям мы проседаем. Дальше расставляем веса, ориентиры и вырабатываем порядок достижения цели.

Раз в две недели на летучке с дежурным мы:

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

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

Оценка покрытия автотестами

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

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

Кто-то считает покрытие кода. Но здесь не учитывается с какими параметрами мы вызываем тот или иной метод. Действительно, зайдя в метод, который делит А на В с какими-нибудь «безопасными» аргументами, мы не можем сказать, что метод покрыт и протестирован. А если деление на ноль? А если переполнение? Также не учитывается критичность непокрытого кода, а поэтому неясна мотивация это покрытие увеличивать.

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

Дальше принцип простой:

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

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

Метрики релизного цикла

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

Мы стали считать сколько времени задача находится на каждой стадии релизного цикла.

Сбор метрик релизного цикла на базе YouTrack

Из всего этого мы сумели:

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

Сейчас у нас соотношение пишущих разработчиков к выпускающим их тестировщикам в районе 3 (± 0.1), комфортным считается 2.5. С учетом проводимой автоматизации релизного цикла мы хотим выйти на соотношение 3.5 и 3.

Наша реализация сбора метрик основывалась на редакторе правил внутрикомандного багтрекера. Это YouTrack Workflow. В своей команде вы можете использовать аналогичные возможности ваших трекеров, либо писать велосипеды с веб-хуками.

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

Метрики ради метрик

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

Допустим, никогда не понимал такую метрику как количество тестов. Нафига? Что вам скажет показатель, что в какой-то команде 12345 тестов? Они хорошо тестируют? Не факт. Их автотестам можно доверять? Вряд ли ребята даже знают что они проверяют. Это показывает эффективность работы автотестера? Возможно, там минусов от поддержки больше, чем какого-либо профита — о какой эффективности речь? На самом деле, под этой метрикой подразумевают покрытие и доверие к вашей тестовой системе. Но, блин, это не одно и то же. Если хотите поговорить о покрытии, то им и оперируйте.

Всегда помните, что сбор метрик требует от вас определенных усилий и времени. Цените его и подходите к этой практике с умом!

Нам очень интересно, а какие метрики используете вы, а от каких, наоборот, отказались. Пишите в комментариях!

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