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