Техники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)

Оценка затрат на тестирование (test estimation): Рассчитанная аппроксимация результатов, связанных с различными аспектами тестирования (например, затраченные усилия, дата завершения, связанные затраты, число тестовых сценариев, и т.д.), результаты которой могут использоваться даже когда входные данные неполные, неопределенные или неточные. (ISTQB)

Test Estimation - это управленческая деятельность, которая приблизительно показывает, сколько времени и денег потребуется для выполнения задачи. Оценка усилий для теста (Estimating effort) является одной из основных и важных задач в управлении тестированием (Test Management).

Мы поговорим о планировании в прогнозирующих методологиях, потому что в них есть время попланировать до того, как проект начался. В гибких же методологиях все происходит «здесь и сейчас»: не только регулярный planning, но и initial planning, как правило, им занимается менеджмент. Это отдельная тема.

Если мы говорим о прогнозирующих методологиях, то здесь могут быть целые этапы, которые вы можете наблюдать на слайде. Вот, к примерe, первый этап - Incention - он может занимать до полугода. И это период, когда не программируют и толком не занимаются требованиями. Кто может согласиться на то, когда нам платят, а мы толком ничего не делаем? Это может быть военная, медицинская промышленность. Это могут быть глобальные проекты, от которых зависит жизнь людей, и период разработки примерно составляет от 2-ух до 5-7 лет. Обычно же на планирование уходит около 2-ух недель, но зачастую это просто «завтра».

Что такое планирование тестирования? Для тест-лида, это не только время, но и что, как и где тестировать.

Планирование тестирования:

  • Определение требований к тестам;

  • Оценка рисков;

  • Разработка стратегии тестирования;

  • Определение ресурсов;

  • Разработка Тест Плана;

  • Создание графика работ.

Каждый этот вопрос достоин рассмотрения. Но мы поговорим о маленьком пункте «Создание графика работ». Конечно, о тестирование можно просто сказать, но лучше показать и как-то формализовать свою аргументацию. Сейчас поговорим именно об этом. Конечно, планирование невозможно без оценки результатов - это и есть наша основная проблема.

«Мы не умеем оценивать!» - команда может вам заявить такое, что джуниор, что опытный специалист. Причину видят в отсутствие определенных методов. Это очень большое заблуждение. Методы есть:

Требующие детальной математической проработки:

Это математические методы, но я не видела ни одной компании, которая бы использовала их. Их основные минусы:

  • Они занимают много времени

  • Они трудоемкие

  • Они не дают результат.

Почему?

Потому что планирование должно быть гибким. Потому что сложно рассчитываемый план может нарушиться только из-за того, что кто-то не пришел или заболел. Пересчитывать? Вряд ли! Поэтому мы поговорим о методах, которыми вы уже пользуетесь, но не всегда осознаете!

Наиболее простые в использовании:

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

Мой любимый метод - структура декомпозиции работ. Это наименее трудоемкий, но формализованный метод для оценки. Что подразумевается? Вам нужно просто дробить вашу работу до той минимальной, которую очень легко оценить и даже учиться этому не нужно.

Например, протестировать авторизацию. Буква «о» не проходит - можно сходу сказать 5 мин для себя. Это минимальная единица. Такое может определить даже человек, который работает всего пару месяцев. Плюс в таком методе - вам сложнее что-то забыть.

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

Обратите внимание на диаграмму, здесь приведена статистика для сайтов от полугода - года. Программирование занимает от 20% до 40% разработки, это не тоже самое что 20-40% от проекта, это в среднем 15% от проекта. Тестирование никогда не занимает 15% от продукта. Если у вас не закладывают столько время для тестирования, то закладывайте хоть сколько-нибудь. Желательно выяснить статистически какой процент от проекта занимает тестирование и это применимо, если у вас стабильные версии релизов, постоянный объем продуктов один и тот же.

Решение проблемы:

  • Обучаем новичков:

    • Хронометраж;

    • Анализ.

  • Создаем универсальный Estimation Check List для портфеля проектов;

  • НЕ ругаем за ошибки в оценках.

