Расчет трудозатрат тестировщиком

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

Есть ли какой-то шаблон и алгоритм подсчета трудозатрат для тестирования того или иного функционала? Что необходимо учитывать, а что нет ?

Я всегда думала, что этим занимается руководитель проектов. Но тут попросили меня, тестировщика, оценить свои приблизительные трудозатраты (наперед).
Буду благодарна за Вашу помощь, т.к. я даже не знаю с чего начать, чтобы потому не вышло так, что я рассчитывала на 15 часов, а вышло 115 часов.

С уважением.

Добрый день.
Я обычно делаю следующие шаги:
1. Как можно более подробно выясняю скоуп предстоящего проекта, т.е. что именно нам предлагают тестировать – интерфейс, какая функциональность, нужно ли нагрузочное тестирование, нужно ли тестирование юзабилити, нужно ли учитывать регрессионное тестирование других модулей. Эту информацию обычно можно собрать у руководителя проекта, технического менеджера либо архитектора, если он есть на проекте.
2. Выясняю с тех менеджером, сколько времени они планируют потратить на разработку. Есть формула время на тестирование нового функционала это примерно 0,7 времени на разработку этого самого функционала. Но это если совсем новое и не понятно вообще как это оценивать.
3. Если есть возможность, выясняю с коллегами QA на соседних проектах, занимались ли они чем нибудь подобным (использовали те же модули либо продукты) и если да, то сколько времени у них ушло на тестирование.
4. Пытаюсь как можно полнее описать условия, при которых моя оценка будет валидной. Т.е. например, если сильно изменятся требования, то оценки надо будет однозначно персчитывать. Также делаю пометку о том, что после получения готового дизайна оценки на тестирования опять же могут измениться.
5. Предусматриваю время на создание кейсов, установку серверов.

С уважением

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

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

Лучше пусть вы сдадите отчеты ранее чем позднее.
Хотя в моем случае это чаще всего буквально один-в-один получается.

Но это мое мнение. Я с удовольствием сама послушаю еще варианты по данной теме.

Кстати - на данном форуме посмотрите списки тренингов, там есть данная тематика, может стоит посетить?

Я всегда думала, что этим занимается руководитель проектов. Но тут попросили меня, тестировщика, оценить свои приблизительные трудозатраты (наперед).

По хорошему, этим должен заниматься руководитель тестирования. Часто, руководитель проекта назначает цифры от балды, а потом на тестирование "не хвает" времени. Так что радуйтесь.

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

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

Есть ли какой-то шаблон и алгоритм подсчета трудозатрат для тестирования того или иного функционала? Что необходимо учитывать, а что нет ?

Я всегда думала, что этим занимается руководитель проектов. Но тут попросили меня, тестировщика, оценить свои приблизительные трудозатраты (наперед).
Буду благодарна за Вашу помощь, т.к. я даже не знаю с чего начать, чтобы потому не вышло так, что я рассчитывала на 15 часов, а вышло 115 часов.

С уважением.

Мое мнение, что тестировщик не может назвать цифру не обладая даром предсказания. Во-первых, почитайте здесь и можно попробовать дать почитать начальству
http://software-test...-taking-so-long
то есть время затраченное на тестирование очень сильно зависит от разработчиков и от того сколько ошибок они сделали

Во-вторых, бывают дефекты blocker - то есть делающие невозможных или крайне медленным дальнейшее тестирование. Таким образом тестировщик зачастую сидит и плюет в потолок пока программист что-то фиксит "по быстрому". Появление таких дефектов и время на их фикс предсказать заранее невозможно. Еще хотелось бы добавить, что программист может фиксить такие дефекты очень и очень неторопливо :) все зависит от человека и как он относится к работе.

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

В-четвертых, на сколько "старый" код, требуется ли тестирование регрессии.

В-пятых, в-шестых, в-седьмых...

