3 апреля 2013 в 22:15

Как быстро найти баги, мешающие релизу

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

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

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

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

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

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

  • Категория А (I). Наличие ошибок данной категории блокирует для пользователя доступ к основной функциональности продукта. Это могут быть ошибки связанные с регистрацией, авторизацией и / или ошибки, возникновение которых не дает пользователю продвинуться дальше по курсу независимо от его текущего состояния.

  • Категория B (II). Ограничивают доступ к некоторой функциональности, не влияющей на завершение прохождения продукта или не дают пользователю продвинуться по курсу, в зависимости от предыдущих предпринятых им шагов, заставляя его начать какую-то часть курса проходить заново.

  • Категория C (III). Ошибки данной категории напрямую не влияют на процесс использования продукта, но ухудшают целостность его восприятия или впечатления от процесса. Сюда входят ошибки верстки, неверное отображение и расположение графических элементов, замедленная реакция контроллов и т.п.

  • Категория D (IV). Ошибки этой категории по сути не являются ошибками. Категория введена для того, чтобы ошибке можно было присвоить ее, в случае, если она связана с функциональностью, визуализацией и прочими свойствами продукта, представление о реализации которых у тестера отличается от того, что предполагалось реализовать.

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

Спасибо за внимание!
Владимир @ZaVteR
карма
11,0
рейтинг 0,0
Самое читаемое Разработка

Комментарии (6)

  • 0
    Интересная методика, НО:
    1. Что будет, если тестировщики найдут багов больше, чем всего в списке?
    2. Что будет, если тестировщики найдут баг одновременно?
    3. Не было ли ситуации, что при закрытии трёх дыр появлялась четвёртая?
    • +1
      Отвечаю.
      1. Что будет, если тестировщики найдут багов больше, чем всего в списке?

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

      Например, тестировщик нашел багов на сумму 10 000 руб, ограничение установлено в 7 500 руб., но другие нашли на меньшую сумму, бонус установлен в размере 2 000 руб, тогда тестировщик получит 7 500 + 2 000 = 9 500 руб.

      2. Что будет, если тестировщики найдут баг одновременно?

      Каждому этот баг будет оплачен.

      3. Не было ли ситуации, что при закрытии трёх дыр появлялась четвёртая?

      Были, но к методике это отношения не имеет. Такие ситуации разрешались уже штатными тестировщиками.
  • 0
    Я не понял, зачем ограничивать сумму выплаты. Один тестировщик получит 10 или два тестировщика получат по 5. Какая разница?
    • +1
      Всего было 3 тестировщика.
      Соответственно, при наличии ограничения, общий максимальный бюджет = [максимальная сумма выплаты] * 3 + [размер бонуса].
      Т.е. заранее определен, что в ситуации, когда вы не представляете общую сырость проекта, очень полезно.
  • 0
    А как при такой схеме вы проводили валидацию исправления дефектов? регрессионное тестирование после?
    Или у вас была штатная команда тестировщиков кроме упомянутого конкурса для фрилансеров?
    • 0
      Да, команда тестировщиков была, они и проводили валидацию.
      После итерации по исправлению багов было еще раз проведено пользовательское тестирование по такой же схеме.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.