Для этого не нужно ходить на тренинги, как-то же оцениваете, запишите свои оценки и посмотрите, сколько это заняло времени реально. Помогают разные трейлеры/приложения, которые помогают записывать время. Или примерно в днях запоминайте. Когда вы сами поймете, сможете научить свою команду. Очень важно, когда вы пытаетесь уговорить команду оценивать, очень важно не ругать ее за эти оценки. Чаще всего люди не хотят оценивать, потому что боятся, что вы можете к ним придраться. Пока не зафиксировано все, они вам ничего не должны.

Объясните своим сотрудникам, что любая неправильная оценка лучше чем ее отсутствие. Иначе вы как тест-лид не знаете ничего, не можете соотносить ресурсы и так далее. Хвалите, если они даже ошиблись. Скажите: «Ты ошибся в 2 раза. а я ошибся в 3!». Но ошибки не пропускайте, сядьте и сравните, сколько запланировано было, сколько времени потребовалось в реальности, где был big fail, и на что потребовалось больше всего времени. Самое важное - этот анализ, когда человек сам осознает, что он не учел. Тут как раз и нужна декомпозиция работ, чтобы ничего не забыть.

Тут нам может помочь - «незабудка для тестировщика».

  • Ознакомление/исследование;

  • Ревизия спецификации;

  • Написание тестовой документации (чек-лист, тест кейсы);

  • Подготовка данных;

  • Выполнение тестов + рекомендации от программистов;

  • Буфер/Риски.

Первое, что мы сделали повесили это каждому на рабочее место. Она подходит для оценки баги и оценки задач. Она верхнеуровневая и подходит для глобальных задач.

И вот это уже для тест-лидов и экспертов, которые оценивают очень большие задачи, особенно, когда до завтра нужно оценить проект из крупных 20 задач.

Вы не пойдете ко всем тестировщикам, вы пойдете к первому опытному и спросите: «Давайте оценим - сколько это займет». Такой Estimation чек-лист (чек-лист по оценке), чтобы ничего не забыть. Для каждого проекта он свой. Накидайте список всех видов и типов тестирования, которыми вы пользуетесь, потому учтите, на что вы тратите время - время на анализ требований, общение с клиентами, программистами, на документирование, создание тест-кейсов, тест-планов. А потом проставляйте в чек листе, что вам нужно и не нужно.

Следующая проблема - мы не хотим оценивать. Что делать с этими людьми, а вам очень нужно?

Сделайте все оценки сами и используйте их для планирования. Повышайте свои скилы + это интересно знать, насколько хорошо, вы можете прогнозировать. Смотрите на задачу и оценивайте, чем лучше вы оцениваете, тем важнее вы для вашего тест-лида. Удивите свою команду и покажите, что вы можете предсказать то, что команда не знает!

Давайте примем для себя, что планирование - это оптимальное распределение ресурсов, кроме оценки. Без оценки - планирование не имеет смысла.

Планирование - оптимальное распределение ресурсов для достижения поставленных целей, совокупность процессов, связанных с постановкой задач и действий в будущем. (с) Википедия.

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

Вы скажете, как я как тест-лид, отвечаю за финансы? Все очень просто. Если вы включите 4 тестировщика в проект, то зарплату надо платить четверым, если троим, то соответственно, меньше. Это банальный уровень, но вот если ваша компания заключает договора о штрафах за просроченный проект, то там финансовые показатели очень большие. Поэтому каждый из этих показателей влияет на время окончания проекта.

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

Тут нам поможет сетевой график работ и Диаграмма Ганта.

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

Есть теория графов - это метод прохождения пути с наиболее тяжелыми весами. В данном случае «весы» - это оценки. Путь состоит из работ.