В общем какие-либо оценки можно попытаться сделать исходя из предыдущего опыта работы на подобном проекте с теми же самыми разработчиками. Если такого опыта нет, то можно попробовать взять время затраченное на разработку и фикс багов и поделить на два. Но тут проблема, разработчики часто (я бы даже сказала чаще всего) сами не могут дать внятных оценок и оценивают задачу в 40 часов, а реально получается 400. При таком раскладе, может быть, ваше начальство не поймет, что оценка на тестирование уже не 20, а превращается 200 часов.

Считаю время из следующих критериев:
0,7 трудоемкости разработки (так считаю в общем, не я, а руководитель)
1 обычный тест - минимум 15 минут, но лучше 20 минут, даже если он такой - Ткнуть в кнопку, проверить, что появилось сообщение "Hello World", было время считал что каждый тест = 10 минут, но это не работает.
1 тест на безопасность, нагрузочный тест - минимум 1 час, нагрузочный тест - отдельная история, весь план может быть из 3-4-х тестов и длиться неделю.
Администрирование, общение с разработчками, ... - минимум 1 час в день.

Обычно руководитель говорит так - надо протестировать к 5-му числу, то есть до пятого числа есть ещё 23 рабочих дня. А продукт выйдет через 7 рабочих дней. Вот 7 дней на подготовку, а потом тестирование. И тут можно планировать по разному, лучше планировать на двоих. В одиночку мало что можно успеть.

Выделяются фунциональные тесты - для меня это такие важные тесты, которые не зависят от тестового окружения, и которые надо точно сделать. Эти функциональные тесты (по 15 минут минимум на штуку) делятся между двумя людьми. В день можно выполнить 10-20 тестов (зависит от глючности продукта). Если продукт нерабочий, то сидеть и плевать в потолок нельзя. Всегда есть режим работы, при котором продукт работает, или подаёт надежды. Поэтому отладчик, профайлер, прокси сервер, снифер в руки и пробуем понять почему не работает и как сделать так, чтобы заработало. Вчитываемся в логи, в журналы ошибок, или находим причину и помогаем её устранить или пишем статью для клиентов - причиной такой ошибки может быть такая-то настройка. Не сидим.

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

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

Потом прикидываем какие тесты можно успеть к оговоренной дате, как павило тесты писать просто и они пишутся в огромном количестве с высокой скоростью. При написании тестов не надо сильно задумываться, это мешает и тормозит процесс. Читаешь ту документацию, что есть, и пишешь по ней тесты. Даже если эти тесты неосновные и кажутся необязательными, их надо записать и выполнить. При их выполнении (а у нас же есть 15-20% на свободный поиск) будет сделан шаг вправо, шаг влево, тут и будут найдены другие дефекты. Тесты пишу в офисном документе, потом структура тестов переносится в систему управления тестами.

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

На один план тестирования надо планировать не более 200-х тестов. Лично я не могу выполнить более 200-х тестов (цифра условная). Видел как начинающие тестировщики (тестировщицы) писали проекты тестов на 15-20 листов, в которых было 500 и более тестов. И они говорили - тесты простые, на каждый уйдет по 5 минут, успеем. Ни разу не успевали, план затягивался, актуализировался. Да и само проектирование 500 тестов, это непросто. А уж если при выполнении теста номер 20 выяснится, что следующие 40 тестов блокируются, то будет весело. Поэтому планируйте 100 тестов максимум, если тестируете в одиночку - можно меньше, больше не стоит. Тогда Вы сможете завершить план за 2 недели. План на 50 тестов (хороших тестов, с бизнес логикой и хорошим ожидаемым результатом) легко завершить за неделю.

Не планируйте себя и других исполнителей с 100% занятостью, то есть по 8-9 часов в сутки. Планируйте работать с 70%-80% занятностью. Всегда может выясниться, что вышла новая специальная версия, что партнёры разработали некий коннектор - что появилось нечто, требующее немедленного тестирования. И если занятость на плане 70%, это нечто можно успеть хотя бы запустить на 1-2 стендах и проверить соответствует ли оно своему описанию. Сотрудников студентов планируйте с 60% занятостью, им надо учиться, до вечера они сидеть на работе не могут.

