Home

Автор: Наталья Руколь, тренер курса «Аудит и оптимизация QA-процессов»

За пятнадцать лет работы в тестировании я наблюдаю, как отрасль из простой и незрелой, ориентированной на начинающих айтишников, становится профессиональным направлением. Раньше тест-менеджер должен был распределять задачи между тестировщиками и следить, чтобы они тестировали разные области, не повторяя одно и то же - такая вот “высокоинтеллектуальная управленческая задача”. Со временем в тестировании появилась узкая специализация, и теперь тестировщики решают разные задачи. Кто-то занимается тест-анализами и тест-дизайном, кто-то автоматизирует тесты, кто-то проводит ручное тестирование как по готовым скриптам, так и в свободном поиске, используя множество инструментов исследовательского тестирования. Соответственно, роль тест-менеджера также поменялась. Теперь он не просто распределяет задачи, а организует процесс, выделяет необходимые задачи для решения, объединяет людей с абсолютно разной квалификацией и целями, чтобы на выходе получить прекрасный результат. И тут, внимание, вопрос: а что же такое прекрасный результат в тестировании?

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

Никакие метрики не являются универсальными – напротив, это лишь инструмент, который помогает вам в решении определенных задач. Вы сначала определяете, что вам нужно, а уже потом ищете способы это померить, но не наоборот! Никто не покупает молоток, чтобы потом ходить и думать, какой бы гвоздь им забить. проверить сталкиваясь с задачей “повесить на стену картину” мы думаем, что нам для этого нужно, и только после этого идём в магазин за нужным гвоздём и подходящим молотком. Вот и с метриками в тестировании то же самое: сначала мы определяем цели, и только потом думаем, какие метрики могут нам помочь в их достижении (и могут ли).

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

1. Оценка прогресса. Если перед нами стоит какая-то задача, которую невозможно выполнить “здесь и сейчас”, нам нужен инструмент оценки, чтобы понять, ведут ли наши действия к ожидаемому результату?

Допустим, вам повезло, и выдумыванием целей заниматься не нужно. Руководитель проекта ставит задачу: “надо проводить тестирование сборки не более, чем за 3 дня, чтобы мы могли своевременно выдавать новые версии заказчику”. Вы считаете текущее положение дел - сборка тестируется 6 дней. Что делать? Оптимизация тестовых наборов, автотесты, расширение штата, аутсорс… Разобрав все возможные решения в команде, вы выбираете путь тотальной автоматизации, и усиленно работаете в этом направлении. Через полгода приходит раздосадованный РМ, машет руками и кричит “Что за фигня?!”. Вы смотрите, сколько в среднем уходило последние релизы на тестирование - 8 дней. Как так??

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

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

Начнём наш пример опять с готовой цели: высокие оценки пользователей в аппсторе. Сейчас у нас в среднем 3.7, а руководство требует 4.5. Простые измеримые показатели, считать просто, над дверью повесить - не проблема… Но зависит ли от нас напрямую этот показатель? И как мы будем его улучшать сегодня и завтра, если ближайший большой релиз только через полгода?

В таком случае мы ищем косвенные процессные метрики, которые будут вести нас к повышению оценок. Читаем отзывы и выясняем, за что снижены оценки. Находим три лидера по упоминаниям среди жалоб: падения на нестандартных окружениях, медленная скорость работы, нехватка запрошенных фич. Отлично, с этим уже значительно понятнее, как работать, чем с абстрактной оценкой нравится/не нравится! Мы можем выбрать метрики, которые помогут нам оценить свою работу (покрытие тестами на разных окружениях, проведение тестов производительности), так и общепроектные метрики: скорость работы и готовность запрошенных фич. Таким образом мы поможем и самим себе, чётко отслеживая рост требуемого тестового покрытия, и другим участникам команды, сразу показав, чего не хватает для релиза. До выпуска полгода, а поднять число тестовых окружений на 6% я уже могу сегодня!

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

Первый случай - когда в вашей компании кто-то недоволен тестированием, но не может высказать это вслух, или не может сформулировать, чего же он хочет-то. Есть какие-то недомолвки, неудовлетворенности, но понять, что именно не устраивает других участников команды, не представляется возможным. Возникает вопрос: что же именно у нас не так? В этом случае мы начинаем искать подходящие метрики, которые помогут нам сначала выявить проблему, а потом уже поработать над ней. “Что-то не так” постепенно вырисовывается в “пропуски критичных дефектов на прод более 20%” или “невозможность принимать нужные решения по релизу без оценки показателей качества”.

