Как избавиться от нестабильных тестов за 5 шагов

🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 15.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks 

Если вы работаете над сложным программным обеспечением и при этом покрытие автотестами достаточно полное, чтобы выявить баги, то, скорее всего, вы уже столкнулись с проблемой нестабильных (flaky) тестов.

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

Как можно выйти на более качественный уровень?

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

Читайте также: Обеспечение качества и надежности тестирования

Но понимание, как улучшить свои тесты, — это только часть решения:

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

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

Шаг 1: Грамотно выбирайте метрики, чтобы объективно оценить масштаб проблемы

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

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

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

Шаг 2: Разделите продукт на модули и назначьте ответственных

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

Как показывает практика, оптимально, когда ответственных на один модуль — двое: этого достаточно для надежности (bus factor), но при этом сохраняется ответственность.

Каждый раз, когда тест падает, сразу понятно, кто за него в ответе.

Шаг 3: Используйте бюрократию как инструмент давления на изменения

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

• Если pass rate выше 50% — встречу отменяется.
• Если он между 30% и 50% — встреча отменяется только в том случае, если метрика улучшается.
• Если pass rate ниже 30% — встреча проходит каждый день.
  

Шаг 4: Сосредоточьтесь на устранении нестабильности, а не на улучшении качества продукта

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

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

Можно выделить три уровня приоритета:

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

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

Шаг 5: Сохраняйте полезные артефакты при падениях тестов

Когда тест падает, по его результатам часто невозможно определить, что именно пошло не так. Но двигаться дальше как-то нужно.

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

Заключение

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

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

Перевод статьи «5 steps to a deterministic test suite».