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