Работа с таблицей коэффициентов — это, по сути, аналитический инструмент, который помогает на старте проекта (или при его масштабировании) оценить необходимое количество QA-специалистов.
Каждый коэффициент (тип приложения, этап разработки, сложность, критичность) выбирается на основе анализа текущего или планируемого состояния проекта. Это делается совместно с тимлидом, архитектором, QA-лидом и/или проектным менеджером.
Как правило, это происходит на этапе инициации проекта или при масштабировании команды.
Формально это может быть зафиксировано: в проектной документации (например, в разделе о ресурсном планировании), в Confluence или другой wiki-системе команды, в оценке нагрузки QA-команды при планировании спринтов
По количеству возможных аффилированных объектов (при росте сложности растет кол-во проверок)
По количеству логики и вариативности (чем больше комбинаций, тем сложнее логика)
Для анализа можно использовать:
Сравнить оценки похожих задач на самом раннем этапе и на текущем (если похожая задача стала занимать больше времени, то это говорит об увеличении сложности)
Рост модулей/компонентов приложения + сложность этих модулей. Можно использовать матрицу компетенций.
Количество задеваемого функционала в задаче. У нас есть практика, когда разработчик пишет, что может быть задето в той или иной правке.
Согласны, что количество тестировщиков действительно зависит от проекта. В статье перечисляются основные аспекты, которые необходимо учитывать для определения оптимального соотношения: тип приложения, этап разработки, сложность проекта и требования к тестированию.
Добрый день! Спасибо за вопрос!
Работа с таблицей коэффициентов — это, по сути, аналитический инструмент, который помогает на старте проекта (или при его масштабировании) оценить необходимое количество QA-специалистов.
Каждый коэффициент (тип приложения, этап разработки, сложность, критичность) выбирается на основе анализа текущего или планируемого состояния проекта. Это делается совместно с тимлидом, архитектором, QA-лидом и/или проектным менеджером.
Как правило, это происходит на этапе инициации проекта или при масштабировании команды.
Формально это может быть зафиксировано:
в проектной документации (например, в разделе о ресурсном планировании),
в Confluence или другой wiki-системе команды,
в оценке нагрузки QA-команды при планировании спринтов
Если остались еще вопросы, мы на связи!
Добрый вечер! Спасибо!
Сложность приложения оценивается:
По количеству возможных аффилированных объектов (при росте сложности растет кол-во проверок)
По количеству логики и вариативности (чем больше комбинаций, тем сложнее логика)
Для анализа можно использовать:
Сравнить оценки похожих задач на самом раннем этапе и на текущем (если похожая задача стала занимать больше времени, то это говорит об увеличении сложности)
Рост модулей/компонентов приложения + сложность этих модулей. Можно использовать матрицу компетенций.
Количество задеваемого функционала в задаче. У нас есть практика, когда разработчик пишет, что может быть задето в той или иной правке.
Количество легаси кода без документации
Ну вот, в целом как-то так:)
Согласны, что количество тестировщиков действительно зависит от проекта. В статье перечисляются основные аспекты, которые необходимо учитывать для определения оптимального соотношения: тип приложения, этап разработки, сложность проекта и требования к тестированию.