Когда на новом проекте менеджер попросила меня провести эстимацию тестирования, я сначала растерялась, ведь это вроде как задача менеджера или старшего тестировщика. А потом вспомнила, что я – единственный тестировщик на проекте. И понеслось…

☑ Что случилось?

☑ Немного о методах эстимации

☑ Что у меня получилось?

☑ На сколько <лет>часов я ошиблась?

☑ Какие ошибки я допустила

☑ Если вы впервые столкнулись с ЭсТИМацией

Что случилось?

Вспомнила я об этой истории недавно, когда помогала сориентироваться в теме молодой коллеге. Она попала в подобную ситуацию – приложение с нуля, маленькая команда, один QA, есть ТЗ и больше ничего, клиент желает выйти в прод через 3 месяца. Она паникует и не понимает, с чего начать.

Сейчас я спокойно предложила коллеге выдохнуть. Но вот тогда, несколько лет назад, я сама знатно стрессанула, когда поняла, что теория и практика – опять (вот сюрприз!) расходятся. Учить определение и рассказывать о методах эстимации на собеседовании – это одно. Но оценивать задачи на реальном проекте, да ещё когда ты там сам себе старший и младший тестировщик, да ещё впервые – это, знаете ли, для неокрепшей психики новичка такое себе.

Как я уже сказала, проект был небольшой. Мы разрабатывали мобильное приложение онлайн-консультаций для медицинской сферы. У клиента уже был сайт, он просто хотел стать "мобильнее". Ещё до официального начала работы менеджер попросила меня оценить задачи, точнее, время на тестирование. Ей нужны были цифры для того, чтобы обосновать бюджет и количество часов работы QA.

Из плюсов – у меня были требования.

Из минусов – не было ничего, кроме требований. Тестовую документацию предстояло тоже писать самой.

Немножко о методах эстимации

Методы можно найти в сети разные, я приведу только те, что чаще всего встречались мне

Декомпозиция. Когда мы делим задачу на более мелкие подзадачи и так до той самой, которую уже можно легко оценить. Это я люблю. С наличием требований удалось вообще быстро разобраться и применить.

Оценка по 3 точкам. Используем три варианта: оптимистичный, наиболее вероятный и худший. И потом используем для подсчёта формулу:

где 6 – это стандартное отклонение. Сложновато – первые три варианта тоже надо откуда-то взять. Я скипнула этот метод.

Метод Дельфи. Тут нужна группа экспертов, которая соберётся, заполнит анкеты или сразу всё обсудит и вынесет вердикт, придя к консенсусу. Ну где ж их взять чаще всего, если надо ответить "ещё вчера"?:)) Тоже мимо.

Процентное отношение к разработке. Достаточно популярный метод. Берём время разработки и в зависимости от количества тестировщиков и разработчиков на проекте, умножаем время разработки на процент. Если на два разработчика один тестировщик, время на 0,5 умножаем. Для меня разницы никакой, так как о сроках на разработку мне всё равно не сказали.

UPD Некоторые эксперты мне написали в ЛС, что обычно 60% от разработки берут. Или 80%, если с рисками.

А как у вас?

Опыт. Полезный метод. Очевидный, как то, что…да как что угодно. Я, конечно, использовала.

Метод Пальцем в небо. Как ни странно, он так и называется. Хотя, как по мне, то если в начале работы сразу пытаться использовать умные формулы вышеуказанных методов, то примерно ПВН и получается, потому что ты совершенно не понимаешь, как эти штуки применить без опыта.

Что у меня получилось

Повторюсь – мне очень повезло, что я пришла на проект с готовыми требованиями. Была чётко оформленная документация и аналитик на связи. Мне предоставили время для ознакомления с требованиями (хотя фактически это оказалось тестированием требований) и составления плана тестирования.

Итак, ДО начала проекта я:

ツ провела тестирование требований, после чего аналитик внёс несколько изменений и можно было начинать работу;

ツ выбрала (не сразу, к сожалению) оптимальный для себя метод оценки времени на тестирование, совместив три в одном: опыт+сама себе эксперт+декомпозиция;

ツ нашла и установила на свой смартфон приложение, в котором были схожие функции с нашим приложением, по некоторым у меня не было опыта тестирования тогда;

ツ исходя из количества тестовых сценариев в требованиях, набросала примерное количество проверок (позитивных и негативных) на каждую задачу, максимально декомпозировала; 

ツ умножила количество тестов на примерное время прохождения тест-кейса. Притом не выводила среднее арифметическое, а отдельно считала явно быстрые прохождения и то, что может занять больше времени;

ツ в риски я заложила 30%.

Цифра, которую я трясущимися руками напечатала менеджеру – 110 часов. Мне казалось, сейчас меня сразу уволят, я ведь так много насчитала. 

На сколько <лет>часов я ошиблась?

По окончании работы на проекте я сравнила затраченные часы и увидела, что в запасе осталось ещё 26 часов. То есть мои расчёты оказались немного(немного ли?) преувеличены, учитывая даже риски, написание тестовой документации и то, что в это время вошло тестирование на iOS, которое не планировалось.

Какие ошибки я допустила:

– хотела зачем-то сделать всё красиво и пошла пытаться при оценке использовать формулы. В итоге, потратила время на то, чтобы перелопатить интернет, и понять, что формулы – это либо сложно в принципе, либо явно не для джуна с его мизерным опытом и паническими атаками от митов с аналитиком, менеджером и заказчиком

– подготовительные мероприятия типа тестирования требований и самой оценки тестирования я не внесла НИКУДА (рукалицо, знаю). Фактически, я просто личное время потратила. А могла бы получить оплату за эти 4 дня…

– поторопилась с ответом менеджеру. Возможно, стоило пересчитать. Хотя менеджер моим ответом осталась довольна – она явно ожидала, что ей придётся отвоёвывать у клиента больше.

Я знаю, что тут в основном люди опытные, но всё же. 

Если вы впервые столкнулись с ЭсТИМацией,

…то первым делом – не паникуйте. Или ещё лучше – поставьте таймер на 15 минут и попаникуйте. А потом выключите таймер, выдохните и подумайте, где можно найти ответ/совет (спойлер – у коллег, куратора, в гугле, в этой статье немного тоже есть)…

А если ещё не сталкивались, но уже работаете QA, то, даже если вас не просят, перед тем, как приступить к задаче, навскидку прикиньте, сколько она может занять. Засеките время и, когда закроете таску и/или оформите по ней баги, отметьте, насколько вы были близки к реальному времени. Это очень поможет вам не только в эстимации, но и в элементарном планировании рабочего времени.

Если у вас есть лайфхаки по эстимации тестирования или другого процесса, поделитесь, пожалуйста, в комментариях. Есть ощущение, что мой рассказ далеко не всё охватил. Мария, специалист по тестированию ЛК.

_{Будем рады вашим вопросам/отзывам/замечаниям. Мы с командой QA хотим писать интересно и полезно о том, что умеем.}