Comments 5
После внедрения данного подхода на сколько процентов у вас уменьшилось количество багов на ПАК после выхода доработок?
Так, а зачем же вообще оценивать результаты тестирования по численным KPI?
Честно, статью прочитал 2 раза, третий раз быстро пробежал глазами и в целом вообще не понял сути внедрения.
Например, мы хотим понять, стали ли мы лучше работать. Не в отдельных проектах (хотя это тоже важно), а как компания или подразделение. Пусть мы регулярно собираем метрики по завершенным проектам, например, плотность дефектов. И с той же регулярностью по ней оцениваем стабильность процесса баг-фиксинга (например). А потом сравниваем показатели – среднее значение и среднеквадратичное отклонение. Среднее значение говорит понятно о чем. Среднеквадратичное отклонение показывает, насколько процесс стабилен. Чем оно меньше, тем более стабилен процесс. Значит, наша работа в будущих процессах более предсказуема. Значит, можно точнее предсказывать, когда и с каким качеством завершится проект. Значит, меньше вероятность неуспешного завершения процесса.
Если же стабильности нет, следует понять (путем анализа конкретных проектов) то, где особые случаи, почему они возникли, что надо сделать, чтобы в будущем избежать / минимизировать их возникновение.
Спасибо за ответ.
По поводу предсказаний, мне кажется, это гадание на кофейной гуще. Так как не учитывается просто человеческий фактор. Во вторых, если процесс разработка/тестирование стабилен, то среднеквадратичное значение всегда будет уменьшаться или хотя бы не увеличиваться, так как все поставлено на поток.
Ну и ещё вопрос: этот инструмент был создан для QA или для менеджера проекта?
Как оценивать работу тестировщиков по науке