Как оценить время на тестирование

+ (TCbase + TCnew) x TCa + TCchng

Сколько всего времени тогда занимает тестирование, мы видим в формулах внизу таблицу — в них все понятно и без комментариев.

Случай 2: «Вот кусок функционала, сколько времени уйдет на тестирование?»

Сколько времени уйдет на тестирование той или иной части функционала? Чтобы это прикинуть, есть разные способы:

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

Случай 3: «Почему вы ничего не успеваете?!»

Следующий, весьма распространенный вопрос, который задают тестировщикам: «а что это вы вообще делаете, почему вы ничего не успеваете, почему вам нужно помогать с автоматизацией, почему вы не хотите, чтобы мы каждый день выпускали новые версии — ведь багов-то новых нету. »

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

Пример такой таблицы:

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

Получили загрузку в часах по дням. И если получается, что каждый день нужно 24 часа тестирования, а у нас всего два человека… Значит, однозначно нужен третий тестировщик!

Случай 4.1: «Выпускаем сборку в пятницу, а то и раньше — так сколько вам нужно времени на тестирование»?

В таком случае процесс тестирования строится так:

Тесты на полную регрессию по платформам проводятся в этом случае следующим образом (Cr, FF и т. д. здесь — разные платформы, в данном случае — браузеры):

Источник

Тестирование ПО

Алгоритм оценки времени на тестирование

Оценка времени на работу – сложная задача и многое тут зависит от опыта. Однако, используя необходимые принципы и подходы можно оценить (хотя бы приблизительно) время на выполнение даже новой и неизвестной задачи. Существует множество различных методов оценки от применения математических моделей до комбинирования мнений экспертов. В этой статье я опишу алгоритм оценки, который сформирован на моем опыте работы в QA.

Предлагаю следующий алгоритм для оценки трудозатрат на тестирование ПО:

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

2. Определить среднее время на разработку и выполнение 1 теста

3. Определить количество возможных ошибок и время на работу с 1 дефектом

4. Учесть возможные дополнительные затраты времени и риски

5. Получить суммарную оценку, с учетом предыдущих шагов

Далее рассмотрим каждый шаг подробно. При этом в качестве примера возьмем функциональность, для которой по алгоритму будем определять время на тестирование. В качестве функционала рассмотрим простую web форму со строкой ввода, которая позволяет складывать 2 числа:

Требования к системе следующие:

а) Должны суммироваться 2 числа от 0 до 100

б) Для сложения между числами необходимо ввести знак «+»

в) Результат сложения должен отображаться под строкой ввода после нажатия «Calculate»

г) При некорректном вводе и попытке вычисления, под строкой ввода должно появляться сообщение «Ошибка вычисления»

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

Проведем оценку времени на тестирования для нашего примера:

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

Итак, начнем с анализа и декомпозиции требований. Как это обычно бывает, не все требования явно прописаны в ТЗ, определенная часть условий будет являться следствием перечисленных. Что в итоге мы фактически должны проверить? Ниже я сразу буду указывать краткое описание, какие требования мы проверяем, какие для этого использует тесты и количество необходимых тестов:

2. Определить среднее время на разработку и выполнение 1 теста

Количество тестов мы получили, теперь нужно определить сколько времени потребуется на то чтобы:

б) Выполнить проверку по тест-кейсу

3. Определить количество возможных ошибок и время на работу с 1 дефектом.

На этом этапе нам необходимо спрогнозировать:

а) С каким примерно количеством ошибок мы можем столкнуться

б) Сколько времени необходимо на регистрацию дефекта

в) Сколько времени уйдет на проверку исправлений

4. Учесть возможные дополнительные затраты времени и риски

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

Допустим, что для нашего примера мы заложили следующее дополнительное время:

Итого, получаем дополнительно 24*3=72 минуты

5. Получить суммарную оценку, с учетом предыдущих шагов

Итак, теперь посмотрим, какие оценки у нас получились на каждом шаге:

В сумме получается: 480+1920+100+200+72=2772 минуты или 46 часов. При этом к общей сумме уже можно не прибавлять какие-то дополнительные риски, т.к. мы их учли на отдельных шагах.