Если разработчик - новичок, то добавьте 20% к повторному тестированию. Так как он может многое недоделать, решив что успеет это сделать на поддержке тестирования. То есть на тестирование пойдёт альфа-версия, которая лишь к моменту проверки исправлений по замечаниям будет стабильной. Из-за этого длительность и важность этапа проверки исправлений возрастает. Само повторное тестирование занимает минимум 30% от основного (зависит от ожидаемого количествоа дефектов и от доделанности начальной версии продукта), максимум - думаю 50% от времени тестирования.

Итак
Весь план тестирования - 70% трудоемкости разработки (если 4 разработчика разрабатывали продукт 50 дней, а тестировать надо в одиночку, то трудоемкость = 70% от 4*8*50 = 1120 часов или 140 дней, что-то много, надо сокращать или звать на помощь коллег, в одиночку не справиться)
Подготовка к тестированию - 2-5 дней (смотря когда скажут, можно готовиться и дольше, если время есть)
Тестирование - минимум 15 минут на тест, планируемая загрузка - 80% в день, для студентов - 60% (но можно и 100% планировать, иногда, очень редко), много тестов планировать не надо, конфигурацонное тестирование - это 10% простых тестов, которые могут показать какие-то особенности на неосновных стендах; тестирование безопасности, нагрузочное тестирование - минимум 1 час на тест.
Повторное тестирование - 30-50% от основного тестирования (если не было приёмочного тестирования и на тестирование передали альфа-версию, то точно получится 50% от основного + весь запас 15-20% будет использован).
Запас - +15-20%.
Прочее (отчеты, администрирование, ...) - +5-10%.

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

Эти цифры написал из опыта последнего плана тестирования, а не из общего опыта. Общие цифры я не знаю, учёт не веду. Поэтому данные цифры могут быть неточными. Если кто-то узнал в этих цифрах что-то знакомое, то, возможно, мы - коллеги и сидим в одном кабинете ).

Считаю время из следующих критериев:
0,7 трудоемкости разработки (так считаю в общем, не я, а руководитель)
1 обычный тест - минимум 15 минут, но лучше 20 минут, даже если он такой - Ткнуть в кнопку, проверить, что появилось сообщение "Hello World", было время считал что каждый тест = 10 минут, но это не работает.
....

Спасибо большое за обширный ответ.
Всем, кто ответил, тоже спасибо. Самое "сложное", это выбить приблизительное время у разработчика на разработку. Буду пытаться.

Если вкратце - при оценки трудозатрат на тестирование можно исходить из следующий пунктов:

1. Время на анализ того, что должно быть протестировано
2. Время на написания соотетствующей документации (тест кейсы, чеклисты итд)
3. Время на тестирование уже поступившей функциональности
4. Время на ритест возможных багов
5. Время на регрессионное тестирование

Это даст вам +- правильною оценку.

По хорошему, этим должен заниматься руководитель тестирования.

У нас руководителей нет, так что оцениваем сами :( Это не трудно, надо только привыкнуть.

Самое "сложное", это выбить приблизительное время у разработчика на разработку. Буду пытаться.

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

Хм, у нас тоже система "оцени сколько времени тебе нужно", если задача типа "эт что вообще" в зависимости от объема функциональных кусков считается отдельно (вход в курс дела)+(написание бумажек)+(непосредственно тестирование)=время*2 как то так, желательно делать погрешность в большую сторону(на всех пунктах), т.к. на последнем пункте выясняется что что то пропустили, где то баг и проч. и проч. а тот запас что экономишь в начале всегда останется.
Оценивать время надо самому, тут никто не помощник, просто немного опыта и сможете нормально оценивать все :)

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

Легко и непринужденно. Просто чуть больше заложится на риски. И вы не поверите - оценивать можно даже Research задачки.

Книга "Сколько стоит программный проект" http://www.ozon.ru/c...ail/id/3115179/, страница 239 и рядом.