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

Как доказать, что ваши автотесты полезны и какую именно ценность они поставляют?

И что собой представляет эта ценность? Автотесты, которые всегда проходят или не проходят?

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

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

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

Тестовое покрытие — плохая метрика ценности

Достаточное тестовое покрытие не гарантирует, что имеющиеся тесты полезны.

Если мы сойдемся на том, что ценными можно назвать те тесты, которые находят дефекты, то отслеживание тестового покрытия не говорит нам ничего о ценности. Тестовое покрытие не говорит нам, выявляет ли тест дефекты. Если у меня проект со 100% тестовым покрытием, значит ли это, что у меня ценный тестовый пакет? Мы не можем ответить на этот вопрос. Нужно копать глубже.

Выход за пределы тестового покрытия

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

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

Метрика №1: ошибочно-негативный показатель

Если не получается починить тест, его необходимо убрать.

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

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

Я сталкивался с некоторыми возражениями против их удаления:

1. Автотест тестирует важную фичу.

Этот ненадежный тест важен — нам нужно протестировать фичу X.

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

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

2. Снизится тестовое покрытие.

Опять же, тестовое покрытие ничего не говорит нам о ценности. Тестовое покрытие не так важно, как полезные рабочие тесты.

Метрика №2: ошибочно-положительный показатель

Лучше иметь тест-сьют, который в процессе выполнения падает, чем дает всегда 100% pass.

Хуже ненадежного теста — тест, который всегда на 100% проходит, и таким образом, потенциально пропускает дефекты. Каждый раз, когда вы имеете дело с дефектом, задавайтесь вопросом — должны ли автоматические тесты его обнаружить? Если ответ положительный и тест существует, запишите его. Начните отслеживать, сколько раз тест пропускает дефект. 

Если у вас есть тесты, которые постоянно пропускают дефекты, то это проблема. Повторюсь, такие тесты стоит переписать или вовсе убрать. Иначе они дают команде ложную уверенность.

Метрика №3: время выполнения

Медленный прогон тест-сьюта замедляет работу команды и снижает ценность.

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

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

Метрика №4: увеличение количества подтвержденных дефектов

Тесты, которые обнаруживают дефекты, создают ценность. 

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

Метрика №5: скопление дефектов

Дефекты часто скапливаются в одном месте. Отслеживание таких областей поможет вам планировать тесты.

Каждый тестировщик сталкивался с эффектом скопления дефектов, даже если он этого и не замечал. Было ли у вас такое, что вы работали над чем-то и нутром чувствовали, что эта фича постоянно ломается? Это и есть скопление дефектов в действии. Там, где вы обнаруживаете дефект, вы часто можете найти и другие, и подобное скопление можно назвать кластером.

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

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

Написания тестов и отслеживания тестового покрытия не достаточно

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

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

Совсем скоро состоится открытый урок курса «Автоматизируй это! Автоматизация API + удобные отчеты», на кототорый приглашаем всех заинтересованных. На занятии собираемся познакомиться с тем, как очень быстро запустить автоматизацию API на проекте и запустить CI/CD для наших автотестов с отчетом в telegram.