Вот так на проработку простейшего функционала запланирована целая рабочая неделя! Хотя на первый взгляд и может показаться, что работы там максимум на 1 час. Но когда мы приступим к реальной задаче, начнем прорабатывать требования, оформлять тест-кейсы и дефекты, станет очевидно, что оценка в 46 часов гораздо ближе к действительности.

Источник

Оценка сроков на разработку и тестирование задачи (не нужна)

Я в тестировании 12 лет, работал в Naumen и Яндексе. Сейчас руковожу отделом тестирования из 150 человек в Контуре и продолжаю работать тестировщиком в одной из команд.

После полугодовых performance review менеджеры из разных команд рассказали, какие цели поставили своим тестировщикам. У каждого пятого была такая: «Научиться оценивать сроки на тестирование задач». Часто такой «оценки сроков» хотят не только от тестировщиков, но и от разработчиков.

Оценка сроков в 95 % случаев. Спасибо, xkcd.

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

Сейчас объясню, как это работает.

О трудах классиков

Максим Дорофеев — Эффект выпрямления сроков

Цитирую по книжке «Джедайские техники», хотя можно было и закон Паркинсона процитировать:

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

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

Задача начинает «дымиться», и мы приступаем к ней. Если ничего не случилось, то мы успеваем вовремя, а вот если что-то случилось… Резерв мы на это «что-то» уже потратили и в итоге опаздываем.

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

Человек как выпрямитель (и диод) — иллюстрация из «Джедайских техник». Видео тоже есть.

Том Демарко — Человеческий фактор

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

Коротко: сам факт оценки влияет на сроки в худшую сторону примерно на 40 %.

Рекомендую прочесть. Все факторы, перечисленные в пятой главе, релевантны до сих пор.

Деминг и Нив — Эксперимент с красными бусинами

За последний год я дважды слышал от менеджеров: «Мы научились выдерживать сроки по оценкам задач, теперь такой-то программист или тестировщик совсем не нарушает сроки, которые назвал».

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

Упомянутые в заголовке авторы говорят, что единственно верный способ оценки сроков — статистический. Должен оцениваться пакет типовых задач. «У нас все задачи разные»? Это ложь. На промежутке в год будет уже не очень много разных задач. Как правило, такое заявление является признаком отсутствия рефлексии над процессом и невыполнения упражнений: декомпозиция, MVP, прототипы, стандартизация.

О заказчиках, которые требуют сроки

Во-первых, надо заметить, что чаще всего — и это само по себе забавно — от ответа исполнителя не зависит ничего, потому что сроки уже есть. Менеджер интересуется не сколько времени мы будем делать задачу, а успеем ли мы к заданному сроку и что именно успеем. Это разные вопросы и отвечать на них нужно по-разному.

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

Ещё раз: оценка сроков мешает исполнителю успеть к дедлайну.

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

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

О некомпетентных менеджерах

Очень легко перепутать оценку сроков (когда задача будет сделана) и оценку трудозатрат (сколько нужно времени, чтобы разработать фичу). Оценка сроков, как мы уже разобрались, если не вредна, то по крайней мере бессмысленна. А вот оценка трудозатрат — довольно полезное упражнение.

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

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

Пример из жизни:
— Сколько времени ты потратишь на эту фичу?
— Полторы недели буду писать и дня три фиксить баги.
— То есть через 3-4 недели будет готово?

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

Ты учишь жизни, а чего добился сам?

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

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

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

Большие задачи помечены тегом «проект», и по ним сразу понятно, что просто не будет. У каждой большой задачи есть фича-лид, задача которого — сделать так, чтоб были проделаны упражнения из списка выше.

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

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

В последний раз я задерживался на работе по просьбе менеджера, чтобы выпустить срочную задачу, больше двух лет назад. До этого пару раз, в 2015 и в 2016 году.

P.S. Один из наиболее важных навыков в нашей работе — не делать ненужной херни. В том числе не заниматься «оценкой сроков» и самообманом. Чего и вам желаю.

(Подпишитесь на наш канал в Телеграме, там неплохо.)

Источник

• ← Как оценить время восстановления системы
• Как оценить вычислительную сложность алгоритма →