Комментарии 7
тестирование как измеряемый процесс;
Можете привести примеры метрик?
Метрик есть довольно много, и нужно выбирать те, которые наиболее важны для конкретного случая.
Из распространенных могу привести: соотношение оценок трудозатрат на тестирование к реальным затратам, общее количество дефектов найденных за итерацию, распределение их по такому показателю как критичность, покрытие требований, соотношение успешно пройденных проверок к тем которые завершились негативно.
В случае, если ваш проект уже вышел в свободное плавание, очень важно измерять эффективность команды тестирования на таких метриках как “утечка” дефектов и эффективность устранения дефектов.
Из распространенных могу привести: соотношение оценок трудозатрат на тестирование к реальным затратам, общее количество дефектов найденных за итерацию, распределение их по такому показателю как критичность, покрытие требований, соотношение успешно пройденных проверок к тем которые завершились негативно.
В случае, если ваш проект уже вышел в свободное плавание, очень важно измерять эффективность команды тестирования на таких метриках как “утечка” дефектов и эффективность устранения дефектов.
эх… мечты мечты…
Практический вопрос по поводу кейза 1.
Откуда у вас было столько свободного времени, что б прошерстить все «огромное количество багов», и чем собственно дело закончилось?
Практический вопрос по поводу кейза 1.
Откуда у вас было столько свободного времени, что б прошерстить все «огромное количество багов», и чем собственно дело закончилось?
Дело в том, что на входе в проект было заложено время на фамилиаризацию. Я решил совместить приятное с полезным. Поскольку проект был относительно небольшим — мне хватило несколько сессий с менеджером чтобы понять текущий функционал и приближающиеся фичи. Потому при разборе JIRA лишь в спорных моментах, по некоторым багам, приходилось обращаться за дополнительной информацией.
Собственно за неделю-две я привел в порядок JIRA — закрыл весь мусор, той крупице реальных багов, которая осталась — выставил Severity, оговорил с командой новый ticket flow, и начал разбираться с теми задачами которые накопились от разработчиков.
Собственно за неделю-две я привел в порядок JIRA — закрыл весь мусор, той крупице реальных багов, которая осталась — выставил Severity, оговорил с командой новый ticket flow, и начал разбираться с теми задачами которые накопились от разработчиков.
Добрый день! Михаил, очень интересный материал, спасибо.
Правильно ли я понимаю, что такой подход к работе применим только если у вас есть опред. админ ресурс или руководство проекта хотя бы на вашей стороне?)
Правильно ли я понимаю, что такой подход к работе применим только если у вас есть опред. админ ресурс или руководство проекта хотя бы на вашей стороне?)
Здравствуйте! В моем случае, я являюсь ответственным за процессы тестирования — потому руководство полагается на мои навыки и видение. Зачастую, на промежуточных результатах команда может оценить работу и тогда развеиваются последние сомнения.
По правде говоря, когда руководство не желает налаживать процессы на проекте, а коллеги считают что тестирование не важно — то никакой подход работать не будет, и в таком случае вопрос перетекает в область налаживания коммуникации и отношений внутри команды:)
По правде говоря, когда руководство не желает налаживать процессы на проекте, а коллеги считают что тестирование не важно — то никакой подход работать не будет, и в таком случае вопрос перетекает в область налаживания коммуникации и отношений внутри команды:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Test Maturity Model: как тестировщику оценить проект и спланировать процессы