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

Итак, дано: проект по разработке интерактивного онлайн тренажера, стадия продукта — открытая бета.
Задача: быстро и как можно дешевле найти мешающие релизу баги, исправить их и сдать продукт клиенту.

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

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

Опыт оказался весьма позитивным, как для проекта, так и для тестировщиков. Для тестирования использовалось 2 сценария, оно проходило в выходные, и в понедельник я уже имел 84 бага (3 категории A, 15 — B, 62 — С и 4 — D), оформленных согласно требованиям. После исправления всех этих багов продукт был зарелизен.

Кстати, когда оформлял задание для фрилансеров, не смог найти в интернете подходящее описание категорий ошибок, поэтому составил сам. Возможно, кому-то оно будет полезно:

• Категория А (I). Наличие ошибок данной категории блокирует для пользователя доступ к основной функциональности продукта. Это могут быть ошибки связанные с регистрацией, авторизацией и / или ошибки, возникновение которых не дает пользователю продвинуться дальше по курсу независимо от его текущего состояния.
• Категория B (II). Ограничивают доступ к некоторой функциональности, не влияющей на завершение прохождения продукта или не дают пользователю продвинуться по курсу, в зависимости от предыдущих предпринятых им шагов, заставляя его начать какую-то часть курса проходить заново.
• Категория C (III). Ошибки данной категории напрямую не влияют на процесс использования продукта, но ухудшают целостность его восприятия или впечатления от процесса. Сюда входят ошибки верстки, неверное отображение и расположение графических элементов, замедленная реакция контроллов и т.п.
• Категория D (IV). Ошибки этой категории по сути не являются ошибками. Категория введена для того, чтобы ошибке можно было присвоить ее, в случае, если она связана с функциональностью, визуализацией и прочими свойствами продукта, представление о реализации которых у тестера отличается от того, что предполагалось реализовать.

Если у кого-то возникнут вопросы по содержанию поста, с удовольствием отвечу.

Спасибо за внимание!

Автор: ZaVteR

Источник