Не понимаю, к чему тут ирония насчет «больших» проектов и то что у других читателей они тоже есть, по моему совсем неуместно, и на ваш первый вопрос я ответил.
Что касается пункта «оценки ретеста задач, основанном на логировании времени на функциональное тестирование» - мы не основываемся на легировании времени, затраченного на функциональное тестирование, рекомендую ознакомится в 4 раз. Мы основываем оценку на артефактах тестирования, созданных в рамках функционального тестирования на qa стенде, а не на залогированном времени, в статье это прописано.
По поводу пункта с оценкой ДО функционального тестирования - в статье также описано (точка с оценкой по спецификации) - можно в 5 раз ознакомиться. Суть заключается в том, что нам достаточно верхнеуровневой оценки на данном этапе и что мы пробовали применить метод декомпозиции - но он себя, в нашем случае, не оправдал.
У нас более 8 продуктовых команд, и иногда еще релизятся проекты. Вначале все задачи на релиз (и проекты) тестируются изолированно у себя на стендах, чтобы найти и исправить все баги своего функционала. После этого (когда все баги исправлены, НТ и UAT, если надо, пройдены), все это добро со всех команд мержится в Release Candidate ветку и заливается на стейдж. Как раз на стейдж данная оценка и нужна, т.к. Релиз тестируется 2 недели всеми командами, которые подали задачи в него и данным командам необходимо учесть, хватит ли им ресурса на тестирование их задач в рамках определенного релиза. Также там проходит общее НТ, общий регресс, отлаживаются автотесты и т.д..
Вполне допускаю, да и сам встречал, что на небольших проектах не требуется такое усложнение и достаточно тестирования на одном стенде, после чего можно сразу в прод идти. Но для нашего кейса - использование Release Candidate branching оправдано, т.к. у нас много команд с различным функционалом и могут возникнуть мерж конфликты, а также всплыть неучтенные моменты, при разработке в разных командах фичей по смежному функционалу, а также есть другие интеграционные системы, которые тоже релизятся параллельно и без доп. тестирования тут не обойтись.
Information
Rating
Does not participate
Registered
Activity
Specialization
Инженер по ручному тестированию, Инженер по обеспечению качества
Спасибо за комментарий! Рад, что идея оказалась полезной!
Не понимаю, к чему тут ирония насчет «больших» проектов и то что у других читателей они тоже есть, по моему совсем неуместно, и на ваш первый вопрос я ответил.
Что касается пункта «оценки ретеста задач, основанном на логировании времени на функциональное тестирование» - мы не основываемся на легировании времени, затраченного на функциональное тестирование, рекомендую ознакомится в 4 раз. Мы основываем оценку на артефактах тестирования, созданных в рамках функционального тестирования на qa стенде, а не на залогированном времени, в статье это прописано.
По поводу пункта с оценкой ДО функционального тестирования - в статье также описано (точка с оценкой по спецификации) - можно в 5 раз ознакомиться. Суть заключается в том, что нам достаточно верхнеуровневой оценки на данном этапе и что мы пробовали применить метод декомпозиции - но он себя, в нашем случае, не оправдал.
У нас более 8 продуктовых команд, и иногда еще релизятся проекты. Вначале все задачи на релиз (и проекты) тестируются изолированно у себя на стендах, чтобы найти и исправить все баги своего функционала. После этого (когда все баги исправлены, НТ и UAT, если надо, пройдены), все это добро со всех команд мержится в Release Candidate ветку и заливается на стейдж. Как раз на стейдж данная оценка и нужна, т.к. Релиз тестируется 2 недели всеми командами, которые подали задачи в него и данным командам необходимо учесть, хватит ли им ресурса на тестирование их задач в рамках определенного релиза. Также там проходит общее НТ, общий регресс, отлаживаются автотесты и т.д..
Вполне допускаю, да и сам встречал, что на небольших проектах не требуется такое усложнение и достаточно тестирования на одном стенде, после чего можно сразу в прод идти. Но для нашего кейса - использование Release Candidate branching оправдано, т.к. у нас много команд с различным функционалом и могут возникнуть мерж конфликты, а также всплыть неучтенные моменты, при разработке в разных командах фичей по смежному функционалу, а также есть другие интеграционные системы, которые тоже релизятся параллельно и без доп. тестирования тут не обойтись.