Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Количество багов само по себе ни о чем не говорит

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

Сравнение количества багов у разных команд ни о чем не говорит

Количество багов, найденных командой, зависит от множества факторов. Каждый тестируемый продукт уникален. Продукт одной команды может быть очень простым или очень зрелым, а у другой команды сложный или только вылупившийся продукт. Более того, команды могут по-разному заводить баги. У одних принято на словах сообщать разработчику о баге, если фича еще в работе. У других письменно фиксируется каждый найденный баг, даже если это один-единственный выбившийся пиксель. И, наконец, баг одного человека может показаться тремя разными багами другому. Допустим, две команды тестируют продукт под iOS и Android. Одна может завести один баг, который воспроизводится в обеих ОС, а другая заведет по багу на каждую ОС отдельно.

Сравнение количества багов одной команды за разные периоды, возможно, что-то вам скажет

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

• Тестировщики стали лучше находить баги.
• Разработчики стали плодить больше багов.
• Только что заехала новая сложная фича.

Но это также может означать, что:

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

Анализ того, кто нашел баг, пользователь или тестировщик, скорее всего, о чем-то вам скажет

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

Если ваша команда стала отслеживать эту метрику и в первом месяце 75% багов было найдено тестировщиками, а 25% пользователями, вам есть, с чем сравнивать. Затем, если в следующем месяце тестировщики найдут 85% багов, а пользователи 15%, можно заключить, что команда стала лучше находить баги до того, как на них наткнутся пользователи.

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

Обсудить в форуме