Если аксимировать это на как управление проектами, то это будет набор задач от начала проекта до конца проекта, которые не имеет запаса по времени. Красненькое - это критический путь. Если вы нарушите сроки выполнения этих работ хоть на час, то релиз задержится на час, если на 2 дня, то значит на 2 дня задержится релиз. Зачем это нужно? Вам важно понимать какие задачи лежат на этом пути, потому что приходит к вам на середине пути тестировщик просит выходной, но оказывается он выполняет работу на критическом пути и от того, что его не было, релиз сдвинулся на 1 день. Метод Критического пути дает нам возможность предвидеть наступление таких критических работ, осознавать, что происходит в проекте.

Давайте опишем основные шаги, которые мы делаем для составления плана.

  • Решить, что будем тестировать;

  • Сделать оценки;

  • Заполнить сетевой график работ, построить Диаграмму Ганта;

  • Проставить логические связи между работами;

  • Назначить ресурсы;

  • Определить Критический путь;

  • Проставить ресурсные связи;

  • Оптимизировать ресурсы (количество исполнителей).

Это очень важно понять. Зачастую именно такой график позволяет понять взаимосвязь ресурсов и невозможность выполнения 400 часового плана сотней тестировщиков за 4 часа. Время тратится на подготовку данных, изучение проекта, анализ требований, общения с программистами.

Все ли мы учли? Если нет, то что осталось и где это учитывать? Не забываем:

  • Отпуска, праздники;

  • Баги

    • Время на заведение;

    • Время на регрессию;

    • Статистическое приближение;

  • Буфер

    • На задачу или проект?

    • %?

  • Риски;

  • Исполнители;

    • Разделение;

    • Опыт;

  • Если версия не первая;

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

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

Те, кто уже планирует, обратите внимание, что нельзя применять Диаграмму Ганта для группы проектов, если у вас общие ресурсы.

Если у вас общий архитектор, и он нужен на все проекты, то такое может не сработать.

Его преимущества, когда у вас ресурсы не пересекаются сразу во всех проектах. Их много, так вы можете управлять своими ресурсами, понимать, где они находятся. Но вам важно, имеет ли это смысл для вашей компании.

Преимущества:

  • Позволяет рассчитать стоимость и сроки проекта, основываясь на численных оценках;

  • Дает представление о занятости ресурсов;

  • Позволяет эффективнее распределять ресурсы между проектами;

  • Инструмент оптимизации сроков проекта;

  • Является наглядными документами для руководства и заказчика;

  • Если заказчик заинтересован в использовании наглядных графиков, то вы можете говорить о том, что так вам легче соблюдать обязательства перед ним, у вас будет четкий аргумент.

Если заказчик заинтересован:

  • Соблюдаем обязательства;

  • Не приносим убытки;

  • Расширяем возможности;

  • Не экономим на качестве;

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

Если заказчик НЕ заинтересован:

  • Сохраняем нервы Лида;

  • Развиваем свою команду;

  • Внедряем фишечки;

  • Разрабатываем свои инициативы;

  • Получаем удовольствие от качества;

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

Нужно очень четко это контролировать. Сколько по времени занимает модификация этого плана? Это гибкий план, поэтому изменения должны производиться раз в неделю. Если это автоматизировано, то ваше время будет уходить только на оптимизацию. В компаниях, где этот процесс не автоматизирован, выясняют один вопрос: «Сколько времени осталось на задачу?». Им не интересно, что помешало, важно сколько времени осталось, и как поменять план. Следовательно, если у вас 20 тестировщиков, то придется менять 20 строк.

Ну и выводы:

  • Планирование - совокупность процессов по:

    • Созданию стратегии тестирования;

    • Оценки трудозатрат;

    • Прогнозированию сроков;

    • Назначению и оптимизации ресурсов;

    • Контролю выполнения задач;

  • Оценка трудозатрат и оценка сроков - не одно и тоже;

  • Большинство этапов можно автоматизировать.

Планирование это здорово, так как все можно автоматизировать, помните, что планирование сроков и оценка трудозатрат не одно и то же.

Источники:

Доп. материал:

PreviousПроцесс тестирования (test process) (draft)NextЭкономика тестирования/стоимость качества (Cost of quality)

Last updated