⏳ Эстимация в тестировании. Шпаргалка QA-инженера

Вы тестировщик. Вам дают задачу и спрашивают: "Сколько времени займёт тестирование?" Если вы растерялись или назвали "на глаз" то эта шпаргалка для вас.

Что такое эстимация?
Эстимация это оценка времени, усилий или ресурсов, необходимых для выполнения задачи.

🎯 Цель: спрогнозировать сроки с учётом реалий проекта, не быть вечно "в тестировании" и не торопиться в ущерб качеству.

Виды эстимации:
▫️Грубая (Rough Estimate): ещё нет деталей, называют вилку: 3–5 дней, неделя и т.д.
▫️Точная (Detailed Estimate): задача проработана, можно оценить каждую часть.
▫️Оценка на основе опыта (Expert Judgment): делается вручную, с опорой на прошлые задачи.
▫️Planning Poker / Wideband Delphi: командные методы, где оценки обсуждаются коллективно.

Что влияет на эстимацию?
▫️Объём и сложность фичи
▫️Доступность тестовой среды
▫️Готовность документации
▫️Время на регрессию
▫️Количество поддерживаемых платформ
▫️Интеграции с другими сервисами
▫️Риски и неопределённость
Не забывайте про багфиксы и ретесты!

Формулы и техники:

Three-Point Estimate (PERT)
Это метод оценки задач, основанный на трёх сценариях:
▫️(Optimistic) оптимистичная оценка: если всё пойдёт идеально, сколько займёт времени?
▫️(Most likely) наиболее вероятная оценка: сколько времени займёт задача при обычных условиях?
▫️(Pessimistic) пессимистичная оценка: если всё будет плохо (баги, блокеры), сколько максимум может занять?
Формула:

(O + 4×M + P) / 6

То есть, основное влияние оказывает реалистичная оценка, но риски и удача тоже учитываются.

Пример:
Вы оцениваете задачу по тестированию фильтра товаров.
▫️(оптимистично) = 2 часа
▫️(наиболее вероятно) = 4 часа
▫️(пессимистично) = 10 часов
Estimation = (2 + 4×4 + 10) / 6 = (2 + 16 + 10) / 6 = 28 / 6 ≈ 4.67 часа

Когда использовать PERT?
▫️Когда много неопределённостей
▫️Когда нет достаточной статистики из прошлого
▫️Когда задача может зависеть от сторонних факторов (дизайн, API, баги и т.д.)

Work Breakdown Structure (WBS):
Разбиваем задачу на подзадачи → оцениваем каждую → суммируем.

Buffer (буфер):
Добавьте 15–25% времени на непредвиденные задачи, если это допустимо проектом.

Как улучшить эстимацию?
▫️Делайте разбор задачи и не оценивайте "вслепую"
▫️Уточняйте требования и тест-кейсы
▫️Учитывайте риски: нестабильность билда, баги, блокеры
▫️Ведите учёт времени и он пригодится для будущих оценок
▫️Общайтесь с командой: Dev, PM, дизайнеры, BA
▫️Документируйте свою эстимацию: что учитывали, чего нет и почему

Что НЕ стоит делать:
▫️Давать оценку, не прочитав задачу
▫️Согласовываться на словах, лучше фиксируйте эстимейт письменно
▫️Обещать закончить быстрее "на всякий случай"
▫️Игнорировать командные дедлайны и приоритеты

💬 Ваша эстимация это прогноз на основе текущей информации. И как любой прогноз, он может меняться.

Насколько этично и допустимо обсуждать свою ЗП, как думаете?

Как правильно отчитываться на дейли-митингах / стендапах / летучках?
Источник: Максим Азаров, Software Testing QA Lead в SAM Solutions

За много лет работы я заметил одну и ту же особенность в командах.

Есть категория людей, которые не любят долго распинаться, предпочитают говорить минимум и в общем предпочитают не отсвечивать. От них обычно слышно что-то типа «Я на автоматизации», или «Я баг проверяю», или «Я стори делаю» и всё. Ни рассказа о находках и преодолённых трудностях, ни эстимейтов, когда закончит, ни любых других интересных или познавательных деталей. Всю остальную информацию приходится вытягивать клещами и наводящими вопросами.

