Достался мне в управление проект, который из-за не выстроенных процессов его контроля и мониторинга, находился в весьма плачевном состоянии. Я не буду перечислять полный список проблем и всех предпринятых для их решения шагов, так как хочу поделиться опытом именно быстрого нахождения багов, исправления которых скорее всего будет достаточно, чтобы зарелизить и сдать продукт клиенту.
Итак, дано: проект по разработке интерактивного онлайн тренажера, стадия продукта — открытая бета.
Задача: быстро и как можно дешевле найти мешающие релизу баги, исправить их и сдать продукт клиенту.
Для решения задачи была разработана схема, при которой привлеченные тестировщики фрилансеры замотивированы найти как можно больше багов, при этом общий бюджет не превысит установленную за��анее сумму.
Это было достигнуто, благодаря введению зависимости оплаты от количества и категорий найденных багов. Также была установлена максимальная сумма выплаты, чтобы заранее можно было определиться с максимальным бюджетом, но дабы тестировщик не остановился после набора им максимальной суммы, был введен бонус, которой добавляется к оплате, если этот тестировщик нашел багов на сумму большую, чем все остальные.
Опыт оказался весьма позитивным, как для проекта, так и для тестировщиков. Для тестирования использовалось 2 сценария, оно проходило в выходные, и в понедельник я уже имел 84 бага (3 категории A, 15 — B, 62 — С и 4 — D), оформленных согласно требованиям. После исправления всех этих багов продукт был зарелизен.
Кстати, когда оформлял задание для фрилансеров, не смог найти в интернете подходящее описание категорий ошибок, поэтому составил сам. Возможно, кому-то оно будет полезно:
Если у кого-то возникнут вопросы по содержанию поста, с удовольствием отвечу.
Спасибо за внимание!
Итак, дано: проект по разработке интерактивного онлайн тренажера, стадия продукта — открытая бета.
Задача: быстро и как можно дешевле найти мешающие релизу баги, исправить их и сдать продукт клиенту.
Для решения задачи была разработана схема, при которой привлеченные тестировщики фрилансеры замотивированы найти как можно больше багов, при этом общий бюджет не превысит установленную за��анее сумму.
Это было достигнуто, благодаря введению зависимости оплаты от количества и категорий найденных багов. Также была установлена максимальная сумма выплаты, чтобы заранее можно было определиться с максимальным бюджетом, но дабы тестировщик не остановился после набора им максимальной суммы, был введен бонус, которой добавляется к оплате, если этот тестировщик нашел багов на сумму большую, чем все остальные.
Опыт оказался весьма позитивным, как для проекта, так и для тестировщиков. Для тестирования использовалось 2 сценария, оно проходило в выходные, и в понедельник я уже имел 84 бага (3 категории A, 15 — B, 62 — С и 4 — D), оформленных согласно требованиям. После исправления всех этих багов продукт был зарелизен.
Кстати, когда оформлял задание для фрилансеров, не смог найти в интернете подходящее описание категорий ошибок, поэтому составил сам. Возможно, кому-то оно будет полезно:
- Категория А (I). Наличие ошибок данной категории блокирует для пользователя доступ к основной функциональности продукта. Это могут быть ошибки связанные с регистрацией, авторизацией и / или ошибки, возникновение которых не дает пользователю продвинуться дальше по курсу независимо от его текущего состояния.
- Категория B (II). Ограничивают доступ к некоторой функциональности, не влияющей на завершение прохождения продукта или не дают пользователю продвинуться по курсу, в зависимости от предыдущих предпринятых им шагов, заставляя его начать какую-то часть курса проходить заново.
- Категория C (III). Ошибки данной категории напрямую не влияют на процесс использования продукта, но ухудшают целостность его восприятия или впечатления от процесса. Сюда входят ошибки верстки, неверное отображение и расположение графических элементов, замедленная реакция контроллов и т.п.
- Категория D (IV). Ошибки этой категории по сути не являются ошибками. Категория введена для того, чтобы ошибке можно было присвоить ее, в случае, если она связана с функциональностью, визуализацией и прочими свойствами продукта, представление о реализации которых у тестера отличается от того, что предполагалось реализовать.
Если у кого-то возникнут вопросы по содержанию поста, с удовольствием отвечу.
Спасибо за внимание!
