Как стать автором
Обновить

Точная оценка задач QA: возможно ли это?

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров5.4K
Всего голосов 7: ↑6 и ↓1+12
Комментарии7
2

Комментарии 7

Внимательно перечитал на 3 раза и все равно не понял, зачем делать оценку после теста?

У нас более 8 продуктовых команд, и иногда еще релизятся проекты. Вначале все задачи на релиз (и проекты) тестируются изолированно у себя на стендах, чтобы найти и исправить все баги своего функционала. После этого (когда все баги исправлены, НТ и UAT, если надо, пройдены), все это добро со всех команд мержится в Release Candidate ветку и заливается на стейдж. Как раз на стейдж данная оценка и нужна, т.к. Релиз тестируется 2 недели всеми командами, которые подали задачи в него и данным командам необходимо учесть, хватит ли им ресурса на тестирование их задач в рамках определенного релиза. Также там проходит общее НТ, общий регресс, отлаживаются автотесты и т.д..

Вполне допускаю, да и сам встречал, что на небольших проектах не требуется такое усложнение и достаточно тестирования на одном стенде, после чего можно сразу в прод идти. Но для нашего кейса - использование Release Candidate branching оправдано, т.к. у нас много команд с различным функционалом и могут возникнуть мерж конфликты, а также всплыть неучтенные моменты, при разработке в разных командах фичей по смежному функционалу, а также есть другие интеграционные системы, которые тоже релизятся параллельно и без доп. тестирования тут не обойтись.

Да я конечно понимаю, что таких больших проектов, как у вас, почти нет. Но бывает что и есть. И бывает, что некоторые читатели там работают... Так вот на любом таком проекте обычно до начала разработки фичи оценивается время, которое будет на нее потрачено, в том числе на ее тестирование.

А, судя по тому, что вы описали, у вас изобрели оценку ретеста задач, основанную на логировании времени на функциональное тестирование.

Не увидел в статье ответа на главный вопрос как же вы ДО функционального тестирования оцениваете полное время на тест?

Или у вас вообще это не требуется, тогда другой вопрос конечно.

Не понимаю, к чему тут ирония насчет «больших» проектов и то что у других читателей они тоже есть, по моему совсем неуместно, и на ваш первый вопрос я ответил. 

Что касается пункта «оценки ретеста задач, основанном на логировании времени на функциональное тестирование» - мы не основываемся на легировании времени, затраченного на функциональное тестирование, рекомендую ознакомится в 4 раз. Мы основываем оценку на артефактах тестирования, созданных в рамках функционального тестирования на qa стенде, а не на залогированном времени, в статье это прописано.

По поводу пункта с оценкой ДО функционального тестирования - в статье также описано (точка с оценкой по спецификации) - можно в 5 раз ознакомиться. Суть заключается в том, что нам достаточно верхнеуровневой оценки на данном этапе и что мы пробовали применить метод декомпозиции - но он себя, в нашем случае, не оправдал.

Идея с встраиванием блоков с кодом в конфлюенсе интересная, спасибо!

Спасибо за комментарий! Рад, что идея оказалась полезной!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации