какие метрики учитываются при принятии решения о приостановке тестирования
Основные показатели процесса QA
В рамках Quality Assurance могут и должны быть использованы различные метрики и показатели качества продукта и процесса разработки. Метрики можно разделить на группы по параметрам, на основании которых они рассчитываются, по этапам жизненного цикла разработки, на которых они применяются, по целям и задачам, по стейкхолдерам, для которых они предназначены. Этот список можно продолжать и дальше.
В этой статье я решил собрать вместе и рассмотреть самые основные, на мой взгляд, группы критериев и измерителей для QA процесса. А в каждой группе я перечислю только самые важные и показательные, опять же на мой взгляд, метрики а также разберу, для чего они необходимы, в каких ситуациях полезны и как их использовать.
Какими должны быть метрики?
Сама по себе метрика в контексте ПО — это численное выражение какого-либо свойства, качества самого продукта или процесса его разработки. Иными словами, это то, с помощью чего мы можем измерить, сравнить и оценить ПО.
Теперь буквально пара комментариев по поводу значений и свойств метрик:
Основные группы метрик для QA
Теоретически возможно придумать свою характеристику, формулу или показатель практически для каждого, даже самого незначительного действия, этапа или статуса процесса QA. Можно учитывать каждый артефакт, все переходы дефектов по статусам, вычислять количество тестов в наборе. Однако, самый важный вопрос, который сразу следует задать себе, когда возникает желание что-то измерить: «Зачем нужна эта информация, как ее можно использовать?». При формирования набора метрик, следует отталкиваться от целей, планов по улучшению процессов и продукта.
Итак, в этой статье мы не будем рассматривать обычные количественные показатели прогресса тестирования, которые используются в большинстве отчетов и статусов. Вместо этого разберем, какие сферы, артефакты и области разработки с точки зрения Quality Assurance мы должны измерять и контролировать для оценки качества выполнения работы. Анализ и оптимизация этих точек крайне важнны для эффективного взаимодействия со стейкхолдерами (https://doitsmartly.ru/all-articles/sw-testing/120-stakeholders-for-qa.html) и разработки ПО в целом:
1. Требования к разрабатываемому ПО.
Совершенно точно мы должны понимать, что разрабатываем и тестируем, и степень этого понимания необходимо уметь оценить. Потенциальные риски или пропущенные проблемы на уровне спецификации могут привести к самым серьезным и дорогим ошибкам.
2. Качество разрабатываемого продукта.
Тут все очевидно: необходимо иметь возможность оценивать качество разработки и ПО, чтобы делать прогнозы и оценку рисков. Важно понимать, насколько продукт является качественным и надежным, опираясь не только на наличие или отсутствие найденных ошибок, но как раз прогнозируя, много ли потенциальных проблем.
3. Возможности команды QA.
Здесь тоже просто: для того, чтобы управлять процессом тестирования, планировать работы и прогнозировать сроки, требуется всегда иметь не только актуальный статус задач, но и знать возможности команды QA.
4. Качество работы команды тестирования.
Помимо качества самого продукта нужно измерять эффективность самого процесса QA и команды тестирования. Чтобы постоянно оптимизировать и улучшать качество работы, требуется знать, где мы находимся сейчас, что позволяет двигаться вперед, а что отбрасывает назад.
5. Обратная связь и удовлетворенность продуктом.
Последняя область, но, конечно же, не по значимости, а по отзывам стэйкхолдеров процесса, потребителей наших услуг, пользователей продукта. Очень важно иметь возможность измерять общую степень удовлетворенности продуктом, выделять тенденции и делать соответствующие выводы. Правильно подобранные для этой группы метрики позволят вовремя выявить возможные проблемы и оперативно применить обратную связь для улучшения процессов.
Далее рассмотрим, какие именно метрики входят в каждую группу, разберем, как именно их можно оценить. Для каждой группы я приведу несколько примеров возможных метрик и опишу их значение. Более подробно эти и некоторые другие индикаторы QA процесса разобраны в моей статье «Самые важные метрики QA» (https://doitsmartly.ru/all-articles/sw-testing/133-the-most-important-metrics-in-qa.html).
Группа 1 — Требования к разрабатываемому ПО
Эта группа метрик позволит оценить, насколько мы проработали требования (user story) к ПО, определить уязвимые места и наиболее сложные, потенциально проблемные фичи ПО, понять, где требуется особый контроль.
1. Тестовое покрытие требования
«Общее количество тестов» / «Общее количество требований»
Назначение метрики: выявить слабые места в тестовом покрытии, подсветить риски.
Метрика вычисляется как количество связей каждого требования с остальными требованиями. При этом используется среднее по всем требованиям значение.
Назначение метрики: дать основание для оценки сроков тестирования и учета возможных рисков. Зная степень взаимного влияния требований друг на друга, можно, например, запланировать дополнительное время и кейсы для сквозного тестирования, проработать регрессионные проверки, посмотреть в сторону интеграции и т.п.
Назначение метрики: показать, как много уже реализованных требований приходится переделывать от релиза к релизу при разработке новых фич. Также метрика дает представление о том, насколько легко масштабируется функционал системы, добавляются новые возможности.
Группа 2 — Качество разрабатываемого продукта
Данная группа метрик позволяет оценить и сравнить от релиза к релизу как качество ПО, так и качество самой разработки.
1. Плотность дефектов
«Количество дефектов в отдельном модуле» / «Общее количество дефектов в ПО»
Рассчитывается как доля дефектов от общего их числа, приходящихся на отдельный модуль в рамках итерации или релиза.
Назначение метрики: подсветить, какая часть ПО является наиболее проблемной. Эта информация поможет при оценке и планировании работ с данным модулем, а также при анализе рисков.
Назначение метрики: показать, на что уходят усилия команды — занимается ли она больше разработкой и отладкой новых фич или основную часть времени тратит на исправления в уже существующих частях ПО.
Назначение метрики: дать оценку качеству разработки и исправления дефектов, а также сложности продукта или отдельного модуля.
Группа 3 – Возможности и эффективность команды QA
Основная задача данной группы метрик заключается в том, чтобы выразить в цифрах, на что способна команда тестирования. Эти показатели можно и нужно рассчитывать и сравнивать на регулярной основе, анализировать тенденции, наблюдая, как на работу команды влияют те или иные изменения.
1. Скорость работы (velocity) команды QA
«Количество story points за N итераций)» / «N»
Рассчитывается как отношение реализованных story points \ требований \ user stories за несколько итераций \ sprints к количеству выбранных итераций.
Назначение метрики: численно выразить возможности, скорость работы команды для дальнейшего планирования объема работ и анализа трендов развития. Метрика позволяет следить за скоростью работы QA, наблюдать за тем, какие внутренние или внешние воздействия на команду влияют на эту скорость.
2. Среднее время жизни дефекта
«Суммарное время исправления найденных дефектов» / «Количество дефектов»
Общее время, в течение которого были открытыми дефекты, найденные в рамках итерации или релиза, к сумме дефектов.
Назначение метрики: показать, сколько в среднем времени уходит на работу с одним дефектом: на его регистрацию, исправление и воспроизведение. Данный показатель позволит оценить время, необходимое на тестирование, выделить области ПО, с которыми возникают наибольшие сложности.
Группа 4 — Качество работы команды тестирования
Задача этого набора метрик: оценить, насколько качественно тестировщики выполняют свои задачи, определить уровень компетенций и зрелости команды QA. Обладая таким набором показателей, можно сравнивать команду с ней же на разных отрезках времени или с другими, внешними группами тестирования.
1. Эффективность тестов и тестовых наборов
«Количество обнаруженных ошибок» / «Количество кейсов в тестовом наборе»
Назначение метрики: показать, как много ошибок в среднем позволяют обнаружить наши кейсы. Эта метрика отражает качество тест дизайна и помогает следить за тенденцией его изменения.
Назначение метрики: продемонстрировать качество тестирования и эффективность обнаружения ошибок — какая доля дефектов была отфильтрована, а какая прошла на продуктив.
Отношение времени, потраченного командой непосредственно на целевые QA активности, к общему количеству часов.
Назначение метрики: во-первых, увеличить точность планирования, а во-вторых, отслеживать и управлять эффективностью работы команды.
Назначение метрики: позволяет использовать поправочный коэффициент для последующих оценок.
Группа 5 — Обратная связь и удовлетворенность пользователей
И в заключение, группа метрик, показывающая, как продукт был принят конечными пользователями, насколько он соответствовал их ожиданиям. При этом в рамках оценки взаимодействия с пользователями нам важна не только обратная связь о самом ПО. Еще одна значимая задача этой группы метрик — показать, удовлетворены ли пользователи процессом взаимодействия с командой ИТ в целом и QA в частности.
1. Удовлетворенность пользователей ИТ сервисом
Проводится регулярный опрос удовлетворенности пользователей сервисом ИТ с выставлением баллов.
Назначение метрики: показать, доверяют ли пользователи команде ИТ, понимают ли, как и почему организована ее работа, насколько эта работа оправдывает ожидания.
Назначение метрики: определить степень участия внешних стейкхолдеров (бизнес, инфраструктура, пользователи, поддержка и т.д.) в работе над продуктом. Имея на руках такую метрику, можно сориентироваться, где требуется получить обратную связь, чтобы однажды не столкнуться с проблемами и непониманием.
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Продолжу хвастаться статусом книги.
• Почему хуки – это лучшее что произошло в развиии Октябрьская лента: лучшее за месяц
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Наталья Руколь, тренер курса «Аудит и оптимизация QA-процессов»
Ключевой парадокс тестирования за эти годы так и остался нерешенным: как оценить результаты процесса, который не производит конкретный, ожидаемый заказчиком продукт? Никому не нужны баг-репорты и тест-кейсы, всем нужен только качественный софт, да ещё и выпущенный вовремя. Как в таких условиях показать ценность работы QA-команды? Здесь нам на помощь приходят метрики, и на текущий момент наверное уже в каждом проекте по разработке софта собираются какие-то измеримые показатели тестирования. Тест-менеджеры понимают, что какие-то метрики им надо внедрить, это в тренде, и начинают искать, что бы им такого померять на проекте? Статьи, форумы, доклады на конференциях пестрят конкретными примерами метрик, которые начинающие тест-менеджеры спешат посчитать на своих проектах. Но так не работает!
Никакие метрики не являются универсальными – напротив, это лишь инструмент, который помогает вам в решении определенных задач. Вы сначала определяете, что вам нужно, а уже потом ищете способы это померить, но не наоборот! Никто не покупает молоток, чтобы потом ходить и думать, какой бы гвоздь им забить. проверить сталкиваясь с задачей “повесить на стену картину” мы думаем, что нам для этого нужно, и только после этого идём в магазин за нужным гвоздём и подходящим молотком. Вот и с метриками в тестировании то же самое: сначала мы определяем цели, и только потом думаем, какие метрики могут нам помочь в их достижении (и могут ли).
Для чего нужны метрики?
В таком случае мы ищем косвенные процессные метрики, которые будут вести нас к повышению оценок. Читаем отзывы и выясняем, за что снижены оценки. Находим три лидера по упоминаниям среди жалоб: падения на нестандартных окружениях, медленная скорость работы, нехватка запрошенных фич. Отлично, с этим уже значительно понятнее, как работать, чем с абстрактной оценкой нравится/не нравится! Мы можем выбрать метрики, которые помогут нам оценить свою работу (покрытие тестами на разных окружениях, проведение тестов производительности), так и общепроектные метрики: скорость работы и готовность запрошенных фич. Таким образом мы поможем и самим себе, чётко отслеживая рост требуемого тестового покрытия, и другим участникам команды, сразу показав, чего не хватает для релиза. До выпуска полгода, а поднять число тестовых окружений на 6% я уже могу сегодня!
Допустим, вы приходите к руководству со стандартным списком жалоб: ресурсов не хватает, времени слишком мало, требований нет, код отстой. Скажите ему это, и он будет отмахиваться от вас всеми доступными способами.
Хотите получить результат вместо отмашек? Придите с метриками. Покажите, что экономия ресурсов тестирования в 2000$ обходится проекту в 9000$ на штрафах по договору. Проиллюстрируйте, как экономия недели в начале релиза на написание требований ведёт к задержке релиза в три недели из-за разного понимания ожиданий. Такая беседа всегда будет конструктивнее и результативнее пустой болтовни, не подтверждённой измеримыми показателями!
Метрики: как выбрать и внедрить
Если по написанному выше ещё не стало понятно, что циферки ради циферок не нужны, придётся повториться: никогда не пытайтесь внедрить какую-то метрику просто потому, что она вам кажется логичной или полезной. Всегда идите от задачи, например:
Максимально осознанно пройдитесь по этому списку вопросов. Подключите коллег через совместный брейншторм или опросы. Определите, что вы хотите измерять, не доходя до уровня конкретных чисел и метрик. Сначала вам нужны обобщённые названия метрик, например:
Примеры метрик в тестировании с описанием вариантов их использования
В рамках курса «Аудит и оптимизация QA-процессов» мы с Олегом Грабко помогаем ученикам выявлять те метрики, которые будут им максимально полезны в конкретных ситуациях. Из тех более трехсот метрик, которые мы когда-либо использовали, мы выбрали 94, наиболее наглядно иллюстрирующих возможности этих инструментов и приложили их в качестве дополнительного материала к уроку №3. Я очень надеюсь, что изложенной выше статьи достаточно для того, чтобы вы смогли внедрить нужные вам показатели с пользой и существенно улучшить с ними свой процесс тестирования.
Внимание! Пожалуйста, сначала проведите работу по анализу ваших потребностей в измерении, алгоритм которой я привела выше, и только после этого ознакомьтесь с примерами метрик.
Скорее всего в этих примерах вы найдёте такие показатели, которые помогут в решении стоящих перед вами задач. Но что делать, если необходимость в метрике вы выявили, но подходящего варианта для её расчёта не нашли? Пишите нам! Обещаем по каждому запросу на вариант внедрения метрики подготовить такой способ расчёта и визуализации, который получится внедрить в ваши условия. Таким образом, постепенно мы сделаем этот документ ещё более полным и полезным для всей отрасли.
Всем качественных продуктов, растущих показателей и зрелых процессов!
Тестирование ПО
Самые важные метрики QA
В этой статье я хочу рассмотреть одни из самых важных QA метрик на мой взгляд. Это будут такие показатели, коэффициенты и индикаторы, которые позволят охватить общую картину происходящего на проекте с точки зрения качества и определить шаги по его улучшению. Метрики будут касаться 5 разных областей: требования, качество ПО, эффективность команды тестирования, качество работы QA и обратная связь. Важно измерять и отслеживать показатели одновременно в различных срезах процесса разработки ПО, чтобы обнаруживать общие, корневые проблемы, уметь настраивать и оптимизировать весь процесс
Эта группа метрик позволит оценить, насколько мы проработали требования (user story) к ПО, определить уязвимые места и наиболее сложные, потенциально проблемные фичи ПО, понять, где требуется особый контроль:
1. Тестовое покрытие требования
Иными словами, это количество тестов на 1 требование.
Назначение метрики: выявить слабые места в тестовом покрытии, подсветить риски.
2. Степень взаимосвязанности требований
Метрика вычисляется как среднее количество связей каждого требования с остальными требованиями.
Назначение метрики: дать основание для оценки сроков тестирования и учета возможных рисков. Зная степень взаимного влияния требований друг на друга можно, например, запланировать дополнительное время и кейсы для сквозного тестирования, проработать регрессионные проверки, посмотреть в сторону интеграции и т.п.
3. Коэффициент стабильности требований
Назначение метрики: показать, как много уже реализованных требований приходиться переделывать от релиза к релизу при разработке новых фич.
Как следует из названия, эта группа метрик демонстрирует качество ПО, а также и качество самой разработки.
1. Плотность дефектов
Вычисляется доля дефектов, приходящаяся на отдельный модуль в течение итерации или релиза.
Назначение метрики: подсветить, какая часть ПО является наиболее проблемной. Эта информация поможет при оценке и планировании работ с данным модулем а также при анализе рисков.
2. Коэффициент регрессии
Назначение метрики: показать, на что уходят усилия команды: занимаемся ли мы больше созданием и отладкой новых фич или основную часть времени вынуждены латать уже существующие части ПО
3. Коэффициент повторно открытых дефектов
Назначение метрики: дать оценку качеству разработки и исправления дефектов, а также сложности продукта или отдельного модуля
4. Средняя стоимость исправления дефекта
Отношение суммы затрат понесенных командой при работе со всеми дефектами (например, в рамках релиза) к общему числу дефектов.
Назначение метрики: показать как дорого нам обходиться обнаружение и исправление каждого дефекта. Это даст возможность посчитать выгоду от сокращения числа допускаемых ошибок, оценить целесообразность соответствующих техник.
5. Количество дефектов в коде конкретного разработчика
Назначение метрики: подсветить возможные сложности в команде разработки, кому из специалистов не хватает опыта, знаний или времени, нужна помощь.
Группа 3 – Возможности и эффективность команды QA
Основная задача данной группы метрик заключается в том, чтобы выразить в цифрах, на что способна команда тестирования. Эти показатели можно рассчитывать и сравнивать на регулярной основе, анализировать тенденции, наблюдать по ним, как на работу команды влияют те или иные изменения.
1. Скорость работы (velocity) команды QA
Рассчитывается как отношение реализованных story points (или требований, или user stories) за несколько, например, 4-5 итераций (Sprint) к количеству выбранных итераций.
Назначение метрики: численно выразить возможности, скорость работы команды для дальнейшего планирования объема работ и анализа трендов развития
2. Среднее время жизни дефекта
Общее время, в течение которого были открытыми дефекты, найденные в рамках итерации или релиза к сумме дефектов.
Назначение метрики: показать, сколько в среднем времени уходит на работу с одним дефектом: на его регистрацию, исправление и воспроизведение. Данный показатель позволит оценить время, необходимое на тестирование, выделить области ПО с которыми возникают наибольшие сложности.
Задача этого набора метрик оценить насколько качественно тестировщики выполняют свои задачи, определить уровень компетенций и зрелости команды QA. Обладая таким набором показателей можно сравнивать команду с ней же самой в разные моменты времени или с другими, внешними группами тестирования.
1. Эффективность тестов и тестовых наборов
Назначение метрики: показать как много ошибок в среднем позволяют обнаружить наши кейсы. Эта метрика отражает качество тест дизайна и помогает следить за тенденцией его изменения.
2. Коэффициент ошибок, пропущенных на продуктив
Кол-во ошибок обнаруженных после выпуска релиза \ общее кол-во ошибок в ПО обнаруженных в процессе тестирования и после выпуска
3. Реальное время работы команды QA
Отношение времени потраченного командой непосредственно на QA активности к общему кололичеству часов.
Назначение метрики: во-первых, увеличить точность планирования, а во-вторых, отслеживать и управлять эффективностью работы той или иной команды.
4. Точность оценки времени по областям\видам\типам работ
Назначение метрики: позволяет использовать поправочный коэффициент для последующих оценок.
5. Доля неподтвержденных (отклоненных) дефектов
Назначение метрики: показать сколько дефектов были заведены «вхолостую».
1. Удовлетворенность пользователей ИТ сервисом
Регулярный опрос удовлетворенности пользователей сервисом ИТ с выставлением баллов.
Назначение метрики: показать, доверяют ли пользователи команде ИТ, понимают ли, как и почему организована ее работа, насколько эта работа оправдывает ожидания.
2. Удовлетворенность пользователей продуктом
Регулярный опрос пользователей о том, насколько они удовлетворены продуктом.
Назначение метрики: определить, насколько разрабатываемый продукт соответствует ожиданиям пользователей, в том ли направлении мы движемся, правильно ли определяем важность фич и выбираем варианты решений.
3. Вовлеченность стейкхолдеров
Количество инициатив и предложений по улучшению процесса и продукта, поступивших в течение итерации (релиза) со стороны стейкхолдеров
Назначение метрики: определить степень участия внешних стейкхолдеров в работе над продуктом. Имея на руках такую метрику можно сориентироваться, где требуется получить обратную связь, чтобы однажды не столкнуться с презрением и ненавистью проблемами и непониманием.
Риски и метрики в автоматизации тестирования
Добрый день!
Бизнес любит измерять, менеджмент любит прозрачность, а сотрудники не любят всю эту бумажную работу, в особенности если от них хотят неизвестно что… Процессы автоматизации тестирования не исключение. Я приведу 5 рисков, которые чаще всего встречаются, которые стреляют, которые нельзя недооценивать, которые могут привести к провалу всего тестирования и проектов в целом. Также я приведу примеры метрик, добросовестное использование которых поможет успокоиться вам, вашему начальству, бизнесу.
Помимо этих рисков существуют глобальные: неверный выбор стратегии тестирования, отсутствие ООП в создании фрэймворка и тестов… Но они, в отличие от первых, приводят лишь к увеличению стоимости тестирования, а не к провалу тестирования как такового, как процесса, как идеологии, как инструмента обеспечения качества продукта, а в конечном счёте лояльности клиентов, которые приносят вам доходы. Если вы, как специалист, можете объяснить это руководству, добиться от разработчиков уважения (его надо заслужить 🙂 ), убедить всех в правильности выбранных подходов и стратегий, вы на верном пути.
Риски:
1. Если будем организовывать автоматизацию тестирования там, где она не нужна, мы выкинем кучу денег
Это первый и главный риск любого процесса. Руководители, особенно в странах постсоветского пространства, редко отличаются гибкостью. Если в голове есть представление, что автоматизация тестирования есть благо, то его будут пихать всюду где нужно и не нужно. Совсем забывается, что реальный возврат инвестиций в автоматизации тестирования возникает в лучшем случае со второго релиза. Нужно научиться объяснять бизнесу, что не всякая автоматизация даст качественное покрытие и что это будут просто выброшенные мотивация, время и деньги.
2. Если мы напишем десятки тысяч тестов, которые буду гоняться на CI в облаках, то мы обманем себя в вопросах качества
Это чаще всего встречающийся анти-паттерн. На нём остановлюсь подробнее — об остальных паттернах и анти-паттернах можно почитать здесь — синяя секция будет наиболее интересна всем, кто пишут unit-тесты. Это давно сформулированные анти-паттерны, которые уже можно отнести к аксиомам.
Без шуток — если мы допускаем тяжеловесные тесты, тесты-лжецы и так далее, мы обрекаем себя на провал проекта. Не раз, принимая участие в аудировании процессов тестирования в различных компаниях, я сталкивался с этим явлением, отговаривал автоматизаторов и руководство от написания тестов ради тестов. Некоторые слушали — и выгребали много всего плохого до внедрений, некоторые не слушали — 3 проекта рухнули в один день, хотя тестов зелёных было порядка 8000 тысяч на каждый.
CI в облаках — да, люблю эту тему. Зачем гонять функциональные тесты на сервере непрерывной интеграции, если тесты все гоняются 10 минут? Зачем CI, если релизы выкатываются раз в месяц, а не раз в день. Как и любой специалист в автоматизации тестирования, я овладел навыками создания скриптов для запуска всего этого чуда на TeamCity, но факт в том, что ни разу, в какой бы команде я ни работал, не приходилось использовать CI иначе как для сборки и прогона unit-тестов. Все функциональные тесты должны гоняться до коммита, а не после него. Я в этом убеждён… При таком подходе есть проблемы при кросскомандной работе. Но и они решаемы грамотной организацией процесса.
3. Если мы будем использовать изолированные входные данные для тестов, то пропустим Critical баги в production
В предыдущей моей статье предлагали разделить unit-тесты и функциональные авто-тесты. Я бы всё-таки старался этого не делать, и считаю, что в большинстве случаев данные не должны быть изолированными. Если мы можем внести случайность во входное поведение для теста, её обязательно надо включить. Пользователи (взывающие стороны методов, если речь идёт о unit-тестировании) всегда в среднем производят действие с данными в определённом диапазоне. Можно сделать провайдера входных данных, который опирался бы на это распределение и приблизить тем самым всё к реальности.
Например, недавно столкнулся с «фичей», которая ярким образом проявлялась у нас. Система ложилась на колени, если в ответ на запрос об оплате от банка приходил номер карточки длиной больше 16 знаков. Да, конечно, это нереально в нашем мире 16тизначных карточек, но, простите, а когда станет реально… когда клиентам банков перевыпустят карточки, и они начнут постепенно уходить из постоянных клиентов сервиса к конкурентам, а бизнес будет терять деньги, не понимая даже, что не так.
Rem: для Java любителей, — понятно, что используя reflection, можно написать инициализатор любого объекта любого класса, так как в конечном счёте это всего лишь дерево примитивов. Мало кто знает, но уже давно всё реализовано в чудесной библиотеке podam. Вот пример использования:
Также можно аннотациями задавать диапазоны значений и создавать собственные стратегии генерации. В общем — всё, что душе угодно. Намного удобней, чем вызывать setter-ы по всему дереву и, используя, Random и RandomUtils заполнять объект данными. Использование Podam либы вместе с Mockito даёт поразительные результаты с точки зрения лаконичности инициализации возвращаемых заглушкой объектов.
5. Если разработчики не понимают, зачем нужна автоматизации тестирования, не сотрудничают в этих вопросах и воспринимают всё, как обязаловку, то автоматизация тестирования будет неэффективна
При аудите я всегда начинаю с беседы с разработчиками. Оказывается, что 3 из 5 разработчиков абсолютно уверены, что эти вот тестировщики (тут уж неважно мануальные или автоматизаторы) просто проедают зарплату. На вопрос «почему вы так считаете?», ответы всегда разные, но суть одна — «нам это не нужно, потому что мы итак прекрасны». Один разработчик из 5, считает, что автоматизация тестирования нужна, что он уже сто раз ставил эти вопросы в компании, но не находил поддержки у коллег. Ещё 1 всех давно уже послал и сам пишет тесты, потому что считает это необходимым, навязывать никому ничего не хочет. Так он обеспечивает качество своей работы. В такой обстановке нужно начинать с переделывания отношения у самоуверенных разработчиков к тестированию. Иначе можно даже не пробовать ставить процессы автоматизации тестирования, потому что тесты гоняться не будут, а даже если и будут, то на результаты никто не будет обращать внимания.
Метрики
Понеслась. Умножение на 100% буду опускать — не злитесь.
1. Процент автоматизируемых тестов.
Да… Увы, не всё нужно автоматизировать и не всё возможно автоматизировать. Если у вас есть список тестов, которые хотелось бы автоматизировать, то было бы логично измерить
PA(%) = количество тестов, которые могут быть автоматизированы / количество всего тестов.
2. Процент продвижения автоматизации
AP(%) = количество автоматизированных тестов / количество тестов, которые могут быть автоматизированы.
Эта метрика очень полезна при рассмотрении во времени процесса автоматизации. Если с каждым новым спринтом этот процент падает, стоит задумать о том, почему такое происходит — пересмотреть взгляды, архитектуру, добавить при необходимости людей в команду и т.д. Конечно, стремимся тут к 100%
3. Продвижение тестирования
TP = количество написанных тестов / промежуток во времени
Полезная метрика, как для определения изменения производительности, так и для оценок сроков покрытия плана. Если производительность колеблется в диапазоне — это нормально. Если она вдруг резко падает или резко взлетает, стоит задаться вопросами. В первом случае — возможно у специалиста упала мотивация или происходят систематические ошибки с оценкой сложности работ. Во втором — возможно, создаётся видимость работы в результате сильного дробления проверок, что тоже не есть хорошо.
4. Процент покрытия
TC(%)= количество написанных тестов / количество требований
Мутная, но полезная метрика, когда речь идёт об оценке глубины покрытия. Лучше даже, наверное, брать обратную пропорцию в качестве процента… Если грамотно её использовать, например, фича-тесты в Agile, то можно не только прикинуть сколько будет тестов через несколько месяцев, но и понять, что пришло время оптимизировать что-то, чтобы сократить время прогона этих самых тестов.
5. Плотность дефектов
TC(%)= количество открытых дефектов / общий размер продукта
Крайне важная метрика, которой пренебрегают ввиду отсутствия разумной возможности оценить, что такое размер продукта. Есть классическое представление о том, что в среднем на 3 строчки кода приходится по одному дефекту. По мне так это бред, а если это так, то, простите, тестирование уже не поможет 🙂 В общем, для Scrum процесса можно в качестве этого самого размера продукта просуммировать story points, — если найденных дефектов мало, нормируйте формулу. В любом случае, это очень полезная метрика как внутри команды, так и снаружи, — особенно когда продукт готовится к выходу в свет. Вообще agile автоматизация тестирования — это отдельная песня. Желающие могут почитать про неё здесь
6. Эффективность устранения дефектов
DRE(%)= дефекты, найденные во время тестирования / (дефекты, найденные во время тестирования + дефекты, найденные пользователями в production)
Крайне важная метрика, без которой никуда. Если по результатам прогона автотестов мы имеем, допустим, 15 дефектов, исправляем их, а после выкатывания на пользователей мы замечаем ещё 15 новых и коварных, то печаль — значит не следили за метриками выше… Получив этот процент, надо как можно скорее поднять его в 100%. Так что эту метрику нужно рассматривать во времени после деплоймента. Тесты на вновь возникшие дефекты должны быть написаны немедленно и должны падать, а не проходить 🙂
Заключение:
Старайтесь придумывать метрики не для руководителей, а для себя. Старайтесь уметь объяснять не только себе, но и другим, как происходит улучшение процессов автоматизации. Показывайте, что дают те или иные технологии, по сравнению с другими, формулируя это в цифрах, понятных тем, кто ничего не смыслит в автоматизации тестирования.
6 февраля 2013 года я опубликовал статью в Journal of Mathematical Sciences (New York), 2013, 188:6, 758–760. Abstract и начало можно посмотреть здесь.
О чём там подробно рассказывать не буду, но как следствие одной из теорем, приведу пример, который так часто проявляется в провальных проектах — если каждый новый максимум количества открытых дефектов при условии, что прошлый максимум количества открытых дефектов = x, достигает значения порядка x^2, то проект оказывается в условиях равномерного распределения количества дефектов. То есть, увидев такую тенденцию, будьте готовы к тому, что перестанет работать весь функционал — причём очень быстро. Эта закономерность подтверждалась много раз на практике, да и не только с максимумами дефектов…
Скажу честно, я знаю компании, у которых, чем хуже качество, тем лучше, потому что они живут договорами на тех-поддержку и гребут большие деньги на том, что у заказчика нет никаких других альтернатив. Таким компаниям не нужна автоматизация тестирования, не нужны метрики и не нужно качество. Эта статья обращена ко всем другим компаниям, которые в конкурентной борьбе пытаются заслужить право на лояльность и деньги пользователей.