Home

Оригинал статьи: http://www.ontestautomation.com/not-so-useful-metrics-in-test-automation/

Автор: Баз Дийкстра (Bas Dijkstra)

Перевод: Ольга Алифанова

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

Итак, что, с моей точки зрения, может быть полезной метрикой для отслеживания эффективности и/или результатов усилий по автоматизации?

Снижение длительности петли обратной связи

Первая метрика, которую я бы предположил, не связана с качеством приложения – скорее она относится к качеству процесса разработки. Сама суть тест-автоматизации (по крайней мере, в идеале) – это повышение эффективности усилий тестирования. Один из способов отследить это – замерять время, которое проходит между моментом, когда разработчик коммитит изменение, и моментом, когда ему сообщают о том, как эти изменения повлияли на качество приложения. Это время, также известное как время петли обратной связи, в идеале должно быть как можно короче. Если разработчик узнает об ужасных последствиях своего коммита спустя две недели – он давно уже переключился на другие задачи. Или проекты. Или вообще сменил работу. Если же обратная связь приходит в течение нескольких минут (или секунд), поправить дело куда проще. Один из способов сократить длительность петли обратной связи – эффективно использовать автоматизацию, поэтому подходите к ней с умом и отслеживайте, как она влияет на петлю обратной связи.

Процент завершения пользовательских сценариев

Возможно, кого-то это удивит, но автотесты, тестирование, разработка ПО в целом – это все еще деятельность, посвященная высшему благу: счастью пользователя. В этом ключе имеет смысл разработать метрику, которая напрямую относится к способности пользователя использовать ваше приложение. Примером такой метрики может служить количество предопределенных критических пользовательских сценариев, которые (все еще) могут быть завершены при помощи автотеста после того, как в код были внесены правки. Под "критическими" я имею в виду сценарии, которые напрямую относятся к генерированию дохода, привлечению потребителей и другим маркетинговым штукам. Чем проще и чаще вы можете убедиться (при помощи автоматизации), что эти сценарии работают, тем больше веры у вас будет в ваше новое прекрасное приложение, которое вот-вот увидит свет.

Ложноположительные и ложноотрицательные срабатывания

Автотесты ценны, только если вы можете полностью доверять той обратной связи, которую они вам дают. Если автотест падает, то это должно происходить из-за дефекта (или незамеченных изменений) в приложении, а не потому, что ваш автотест плох (зачем вам ложноотрицательные срабатывания?). С другой стороны, если автотест прошел, вы должны быть полностью уверены, что компонент или приложение, которое тестировалось, действительно работает так, как должно (ложноположительные срабатывания нужны вам еще меньше). Ложноотрицательные срабатывания раздражают, но как минимум не проходят незамеченными. Исправляем их причину и идем дальше. Если она не может быть исправлена, удаляем сам тест – если ему нельзя верить, в нем нет смысла. Ложноположительные срабатывания – куда большая проблема, потому что их не так-то просто заметить. Если в мире автоматизации все вокруг зеленое, очень легко (и по-человечески понятно) доверять результатам, даже если все, что вы проверяли – это то, что единица равна единице (см. ниже). Один из подходов по определению ложноположительных срабатываний, по крайней мере в области юнит-тестирования – это использование мутационного тестирования. Если это невозможно, регулярно проверяйте ваши автотесты, чтобы убедиться, что они все еще послушно ищут баги.

Помимо полезных метрик, есть и такие, ценность которых сомнительна (или вовсе отсутствует).

Покрытие кода

Метрика, которая часто используется для выражения покрытия сьюта юнит-тестов. Основная проблема с этой метрикой в том, что, теоретически, она очень логична (каждая строчка кода запускалась как минимум один раз, когда мы прогоняли наши тесты), но на практике она ровным счетом ничего не говорит о качестве и эффективности тестов, а также качестве самого приложения. К примеру, очень даже возможно написать юнит-тесты, которые затронут абсолютно все строки кода и убедятся, что единица равна единице. Или что яблоки равны яблокам. Эти тесты пройдут без сучка, без задоринки. Они будут проходить каждый божий раз (ну или до тех пор, пока единица не перестанет равняться единице, но я думаю, что в обозримом будущем все будет хорошо). Инструменты покрытия кода покажут блестящий 100% результат. Который будет означать ровным счетом ничего в смысле качества приложения.

Процент тест-кейсов, которые уже автоматизированы

Экспонента феномена "автоматизируйте все на свете!". В теории, выглядит круто: "Мы автоматизировали 83,56% наших тестов!" Во-первых (особенно в плане исследовательского тестирования – это не моя сильная сторона, могу ошибаться), нет такого понятия, как фиксированное количество тест-кейсов. Следовательно, выражать количество автотестов как процент от переменной, которая вовсе не существует – это бессмысленно. Или вы просто врете сами себе (выберите сами, что именно). Есть только одна метрика, которая заслуживает внимания в этом ключе, цитируя Алана Пейджа:

Вы должны автоматизировать 100% тестов, которые должны быть автоматизированы.

Снижение количества тестировщиков

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

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

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