Комментарии 26
Скажите, а что является результатом процесса эстимации?
Полагаю, количественные показатели. Если говорить о том случае, который я описала, результатом для менеджера было - попадают ли они в свой фиксированный бюджет и в сроки. Для меня же - сводная таблица с данными о временных затратах на каждую главу ТЗ.
Но я написала, что речь скорее в тот раз шла не об эстимации в целом, а исключительно об оценке времени на тестирование. Фактически произошла подмена понятий, что, кстати, от того менеджера я регулярно слышала.
Как правило, на одного разработчика два тестировщика
А где такие правила есть? Я как-то привык к тому, что стремятся к отношению "один тестировщик на 3|4 разработчика"
Да нет таких правил прописанных, конечно. Всё зависит от проекта. Я исходила из своих, когда было удобно работать. Вот 1 к 4 пока не приходилось.
У нас вообще 1 тестировщик примерно на 7-10 разработчиков :(
У нас 1 тестировщик на 5-6 разработчиков.
Где-то 70% работы тестировщика - проверка задач, которые сделали разработчики (перед ежедневным релизом). За день 2-3 задачи проверяются. Остальные 30% работы - написание и правка UI-тестов.
Разработчик в среднем за неделю делается 2-3 задачи. Соответственно, команда делает порядка 10-15 задачек за неделю, что как раз примерно соответствует «производительности» тестировщика.
При этом на проекте непрерывный релизный цикл, поэтому нагрузка относительно равномерная от недели к неделе.
Вопрос, почему у кого-то в проекте на 1 разработчика 2 тестировщика? Разработчик больше задач за неделю делает или тестировщик меньше может протестировать?
Может, зависит от сложности проекта? Если проект связан с проведением финансовых платежей, уровня mission critical и категорически нельзя допустить ошибок, иначе будут неприятные разборы полетов от других участников проекта. У нас похожий проект и здесь на 1 погруженного тестировщика приходится 2 разработчика. Всего чуть больше десятка человек в команде, разрабы + тестировщики.
Значит, нужно больше тестировщиков, которые смогут сопровождать процессы тестирования финансовой махины с вермишелью бизнес-логики, которые нужно перепроверять и регрессить после каждой выполненной разработчиком задачи.
Если вы пишете про регрессию - вероятно, у вас она делается вручную и это по логичным причинам занимает много времени?
У нас вся основная бизнес-логика покрыта end-to-end тестами (их несколько тысяч) и поэтому проверять требуется только новый функционал, на который тесты еще не успели написать. И такого подхода придерживается все больше компаний.
запасе осталось ещё 26 часов
А сколько всего часов было? 26 из 50 и 26 из 150 - это две большие разницы. Ну и ещё неплохо иметь небольшой запас на случай, если вдруг клиент (ну или кто-то в цепочке после QA) найдёт что-то, что вы упустили - можно будет спокойно пофиксить за оставшиеся часы.
Сразу скажу, что QA не являюсь и богатого опыта самостоятельной оценки затрат времени на тестирование не имею. Возможно из-за этого вопросы и возник)
А можно хотя бы грубо раскладку по часам? Что сколько времени заняло? Тут грубо говоря получилось, что один-единственный тестировщик затащил разработку мобильного приложения с нуля (ну ок, при готовых требованиях) за три месяца, работая на 0.2 ставки 0_о
Насчёт раскладки по часам -- поищу. Считала все на бумаге, блокнот должен был сохраниться. Там был несложный скромный функционал - личный кабинет, календарььи непосредственно покупка консультации.
Что касается графика, то я работала на полставки, над проектом работали мы полтора месяца. У меня была загрузка месяц по 20 часов в неделю + ещё 2 недели по необходимости подключалась на столько, сколько требовалось - там были уже небольшие ретесты. Потратила всего 86 часов.
Но как я написала в ошибках -- я по неопытности потратила на оценку личное время, которое никуда не затрекалось.
О, эстимация. Как вспомню как я делал её - так в холодный пот бросает. И полностью согласен, что всегда надо закладывать время на форс-мажоры.
Тут самый главный вопрос: на какие форс-мажоры и сколько.
Ну вот форс-мажоры - это уж точно пусть менеджер просчитывает.
π (pi) чудесный коэффициент неопределённости, особенно когда вообще не ясно.
Первая оценка будет всё-равно оптимистичной, но при ближайшем рассмотрении всё будет не настолько радужно - теория *оп в помощь
Я один впервые слышу слово эстимация и не очень рад очередному англицизму? Всю жизнь была оценка трудозатрат.
По теме - обычно закладываю примерно 60/40 разработка к внутреннему тестированию и исправлению ошибок. Риски советую для себя хотя бы научиться называть. Риск «ссыкотно» не очень продуктивный, для меня он означает, что надо посмотреть еще раз на всю оценку, может, что-то забыл и убирать его 😁. Правда, у меня есть внутренние риски типа «в прошлый раз они сделали мне мозг» или на бюрократию заказчика, они работают на всю оценку.
80 часов - это очень мало, такие оценки делаются пальцем (культурно это называется «экспертная оценка») и, мне кажется, все оценки делаются пальцем, пусть даже после декомпозиции 😁. Я несколько раз видел попытки сделать эстиматоры, и сам тоже пытался, они не работают, максимум как чек-лист используются.
Да, надо всегда закладывать в оценку анализ, сдачу результата, взаимодействие с другими командами, смотря чем вы занимаетесь.
Слово мне тоже не нравится. Но что поделать,если его используют. Я его узнала только в IT , кстати. Англицизмы прочно поселились, конечно. И частенько их вплетают в речь без понимания смысла.
Риск «ссыкотно»
Никогда не называла это риском, но всё равно научилась с ним бороться
Все оценки делаются пальцем
И мне так кажется. Возможно, я ещё многого не знаю. Или нужен оооочень большой опыт.
Ни разу не пробовала на практике, но метод по 3 точкам всегда нравился больше, всё ещё эпизодически пытаюсь убедить начальство в его пользе. Для меня оптимистично - это количество минимального времени, которое я затрачу на задачу - т.е. прохождение кейсов которые придумала в моменте (у нас не дают долго думать на планировании даже с требованиями сейчас с трудом знакомимся до взятия в работу), без перерыва, оптимально - это время на "подумать" + мелкие перерывы на чай-кофе-туалет - прибавляю 5-10% на мелкий задачах и до 30 на крупных, пессимистично - это та же оптимальность только с починкой мелких дефектов при условии что разработчик оперативно возьмётся чинить это 20-50%, в зависимости от сложности, но здесь стоит хотя бы немного поработать в команде чтобы оценить как быстро работают разработчики.
Когда на новом проекте менеджер попросила меня провести эстимацию тестирования, я сначала растерялась, ведь это вроде как задача менеджера или старшего тестировщика
Вы, наверно имели ввиду:
Вен на нью проджекте манагер аскнула меня сделать эстимэйт тестирования, я была литтл конфьюсед ат фёрст, бекоз это вроде как таска манагера или сеньёр-манагера
<Не>Страшное слово эстимация, или Как я впервые оценивала время на тестирование и перебрала