Что такое оценка тестирования (Test Estimation)?

А, вот это тема, блядь! Оценка тестирования! Ну, хуй с ним, давай разберёмся, что это за зверь такой, а то потом все удивляются, почему сроки просрали, а тестировщики с горя на стенку лезут.

Test Estimation, ёпта, — это когда ты пытаешься угадать, сколько же времени, сил и нервных клеток тебе понадобится, чтобы всё это протестировать и не получить потом пизды за срыв релиза. Цель-то простая, как три копейки: спланировать, кто, что и когда делает, чтобы не было потом аврала, где все бегают, как угорелые, и кричат «всё пропало!».

Как это обычно делают, эти наши умники:

• Экспертная оценка: Это когда зовут какого-нибудь седого старпёра-тестировщика, который уже всё на свете видел. Он хмыкает, почесывает репу и изрекает: «Ну, тут, блядь, недели на две работы, не меньше». И все ему верят, потому что он уже столько проектов похоронил и воскресил, что ему можно.
• Декомпозиция (Work Breakdown Structure): Берешь эту громадную, страшную задачу «протестировать всё» и начинаешь её пилить на мелкие кусочки, как колбасу. Настроить среду? Окей. Написать тест-кейсы? Ясно. Прогнать эти кейсы? Ага. Написать отчёты? Ну конечно, блядь. Каждый кусочек оцениваешь отдельно, а потом складываешь — вроде логично, да?
• Метрики, ёбана: Тут уже начинается магия с цифрами. Смотришь в старые отчёты: «Ага, в прошлый раз мы в час по 1.5 тест-кейса делали в среднем (это velocity, если по-умному)». Берёшь эту цифру и пытаешься прикинуть на новую кучу работы. Главное — не забыть, что в прошлый раз у тебя среда не падала каждые два часа, а требования не менялись три раза в день.
• Planning Poker: А это вообще цирк, я тебе скажу. Собирается вся команда, раздают им карточки с какими-то ёбаными единицами сложности (стори-поинтами). Каждый тычет свою цифру, а потом начинается: «Почему у тебя 13, а у меня 5? Да ты глянь, какой там объём!». Спорят, ругаются, пока не придут к какому-то общему числу. Иногда полезно, иногда — просто трата времени, пиздец.

Ну и чтобы не быть голословным, вот тебе примерчик, как это в цифрах может выглядеть:

# Считаем, сколько нам надо времени на прогон этих тест-кейсов
test_cases_count = 100  # Сто штук, Карл!
average_time_per_case_hours = 0.75  # По 45 минут на каждый, если всё гладко (ха-ха)
environment_setup_hours = 8  # Настроить стенд, это ещё целый день
reporting_hours = 4  # А потом отчёты писать, это тоже время

# Считаем общую оценку
total_estimation_hours = (test_cases_count * average_time_per_case_hours) + environment_setup_hours + reporting_hours
# Итого: 100 * 0.75 + 8 + 4 = 87 часов. Вроде красиво.

А теперь, сука, самое важное — нюансы! Без них твоя красивая оценка накроется медным тазом на второй же день.

1. Риски, блядь! Их надо учитывать сразу, а не когда они уже наступили тебе на горло. Требования поменяются? Ещё как. Баги будут сложные, которые два дня дебажить? Обязательно. Среда testing'овая сдохнет в самый неподходящий момент? Да без вариантов! Закладывай на это время заранее.
2. Буфер, ёпта! Никогда, слышишь, НИКОГДА не давай итоговую цифру как есть. Накинь сверху ещё 20-30%, а то и больше. Это на те самые «внезапные хотелки», «непредвиденные обстоятельства» и просто на то, чтобы не сойти с ума. Это не обман, это — здравый смысл, ебать его в сраку.
3. Оценка — она живая! Это не каменная скрижаль, которую раз высекли и забыли. Жизнь течёт, проект меняется, задачи прибывают. Раз в неделю, а то и чаще, смотри на то, что насчитал, и корректируй. А то будет как в том анекдоте: «Мы уже полгода делаем двухнедельную задачу».

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