Отличной всем пятницы, друзья! В конце июня мы запускаем новую группу по курсу «QA-специалист», этому и будет посвящена сегодняшняя публикация.
Существует множество показателей по которым можно измерить эффективность работы команды тестировщиков. Одним из них является коэффициент отклоненных дефектов/ошибок (Rejected Defect Ratio), или же количество отклоненных отчетов об ошибках деленное на общее количество принятых отчетов. Должно быть, вы думаете, что если количество отклоненных отчетов равно нулю, то это хорошо, но здесь не все так просто. Давайте разберемся в типах отклоненных ошибок, посмотрим, как они влияют на коэффициент отклоненных ошибок, и вычислим правильный коэффициент для вашей команды.
Есть три категории отклонённых ошибок:
Давайте начнем с ошибок самих по себе.
Есть два типа невоспроизводимых ошибок. Первый — это ошибка, которую действительно трудно воспроизвести. Это может быть ошибка, возникающая в результате взаимодействия нескольких параметров, о некоторых из которых вы даже не знаете.
Предположим, вы провели несколько тестов подряд, и какой-то один из тестов изменил параметр конфигурации со значения по умолчанию А на какое-то другое значение В. Ошибка происходит только тогда, когда параметр конфигурации содержит значение В, а входное значение равно С. При попытке воспроизвести ошибку, скорее всего, вы захотите начать с известного состояния, чтобы инициализировать систему (или, возможно, произвести чистую установку). Ошибки не произойдет, поскольку параметр конфигурации теперь снова содержит значение по умолчанию А.
Другой вариант такого рода невоспроизводимой ошибки – это когда тест действительно обнаружил дефект, но в информации о воспроизведении отсутствуют какие-то данные: шаг, конкретное входное значение или понимание того, что ошибка возникает только при определенном порядке действий. В результате попытки воспроизвести ошибку ни к чему не приводят.
В обоих вышеуказанных случаях, однако, действительно дефект в самом продукте.
Второй тип невоспроизводимой ошибки – это когда ошибку нельзя повторить, потому что ее нет. Тестировщик мог что-то заметить, но истолковать неправильно, или же в системе, используемой для тестирования, могла возникнуть какая-то проблема, такая как неисправный аппаратный компонент, несовместимый драйвер или неправильные настройки доступа. Попытки воспроизвести ошибку в правильно сконфигурированной системе завершаются неудачей.
Оба этих типа ошибок обычно помечаются в системах отчетов об ошибках как " отклонено – нельзя воспроизвести.”
Такой тип ошибок встречается в случае, если тестировщик решает, что продукт должен вести себя определенным образом и сообщает об ошибке, когда поведение его ожиданиям не соответствовало. Однако более детальное изучение требований показывает, что ожидания тестировщика были ошибочными, и продукт на самом деле функционировал правильно. То есть тестируемый продукт отработал верно, а тестировщик, который не был достаточно знаком с требованиями, ошибся.
Такие ошибки обычно помечаются в системах отчетов об ошибках как «отклонено — не ошибка” или» отклонено—по архитектуре " (то есть поведение соответствует архитектуре).
Повторяющиеся ошибки – это те ошибки, о которых кто-то один уже сообщил, а за ним сообщает следующий. Ошибка является повторяющейся, только если «симптомы» ее появления одинаковы. А если первопричина ошибки одна и та же, но «симптомы» оказались разными, это не повторение ошибки!
Эти ошибки обычно помечаются в системах отчетов об ошибках как «отклонено — дубликат/повторение.”
Очевидно, что некорректная ошибка это своего рода трата времени, которое тестировщик затратил на воспроизведение ошибки и сообщение о ней, времени, которое те, кто сортируют ошибки, тратят на чтение и понимание их, и времени, которое разработчики тратят на попытку воспроизвести невоспроизводимую ошибку или на исправление (и неисправление) чего-то, что не нуждалось в этом исправлении.
Помимо того, что коэффициент отклоненных ошибок или RDR является мерой неэффективности команды тестировщиков, он также говорит о профессионализме тестировщиков в целом. Ошибка, которую нельзя воспроизвести из-за отсутствия необходимой информации в отчете говорит о том, что тестировщики не были дотошными и недостаточно потрудились, чтобы эту ошибку воспроизвести с помощью ими же описанных шагов. Кроме того, для ошибок, которые воспроизводятся нечасто, тестировщики в целом не сделали заметку о низкой частоте воспроизведения в отчете.
Появление некорректной ошибки говорит о том, что тестировщики не полностью понимают требования к продукту. Повторяющиеся ошибки показывают, что тестировщики не выполнили и минимального поиска в локальной базе данных ошибок, чтобы проверить встречалась ли она раньше. Или же, это означает, что специалист, который сообщил об этой ошибке первым не включил в название правильные ключевые слова, чтобы облегчить поиск другим своим коллегам.
В свою очередь, если получается так, что найденную мной ошибку отклоняют, я негодую, ведь меня посчитали непрофессионалом. С одной стороны, это значит, что найденные ошибки я буду отстаивать. Когда мой отчет отклоняют, я поступаю следующим образом:
С другой стороны, определенная вероятность отклонения ошибки заставляет меня быть осторожным. Если я не до конца уверен, что нашел баг, я потрачу еще какое-то время на проверку, прежде чем отчитываться. Я часто спрашиваю коллегу, правильно ли я трактую требования, или же проверяю, воспроизводится ли ошибка на чужой системе.
Команда тестировщиков должна контролировать и стремиться к снижению уровня RDR. Вопрос лишь в том, какой показатель RDR считать хорошим?
На первый взгляд кажется, что 0% — это оптимальный результат, но я с этим категорически не согласен. Я считаю, что когда RDR держится на каком-то здоровом уровне – это нормально, поскольку если он близок к нулю, команда тестировщиков очевидно страдает от не менее серьезных проблем, чем, допустим, слишком высокий RDR.
Команда тестировщиков должна приложить большие усилия, чтобы достичь крайне низкого RDR. Каждая отклоненная ошибка будет проанализирована, чтобы понять, что пошло не так, и каждый тестировщик, который сообщил об ошибке, которую отклонили, должен будет пояснить, что на самом деле произошло и как такой ситуации можно избежать в будущем. В результате тестировщики будут сообщать об ошибках, в которых они абсолютно уверены.
Если они замечают поведение, которое по их мнению повредит удобству использования продукта, они предпочтут принять как должное такое поведение, а не оправдываться в том, что они нашли ошибку, которая на самом деле исходя из требований ошибкой не является. Если у них есть доказательства, что произошла ошибка, но нет хорошего сценария ее воспроизведения, они предпочтут не сообщать об этом; им действительно не хочется расстраивать себя. Если они сталкиваются с несерьезным багом, они могут вообще решить не сообщать об этом, потому что незначительные баги не всегда исправляют, так зачем рисковать и бояться, что найденную тобой ошибку отклонят?
Короче говоря, стремление к очень низкому RDR порождает стресс и нездоровое поведение в команде тестировщиков, а также увеличивает вероятность того, что некоторые ошибки так и останутся незамеченными.
Нам нужны тестировщики, которые не просто сообщают о явных ошибках, но и предупреждают о любом подозрительном поведении в проекте. Мы считаем, что тестировщики, которые придают большое значение тому, чтобы ошибка не ускользнула, даже ценой дубликатов в отчетах, лучше, чем тестировщики, которые тратят часы на проверку того, был ли уже зафиксирован баг в отчетах ранее или нет, в страхе что они сделают дубликат. Мы хотим, чтобы тестировщики чувствовали себя комфортно, подвергая сомнению слово системного архитектора или спецификации требований, даже если это означает, что некоторые из их ошибок будут помечены, как отклоненные.
Нам нужны тестировщики, которые не боятся время от времени ошибаться. Это означает, что нужно равновесие, поэтому некоторый небольшой RDR считается допустимым.
Мое эмпирическое правило гласит, что RDR должен составлять 15 процентов. Это значение основано на моем опыте работы с командой тестировщиков, которая, по общему мнению, была хорошей и эффективной командой. Это был наш RDR во время нескольких проектов, которые шли друг за другом, в то время как другая команда, которая работала над теми же проектами и параллельно с нами, хотя и была менее осведомлена о продукте и считалась менее эффективной, имела 30—процентный RDR.
Я не думаю, что есть какое-либо оправдание этому значению, кроме моего внутреннего чувства. Это определенно не научно. Я не буду спорить с командой, которая нацелена на 10 или 20 процентов, но я думаю, что терпеть 30 процентов или ставить цель в 5 процентов – это уже проблема.
В конце концов, это решение, которое должно быть принято командой тестировщиков, основываясь на особенностях продукта, уровне экспертности команды, модели разработки, опыта команды разработчиков и многом другом. Я настоятельно рекомендую вам отслеживать RDR и думать, нужно ли вам что-то делать с ним. И если же он слишком высокий или низкий, следует принять соответствующие меры.
По устоявшейся традиции ждем ваши комментарии и приглашаем на бесплатный вебинар, который состоится уже 14 июня. До встречи!
Существует множество показателей по которым можно измерить эффективность работы команды тестировщиков. Одним из них является коэффициент отклоненных дефектов/ошибок (Rejected Defect Ratio), или же количество отклоненных отчетов об ошибках деленное на общее количество принятых отчетов. Должно быть, вы думаете, что если количество отклоненных отчетов равно нулю, то это хорошо, но здесь не все так просто. Давайте разберемся в типах отклоненных ошибок, посмотрим, как они влияют на коэффициент отклоненных ошибок, и вычислим правильный коэффициент для вашей команды.
Есть три категории отклонённых ошибок:
- Невоспроизводимые ошибки;
- Некорректные ошибки;
- Повторяющиеся ошибки.
Давайте начнем с ошибок самих по себе.
Невоспроизводимые ошибки
Есть два типа невоспроизводимых ошибок. Первый — это ошибка, которую действительно трудно воспроизвести. Это может быть ошибка, возникающая в результате взаимодействия нескольких параметров, о некоторых из которых вы даже не знаете.
Предположим, вы провели несколько тестов подряд, и какой-то один из тестов изменил параметр конфигурации со значения по умолчанию А на какое-то другое значение В. Ошибка происходит только тогда, когда параметр конфигурации содержит значение В, а входное значение равно С. При попытке воспроизвести ошибку, скорее всего, вы захотите начать с известного состояния, чтобы инициализировать систему (или, возможно, произвести чистую установку). Ошибки не произойдет, поскольку параметр конфигурации теперь снова содержит значение по умолчанию А.
Другой вариант такого рода невоспроизводимой ошибки – это когда тест действительно обнаружил дефект, но в информации о воспроизведении отсутствуют какие-то данные: шаг, конкретное входное значение или понимание того, что ошибка возникает только при определенном порядке действий. В результате попытки воспроизвести ошибку ни к чему не приводят.
В обоих вышеуказанных случаях, однако, действительно дефект в самом продукте.
Второй тип невоспроизводимой ошибки – это когда ошибку нельзя повторить, потому что ее нет. Тестировщик мог что-то заметить, но истолковать неправильно, или же в системе, используемой для тестирования, могла возникнуть какая-то проблема, такая как неисправный аппаратный компонент, несовместимый драйвер или неправильные настройки доступа. Попытки воспроизвести ошибку в правильно сконфигурированной системе завершаются неудачей.
Оба этих типа ошибок обычно помечаются в системах отчетов об ошибках как " отклонено – нельзя воспроизвести.”
Некорректные ошибки
Такой тип ошибок встречается в случае, если тестировщик решает, что продукт должен вести себя определенным образом и сообщает об ошибке, когда поведение его ожиданиям не соответствовало. Однако более детальное изучение требований показывает, что ожидания тестировщика были ошибочными, и продукт на самом деле функционировал правильно. То есть тестируемый продукт отработал верно, а тестировщик, который не был достаточно знаком с требованиями, ошибся.
Такие ошибки обычно помечаются в системах отчетов об ошибках как «отклонено — не ошибка” или» отклонено—по архитектуре " (то есть поведение соответствует архитектуре).
Повторяющиеся ошибки
Повторяющиеся ошибки – это те ошибки, о которых кто-то один уже сообщил, а за ним сообщает следующий. Ошибка является повторяющейся, только если «симптомы» ее появления одинаковы. А если первопричина ошибки одна и та же, но «симптомы» оказались разными, это не повторение ошибки!
Эти ошибки обычно помечаются в системах отчетов об ошибках как «отклонено — дубликат/повторение.”
Как отклоненные ошибки влияют на команду
Очевидно, что некорректная ошибка это своего рода трата времени, которое тестировщик затратил на воспроизведение ошибки и сообщение о ней, времени, которое те, кто сортируют ошибки, тратят на чтение и понимание их, и времени, которое разработчики тратят на попытку воспроизвести невоспроизводимую ошибку или на исправление (и неисправление) чего-то, что не нуждалось в этом исправлении.
Помимо того, что коэффициент отклоненных ошибок или RDR является мерой неэффективности команды тестировщиков, он также говорит о профессионализме тестировщиков в целом. Ошибка, которую нельзя воспроизвести из-за отсутствия необходимой информации в отчете говорит о том, что тестировщики не были дотошными и недостаточно потрудились, чтобы эту ошибку воспроизвести с помощью ими же описанных шагов. Кроме того, для ошибок, которые воспроизводятся нечасто, тестировщики в целом не сделали заметку о низкой частоте воспроизведения в отчете.
Появление некорректной ошибки говорит о том, что тестировщики не полностью понимают требования к продукту. Повторяющиеся ошибки показывают, что тестировщики не выполнили и минимального поиска в локальной базе данных ошибок, чтобы проверить встречалась ли она раньше. Или же, это означает, что специалист, который сообщил об этой ошибке первым не включил в название правильные ключевые слова, чтобы облегчить поиск другим своим коллегам.
В свою очередь, если получается так, что найденную мной ошибку отклоняют, я негодую, ведь меня посчитали непрофессионалом. С одной стороны, это значит, что найденные ошибки я буду отстаивать. Когда мой отчет отклоняют, я поступаю следующим образом:
- Я снова проверяю, воспроизводится ли ошибка в моей системе и добавляю шаги воспроизведения, если я что-то пропустил;
- Если мое непонимание требований было вызвано неоднозначным требованием или некорректной документацией, я буду настаивать на том, чтобы ошибка была отмечена как ошибка документации и закрыта только тогда, когда документация будет исправлена;
- Если я считаю, что поведение продукта при выполнении требования является неправильным, я буду говорить о требованиях с архитекторами и разработчиками, пытаться убедить их в том, что требования нужно обновить (в конце концов, я представляю мнение клиента!);
- Если ошибка отклонена как дубликат, я удостоверюсь, что она не была помечена точно так же, или что она не появляется «по тому же сценарию».
С другой стороны, определенная вероятность отклонения ошибки заставляет меня быть осторожным. Если я не до конца уверен, что нашел баг, я потрачу еще какое-то время на проверку, прежде чем отчитываться. Я часто спрашиваю коллегу, правильно ли я трактую требования, или же проверяю, воспроизводится ли ошибка на чужой системе.
Мнение против полного отсутствия отклоненных ошибок
Команда тестировщиков должна контролировать и стремиться к снижению уровня RDR. Вопрос лишь в том, какой показатель RDR считать хорошим?
На первый взгляд кажется, что 0% — это оптимальный результат, но я с этим категорически не согласен. Я считаю, что когда RDR держится на каком-то здоровом уровне – это нормально, поскольку если он близок к нулю, команда тестировщиков очевидно страдает от не менее серьезных проблем, чем, допустим, слишком высокий RDR.
Команда тестировщиков должна приложить большие усилия, чтобы достичь крайне низкого RDR. Каждая отклоненная ошибка будет проанализирована, чтобы понять, что пошло не так, и каждый тестировщик, который сообщил об ошибке, которую отклонили, должен будет пояснить, что на самом деле произошло и как такой ситуации можно избежать в будущем. В результате тестировщики будут сообщать об ошибках, в которых они абсолютно уверены.
Если они замечают поведение, которое по их мнению повредит удобству использования продукта, они предпочтут принять как должное такое поведение, а не оправдываться в том, что они нашли ошибку, которая на самом деле исходя из требований ошибкой не является. Если у них есть доказательства, что произошла ошибка, но нет хорошего сценария ее воспроизведения, они предпочтут не сообщать об этом; им действительно не хочется расстраивать себя. Если они сталкиваются с несерьезным багом, они могут вообще решить не сообщать об этом, потому что незначительные баги не всегда исправляют, так зачем рисковать и бояться, что найденную тобой ошибку отклонят?
Короче говоря, стремление к очень низкому RDR порождает стресс и нездоровое поведение в команде тестировщиков, а также увеличивает вероятность того, что некоторые ошибки так и останутся незамеченными.
Нам нужны тестировщики, которые не просто сообщают о явных ошибках, но и предупреждают о любом подозрительном поведении в проекте. Мы считаем, что тестировщики, которые придают большое значение тому, чтобы ошибка не ускользнула, даже ценой дубликатов в отчетах, лучше, чем тестировщики, которые тратят часы на проверку того, был ли уже зафиксирован баг в отчетах ранее или нет, в страхе что они сделают дубликат. Мы хотим, чтобы тестировщики чувствовали себя комфортно, подвергая сомнению слово системного архитектора или спецификации требований, даже если это означает, что некоторые из их ошибок будут помечены, как отклоненные.
Нам нужны тестировщики, которые не боятся время от времени ошибаться. Это означает, что нужно равновесие, поэтому некоторый небольшой RDR считается допустимым.
Нахождение оптимального коэффициента отклоненных дефектов
Мое эмпирическое правило гласит, что RDR должен составлять 15 процентов. Это значение основано на моем опыте работы с командой тестировщиков, которая, по общему мнению, была хорошей и эффективной командой. Это был наш RDR во время нескольких проектов, которые шли друг за другом, в то время как другая команда, которая работала над теми же проектами и параллельно с нами, хотя и была менее осведомлена о продукте и считалась менее эффективной, имела 30—процентный RDR.
Я не думаю, что есть какое-либо оправдание этому значению, кроме моего внутреннего чувства. Это определенно не научно. Я не буду спорить с командой, которая нацелена на 10 или 20 процентов, но я думаю, что терпеть 30 процентов или ставить цель в 5 процентов – это уже проблема.
В конце концов, это решение, которое должно быть принято командой тестировщиков, основываясь на особенностях продукта, уровне экспертности команды, модели разработки, опыта команды разработчиков и многом другом. Я настоятельно рекомендую вам отслеживать RDR и думать, нужно ли вам что-то делать с ним. И если же он слишком высокий или низкий, следует принять соответствующие меры.
По устоявшейся традиции ждем ваши комментарии и приглашаем на бесплатный вебинар, который состоится уже 14 июня. До встречи!