Второй сценарий - мой любимый и самый часто используемый. Например, на вашу команду поступают жалобы о том, что дефекты заводятся слишком поздно. В чем может быть причина? Вы можете попытаться субъективно разобраться в первоисточнике проблемы, а можете использовать метрики, выявляя причины несвоевременного обнаружения дефектов. Посоветовавшись с коллегами, выписываем все возможные причины поздних обнаружений: нехватка ресурсов, непродуманный и неполный тест-дизайн, ложные срабатывания автотестов или неэффективное распределение ресурсов тестирования. Определив список возможных первопричин, по каждому запоздало найденному багу вы проставляете причины задержек в этом конкретном случае. И вот, через месяц такой диагностической работы выясняется, что тесты на большинство пропущенных дефектов у вас есть, но выполняются они слишком поздно. Я несколько раз сталкивалась с такой ситуацией, выглядит она настолько нелогично, что заметить её без метрик почти невозможно, а исправить тщательной приоритизацией тестов можно очень быстро! Пара дней усиленной совместной работы тест-дизайнера и бизнес-аналитика и вуаля, критичные дефекты начинают обнаруживаться в самом начале тестирования!

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

Допустим, вы приходите к руководству со стандартным списком жалоб: ресурсов не хватает, времени слишком мало, требований нет, код отстой. Скажите ему это, и он будет отмахиваться от вас всеми доступными способами.

Хотите получить результат вместо отмашек? Придите с метриками. Покажите, что экономия ресурсов тестирования в 2000$ обходится проекту в 9000$ на штрафах по договору. Проиллюстрируйте, как экономия недели в начале релиза на написание требований ведёт к задержке релиза в три недели из-за разного понимания ожиданий. Такая беседа всегда будет конструктивнее и результативнее пустой болтовни, не подтверждённой измеримыми показателями!

Метрики: как выбрать и внедрить

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

1. Согласуйте ожидания руководства, зафиксируйте, а потом уже думайте: какими показателями можно оценить именно эту цель?
2. Вы хотите что-то улучшить в своей работе. Что именно? Определившись, какой результат вы хотите достигнуть, подумайте о его измерении:
   1. Как оценивать прогресс в достижении этого показателя?
   2. Как измерять достижения на уровне процесса, пока ключевой показатель, возможно, не меняется?
3. Вы хотите решить какую-то проблему, непосредственно в команде тестирования или на проекте в целом.
   1. Как оценивать эту проблему, в чём её можно измерить?
   2. Какие могут быть предпосылки для этой проблемы, очевидные или кажущиеся совсем нелогичными?
   3. Как можно обнаружить корень этой проблемы, или “узкое горлышко”?
4. Вам надо обосновать что-то своему руководству, и вы исчерпали аргументы:
   1. как проиллюстрировать наличие проблемы?
   2. как показать пользу от предлагаемого вами решения?

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

• срывы сроков (для обработки жалобы от РМа)
• причины срыва сроков (чтобы найти решения проблеме)
• низкое качество тестирования (для решения жалоб от техподдержки)
• низкое качество кода (чтобы конструктивно пожаловаться руководителю разработки)
• отчётность для РМа по качеству продукта (по которой он сможет принимать взвешенные решения)
• и т.д.

Только когда у вас появится список неуточнённых метрик, вы можете задуматься, как их измерять. Сначала - цели, потом - инструменты!

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

В рамках курса «Аудит и оптимизация QA-процессов» мы с Олегом Грабко помогаем ученикам выявлять те метрики, которые будут им максимально полезны в конкретных ситуациях. Из тех более трехсот метрик, которые мы когда-либо использовали, мы выбрали 94, наиболее наглядно иллюстрирующих возможности этих инструментов и приложили их в качестве дополнительного материала к уроку №3. Я очень надеюсь, что изложенной выше статьи достаточно для того, чтобы вы смогли внедрить нужные вам показатели с пользой и существенно улучшить с ними свой процесс тестирования.

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

Скорее всего в этих примерах вы найдёте такие показатели, которые помогут в решении стоящих перед вами задач. Но что делать, если необходимость в метрике вы выявили, но подходящего варианта для её расчёта не нашли? Пишите нам! Обещаем по каждому запросу на вариант внедрения метрики подготовить такой способ расчёта и визуализации, который получится внедрить в ваши условия. Таким образом, постепенно мы сделаем этот документ ещё более полным и полезным для всей отрасли.

Всем качественных продуктов, растущих показателей и зрелых процессов!

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