Хорошо ли, что тестеры соревнуются, чтобы увидеть, кто открывает больше ошибок?

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

Это хорошо для проекта? Если нет, то как я (как разработчик программного обеспечения) могу попытаться изменить мышление и отношение команды тестировщиков?

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

OBS: Этот конкурс не является практикой компании! Это соревнование между организованными ими тестерами и без каких-либо призов.

Я не думаю, что это хорошо, что они устраивают состязание из поиска большинства ошибок. Хотя это правда, что их работа состоит в том, чтобы находить ошибки, их работа заключается не в том, чтобы «найти большинство ошибок». Их цель - не найти больше, их цель - помочь улучшить качество программного обеспечения. Награда за то, что они нашли больше ошибок, - это то же самое, что вознаграждение программиста за написание большинства строк кода, а не за код самого высокого качества.

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

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

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

Итог: не делайте игру из поиска ошибок. Найдите в своей организации способы вознаграждения за хорошую работу и оставьте все как есть. Геймификация вознаграждает людей за достижение цели. Вы не хотите, чтобы у аналитика QA была цель «найти наибольшее количество ошибок», вы хотите, чтобы их целью было «улучшить качество программного обеспечения». Эти две цели не совпадают.

Я собираюсь немного не согласиться с другими ответами. «Поиск ошибок» для тестера немного похож на «написание кода» для разработчика. Сырое количество не имеет смысла. Работа тестировщика состоит в том, чтобы найти как можно больше существующих ошибок, а не найти большинство ошибок. Если тестер A находит 5 из 10 ошибок в компоненте высокого качества, а тестер B находит 58 из 263 ошибок в компоненте низкого качества, тогда тестер A является лучшим тестером.

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

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

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

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

Вы должны сосредоточиться на пользователе здесь. Пользователь не знает, сколько ошибок было зарегистрировано во время тестирования, все, что он видит, - это то, что удалось пройти. В конечном счете, пользователям все равно, подадите ли вы 20 отчетов об ошибках или 20 000, если программное обеспечение работает, когда они его получают. Лучшим показателем для оценки тестировщиков было бы количество ошибок, о которых сообщили пользователи, но которые должны были быть разумно обнаружены тестерами.

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

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

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

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

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

Поиск ошибок - это их работа. До тех пор, пока они не делают вещи менее эффективными (например, открывая баг для 10-ти опечаток вместо одного, чтобы охватить несколько из них), это побуждает их делать именно то, что они должны делать, поэтому Я не вижу много недостатков.

Это расширение ответа @ CandiedOrange .

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

Каждый день, когда сообщается хотя бы об одной существенной ошибке, оставляйте жетон «Ошибка дня» на столе тестера. Раз в неделю проводите церемонию с участием разработчиков, которые раздают более крупный и лучший жетон или кубок «Ошибка недели». Сделайте доставку трофея "Ошибка месяца" еще более впечатляющей, возможно, с тортом. Каждый жетон или трофей должны сопровождаться цитатой, в которой говорится, почему разработчики посчитали хорошей вещью обнаружение ошибки при тестировании. Копии цитат следует размещать где-нибудь, где все тестеры смогут их прочитать.

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

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

Это хорошо для проекта?

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

Если нет, то как я (как разработчик программного обеспечения) могу попытаться изменить мышление и отношение команды тестировщиков?

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

Я думаю, как это будет (или как это уже есть), если так будет продолжаться, вы не обязательно получите более низкое качество. Хотя я думаю, что это уменьшит соотношение количества к качеству. Это зависит от того, плохо это или нет. Зависит если

сообщать об ошибках об улучшениях экрана, удобстве использования или глупых ошибках.

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

Причина, по которой они устраивают соревнования, - это, вероятно, развлечение во время работы, поэтому они, вероятно, не собираются делать плохую работу (если это считается плохой).