О правильном применении метрик в автоматизированном тестировании

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

Особенно важна и ценна автоматизация тестирования в проектах, где высока цена ошибки. Например, в проектах банковской сферы. Почему?

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

При правильном применении автоматизации тестирования вы можете получить следующие преимущества:

• освобождается время специалистов при проведении регрессионного тестирования. Это время можно потратить на другие полезные активности в проекте;

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

Все это на длительной дистанции снижает стоимость проведения тестирования в целом.

Как понять, какая польза от автоматизации тестирования? На помощь приходят метрики, с которыми надо быть осторожным. Есть две крайности:

• метрики вообще не используются: «Ну это же и так понятно»;

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

И, как обычно это бывает, вдаваться в крайности - плохо. Метрики не лекарство от плохих процессов, это индикатор проблем.

Для чего же нужны метрики?

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

• для визуализации. Метрики помогают наглядно показать ситуацию на проекте;

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

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

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

• Наличие GUI пользовательских сценариев;
• кроссбраузерность;
• конфигурирование CI и тестовых виртуалок.

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

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

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

• время прогона, когда автотесты падали. В случае, когда тесты падают долго, они могут создать очередь, которая в свою очередь не несет полезной нагрузки и вызывает простой стенда и CI;

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

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

Как оценить покрытие автотестами?

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

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

По итогу мы добились следующего:

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

• увеличили скорость прохождения автотестов;

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

• сняли головную боль от вопросов «А вдруг автотесты не нужны?» и тому подобных.

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

Итог

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