после релиза? ( Я-jun)
1) поиск багов - это малая часть работы тестировщиков 2) если оценивать QA по количеству багов, в различных срезах, то тестировщики, просто, будут заводить очень много багов
Потому что как и оценка разраба по числу строк кода - это совершенно кривая метрика. Число багов как вспомогательная метрика может быть
А скорость выполнения задач? Это же точно такая же кривая метрика, разве нет? Как пример : у нас на заводе есть люди, которые очень быстро чертят. Но потом ты исправляешь их чертежи два рабочих дня
даже больше. абсолютно все метрики выше если брать их индвидуально - кривые. Надо брать все, и матчить на людей, фичи и прочие факторы. Тогда есть шанс получить хоть как то приемлимые эстимейты. :)
Получается, что все так или иначе упирается в скрепный заводской подход : изучаем людей и их навыки, выдаём команде определенный объем задач и срок сдачи. В конце срока смотрим , что сделано и где закрыть просадки и кем их закрыть:). Чтобы на выходе получить желаемое качество продукта)?
Обсуждают сегодня