Эстимация без паники. Как я впервые оценила тестирование, ошиблась на 26 часов и это был +
Просмотров 98нет комментариев
Когда на новом проекте менеджер попросила меня провести эстимацию тестирования, я сначала растерялась, ведь это вроде как задача менеджера или старшего тестировщика. А потом вспомнила, что я – единственный тестировщик на проекте. И понеслось…
Что случилось?
Вспомнила я об этой истории недавно, когда помогала сориентироваться в теме молодой коллеге. Она попала в подобную ситуацию – приложение с нуля, маленькая команда, один QA, есть ТЗ и больше ничего, клиент желает выйти в прод через 3 месяца. Она паникует и не понимает, с чего начать.
Сейчас я спокойно предложила коллеге выдохнуть. Но вот тогда, несколько лет назад, я сама знатно стрессанула, когда поняла, что теория и практика – опять (вот сюрприз!) расходятся. Учить определение и рассказывать о методах эстимации на собеседовании – это одно. Но оценивать задачи на реальном проекте, да ещё когда ты там сам себе старший и младший тестировщик, да ещё впервые – это, знаете ли, для неокрепшей психики новичка такое себе.
Как я уже сказала, проект был небольшой. Мы разрабатывали мобильное приложение онлайн-консультаций для медицинской сферы. У клиента уже был сайт, он просто хотел стать «мобильнее». Ещё до официального начала работы менеджер попросила меня оценить задачи, точнее, время на тестирование. Ей нужны были цифры для того, чтобы обосновать бюджет и количество часов работы QA.
Из плюсов – у меня были требования. Из минусов – не было ничего, кроме требований. Тестовую документацию предстояло тоже писать самой.
Почему эстимация важна для всех
Для опытных QA-специалистов: вы можете быть технарём до мозга костей, но без умения обосновывать эстимации перед стейкхолдерами рискуете оказаться крайним в любой форс-мажорной ситуации. Часто, когда мы только начинаем вести проекты, мы занижаем оценки, чтобы «не пугать». В итоге – переработки, ночные прогоны тестов и напряжённые ретроспективы. А ведь можно было честно озвучить риски сразу и договориться о дополнительных QA-ресурсах или выделении времени на автоматизацию.
Эстимация всего лишь инструмент управления ожиданиями, а не игра «угадай сроки». Чем точнее вы оцениваете, тем легче доказывать необходимость изменений, будь то внедрение новых инструментов, найм специалиста или пересмотр сроков релиза.
Менеджерам проектов и продакт-оунерам не менее важно владеть навыками оценки времени. Когда PM или PO понимает, как команда делает эстимацию, они перестают воспринимать сроки как произвольную цифру «от балды». Это основа для взаимного доверия. Один из наших клиентов раньше постоянно просил «ужать раза в два». После того как ему объяснили логику: где покрытие, где регресс, где риски, – он сам предложил добавить два дня на smoke-тест после релиза. Неплохо же?
Несколько методов эстимации
Методы можно найти в сети разные, я приведу только те, что чаще всего встречались мне.
Декомпозиция. Когда мы делим задачу на более мелкие подзадачи и так до той самой, которую уже можно легко оценить. Это я люблю. С наличием требований удалось вообще быстро разобраться и применить.
Оценка по 3 точкам. Используем три варианта: оптимистичный, наиболее вероятный и худший. И потом используем для подсчёта формулу:
Нужное время = (О +(4*НВ) +х)/6,
где 6 – это стандартное отклонение. Сложновато – первые три варианта тоже надо откуда-то взять. Я скипнула этот метод.
Метод Дельфи. Тут нужна группа экспертов, которая соберётся, заполнит анкеты или сразу всё обсудит и вынесет вердикт, придя к консенсусу. Ну где ж их взять чаще всего, если надо ответить «ещё вчера»?:)) Тоже мимо.
Процентное отношение к разработке. Достаточно популярный метод. Берём время разработки и в зависимости от количества тестировщиков и разработчиков на проекте, умножаем время разработки на процент. Если на два разработчика один тестировщик, время на 0,5 умножаем. Для меня разницы никакой, так как о сроках на разработку мне всё равно не сказали.
UPD Некоторые эксперты мне написали в ЛС, что обычно 60% от разработки берут. Или 80%, если с рисками. А как у вас?\
Опыт. Полезный метод. Очевидный, как то, что… да как что угодно. Я, конечно, использовала.
МетодПальцем в небо. Как ни странно, он так и называется. Хотя, как по мне, то если в начале работы сразу пытаться использовать умные формулы вышеуказанных методов, то примерно ПВН и получается, потому что ты совершенно не понимаешь, как эти штуки применить без опыта.
Ниже в таблице собрала для вас еще рабочие варианты ⬇️⬇️⬇️
Что сделать ДО начала проекта
Повторюсь – мне очень повезло, что я пришла на проект с готовыми требованиями. Была чётко оформленная документация и аналитик на связи. Мне предоставили время для ознакомления с требованиями (хотя фактически это оказалось тестированием требований) и составления плана тестирования.
Итак, ДО начала проекта я:
провела тестирование требований, после чего аналитик внёс несколько изменений и можно было начинать работу;
выбрала (не сразу, к сожалению) оптимальный для себя метод оценки времени на тестирование, совместив три в одном: опыт+сама себе эксперт+декомпозиция;
нашла и установила на свой смартфон приложение, в котором были схожие функции с нашим приложением, по некоторым у меня не было опыта тестирования тогда;
исходя из количества тестовых сценариев в требованиях, набросала примерное количество проверок (позитивных и негативных) на каждую задачу, максимально декомпозировала;
умножила количество тестов на примерное время прохождения тест-кейса. Притом не выводила среднее арифметическое, а отдельно считала явно быстрые прохождения и то, что может занять больше времени;
в риски я заложила 30%.
Цифра, которую я трясущимися руками напечатала менеджеру – 110 часов. Мне казалось, сейчас меня сразу уволят, я ведь так много насчитала.
На сколько лет часов я ошиблась?
По окончании работы на проекте я сравнила затраченные часы и увидела, что в запасе осталось ещё 26 часов. То есть мои расчёты оказались немного (немного ли?) преувеличены, учитывая даже риски, написание тестовой документации и то, что в это время вошло тестирование на iOS, которое не планировалось.
Какие ошибки допустила
🔻хотела зачем-то сделать всё красиво и пошла пытаться при оценке использовать формулы. В итоге, потратила время на то, чтобы перелопатить интернет, и понять, что формулы – это либо сложно в принципе, либо явно не для джуна с его мизерным опытом и паническими атаками от митов с аналитиком, менеджером и заказчиком
🔻 подготовительные мероприятия типа тестирования требований и самой оценки тестирования я не внесла НИКУДА (рукалицо, знаю). Фактически, я просто личное время потратила. А могла бы получить оплату за эти 4 дня…
🔻 поторопилась с ответом менеджеру. Возможно, стоило пересчитать. Хотя менеджер моим ответом осталась довольна – она явно ожидала, что ей придётся отвоёвывать у клиента больше.
Коммуникация и «мягкие навыки»
Делюсь с вами опытом и советами коллег QA (они разрешили)
Как продавать эстимации
Когда называешь эстимацию в 60 часов, часто слышишь: «Почему так много?» – и тут важно не мяться. Раскладывай: 20 часов на регрессию, 10 на exploratory, 5 на документацию и 25 – буфер с учётом прошлых проблем. Плюс в помощь визуализация в Confluence или Miro – помогает сразу «показать», что за этой цифрой стоит.
Если просят «урезать»
Когда менеджер просит сократить эстимацию, возвращай мяч: «Окей, что мы тогда выкидываем: сценарии авторизации или критичный путь оформления заказа?» Пусть решение будет взвешенным. Часто помогает честное обозначение рисков: «Срежем – тестировать будем не всё, баг может уйти в релиз».
Обратная связь и итерации
Эстимация – не надпись на граните. После первых дней тестирования нужно пересмотреть план. Особенно в проектах с живым кодом. Не редок случай, когда после двух дней тестирования выясняется: в новом модуле багов больше, чем думали. Эстимацию стоит пересчитать, и все примут это без скандалов, потому что диалог будет постоянным.
Как квантифицировать? Не сложно. Заведи правило: если есть больше трёх факторов риска, добавляй минимум 30% времени. Для проектов с высокой неопределённостью – до 50%. Можно использовать матрицу: вероятность × ущерб. Вес каждой категории суммируется, и ты получаешь обоснованный «плюс к оценке».
Буферы Всегда держи в голове: «10% — это на баги и кофе. 20% — на разногласия и конфигурации. 30%+ — на реальность». Буферы – это не запас, а отражение того, что проект всегда немного живёт своей жизнью.
Я знаю, что тут в основном люди опытные, но всё же…
Мини-чеклист
Как эстимировать, если проект нестандартный? Недавно я попробовала собрать для себя мини-чеклист, когда эстимация идёт не по классике (в духе «вот тебе 10 юзер-стори и 2 недели на спринт»), а по модели «тестировщик один, ТЗ странное, срок «вчера». Делюсь:
Такой самоопрос помогает не залипнуть в попытках «оценить правильно», а просто разложить задачу по полочкам и сделать реалистичную прикидку. Особенно если ты пока что один QA на борту.
Если вы впервые столкнулись с ЭсТИМацией,
…то первым делом – не паникуйте. Или ещё лучше – поставьте таймер на 15 минут и попаникуйте. А потом выключите таймер, выдохните и подумайте, где можно найти ответ/совет (спойлер – у коллег, куратора, в гугле, в этой статье немного тоже есть)…
А если ещё не сталкивались, но уже работаете QA, то, даже если вас не просят, перед тем, как приступить к задаче, навскидку прикиньте, сколько она может занять. Засеките время и, когда закроете таску и/или оформите по ней баги, отметьте, насколько вы были близки к реальному времени. Это очень поможет вам не только в эстимации, но и в элементарном планировании рабочего времени.
Если у вас есть лайфхаки по эстимации тестирования или другого процесса, делитесь, пожалуйста. Есть ощущение, что мой рассказ далеко не всё охватил.
Специалист по тестированию, контент-менеджер "Лаборатории качества". В IT с 2022 года. В журналистике с 2003 года. Работает в департаменте развития и производственном департаменте.