Есть другая категория людей, которые, наоборот, любят говорить долго, погружают всех окружающих в кучу технических деталей, рассказывают свои мысли, о том, как они думали, какие решения принимали, где ошиблись, а где, наоборот, придумали гениальные решения. Так минут на 10–15. Эти товарищи часто очень обижаются, если их прерывают и просят сформулировать статус в 2–3 предложениях. И тут обратная ситуация: идёт перегруз информацией, и человек вне контекста очень быстро теряет смысл происходящего, а у человека, собирающего статус и оценивающего общую ситуацию на проекте, начинает кипеть мозг от лишней информации.

Так нужен ли на самом деле алгоритм? И для кого на самом деле эти митинги? Для менеджера, чтобы собрать статус, или для членов команды, чтобы понимать, что вообще происходит и кто что делает на проекте?

Короткий ответ: Митинг этот для всей команды, но с разными целями для разных ролей.

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

Для менеджера / тимлида / скрам-мастера это:
а) Сбор статуса: получить общее представление о прогрессе.
б) Выявление рисков: увидеть препятствия, которые мешают команде, и оперативно их устранить.
в) Оценка нагрузки: понять, всё ли по плану или нужны корректировки.

Главная ошибка здесь - считать, что дейли - это просто отчёт менеджеру. Это время синхронизации команды, которую организует менеджер / скрам-мастер.

Предположительно правильный алгоритм отчёта должен укладываться в 3-4 предложения и длиться не более 1-2 минут. Он должен содержать ответы на три ключевых вопроса:
1. Что я сделал вчера? (По отношению к цели спринта)
2. Что я планирую сделать сегодня? (Опять же, для движения по задачам)
3. С какими трудностями столкнулся? (Блокеры, риски, вопросы)

Плохо: «Я кодил, потом тестил, потом ещё покодил».

Хорошо: «Вчера я завершил разработку API для модуля платежей и написал для него юнит-тесты. Сегодня планирую начать интеграцию с банковским шлюзом. Пока блокеров нет».

А как это работает в ваших командах ?

Как перейти от монолита к микросервисам без лишнего риска?

🎥 6 октября в 20:00 МСК на открытом уроке разберём практические подходы к переходу от монолита на микросервисы: как определить границы сервисов, выбрать стратегию миграции и не остановить разработку.

На примере покажем, как работать со strangler pattern, декомпозировать систему по доменам, организовать работу с данными и транзакциями и избежать главной ловушки «распределённого монолита».

🔔 Урок проходит в преддверии старта курса «Микросервисная архитектура» и будет полезен backend-разработчикам, архитекторам, техлидам и DevOps-инженерам, которые работают с большими системами и планируют их эволюцию.

Зарегистрируйтесь и разберитесь, как переходить от монолита к микросервисам поэтапно без остановки бизнеса и дорогих архитектурных ошибок: https://vk.cc/d2ezcC

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Когда щедрость компании не знает границ.

Это база! Рассказываю о бесплатных функциях Google Календаря, которые упростят вашу жизнь

Google-календарь — это не просто место, где удобно записывать личные и рабочие дела. А ещё и мощный инструмент, который упростит вашу жизнь. Поделюсь моими любимыми функциями.

Читать

Что думаете по поводу таких моментов на собеседованиях?

Если вам интересна работа с данными, попробуйте освоить Python для анализа данных.

Получить данные через API, разобраться в большой таблице, объединить информацию из разных источников и построить наглядный график. Python помогает выполнять такие задачи и автоматизировать повторяющиеся действия.

На курсе «Язык программирования Python для анализа данных» Факультета компьютерных наук НИУ ВШЭ вы начнёте с основ языка и постепенно перейдёте к работе с данными.

Что вы научитесь делать:
🔹 Получать данные через API
🔹 Обрабатывать и анализировать данные с помощью pandas
🔹 Работать с SQL и базами данных
🔹 Визуализировать результаты

Опыт программирования не нужен: вы начнёте изучать Python с нуля.

📅 Старт 14 октября
💻 Онлайн
⏳ 9 недель

→Подробнее о программе

Так или иначе провёл время с пользой.