Test Maturity Model: как тестировщику оценить проект и спланировать процессы

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

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

Собственно за неделю-две я привел в порядок JIRA — закрыл весь мусор, той крупице реальных багов, которая осталась — выставил Severity, оговорил с командой новый ticket flow, и начал разбираться с теми задачами которые накопились от разработчиков.

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