Сообщений в теме: 56

[Dmitry_NJ]

Вот змея и проглотила свой хвост... (смотри первый пост)

Только в первом посте нет никакого намека на определение трудозатрат "когда о предмете тестирования еще ничего не известно".

[Натали]

Натали, опишите ваше приложение или систему?

Их несколько.
Но вот например - система банковского учета. Есть какая-то стабильная основа, которая адаптируется под заказчика. Недавно был заказчик, под которого эта система изменялась очень сильно.
И была ситуация, когда надо было определить трудозатраты по тестированию новых функций, которых в системе раньше не было и еще неясно было, в каком виде (новая форма, изменение внешнего вида и работы текущей, просто донастройка скриптов) это будет сделано. Т.е. заявка на изменение не содержала подробных описаний, только общее. Подробности пришли позже.
А я еще не настолько опытный тестер, чтобы определять трудозатраты по общему описанию.
Или еще - собираются делать новый проект. Идея - т.е. для чего будет проект, известна, нечто подобное(интерфейсно) было. ТЗ еще нет. С меня спрашивают, сколько времени может потребовать тестирование этого проекта.

Если нет даже описания предмета тестирования, то как можно формализовать оценку трудозатрат на него?

Вот! Иногда я и думаю, что в моей ситуации определение "на глазок" или "подобное подобному" обусловлено недостатком информации и нормально. Но все время кажется, что есть волшебные методики. :)

Вот вам формализованный подход.

Спасибо, буду разбираться.

[Case]

Вот вам формализованный подход. В случае тестирования под одной ОС, в одной конфигурации и отсутствия сложной инсталляции берём, например, 25% от общего планового времени проекта.

Несколько вопросов:
1. Откуда цифра 25%? Средне потолочное? Насколько могу понять эта цифра зависит от типа проекта. Есть проекты в которых тестирование занимает времени больше чем сама разработка: для них вообще рациональнее заменить тестирование параллельной разработкой второй подобной системы - и сравнивать промежуточные результаты. Это только один возможный вариант.
2. Что значит "сложная инсталляция"? Опять-таки на старте проекта не всегда понятно какая она будет, эта инсталляция. Опять таки оценка потолочная выйдет.

Если стоит задача определить время проекта, то оно неизвестно.
Имеем время проекта Х, и время тестирования 0,25*Х - что даёт?

Дальше:

осталось прибавить время на инсталляцию проекта
Ттест=Ксл*Тплан(0.25+0.05(Nos+Nconf-2))+Тинст

Не совсем понял при чём тут инсталляция проекта к затратам на тестирование? Да, это время безусловно будет потрачено, но сходу его относить к затратам на тестирование я бы не стал - деплоймент это несколько отдельный бизнес. Система, которую я на данный момент тестирую собирается минут за 20 и разворачивается с настройками более 2 часов. Занимается этим отдел разработки - это не мои затраты.

Имеем много припусков изначально и попытки учитывать риски в конце (кстати, можно пример? а то звучит как-то голословно - учитывайте риски).

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

[Clauster]

Ещё раз повторюсь, что здесь есть ограничения. Метод скорее подходит для внешнего тестирования средних и маленьких проектов сроком менее полугода, когда группа тестирования независима от группы проекта.

Несколько вопросов:
1. Откуда цифра 25%? Средне потолочное?

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

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

Смотрим параметр Ксл, по которому, на самом деле, тоже надо определить влияющие на него факторы, например: тип проекта, используемая в проекте аппаратная часть, сложность бизнесс-логики, количество пользователей, распределённость системы и т.п.

2. Что значит "сложная инсталляция"? Опять-таки на старте проекта не всегда понятно какая она будет, эта инсталляция. Опять таки оценка потолочная выйдет.

Это не те случаи, когда просто запускаешь msi или что-то ещё, и система установилась. Например, надо сконфигурировать аппартуру или создать полигон тестирования и т.д.

Если стоит задача определить время проекта, то оно неизвестно.
Имеем время проекта Х, и время тестирования 0,25*Х - что даёт?

Время проекта известно, мы же получаем готовую систему на тестирование, 0,25*Х это совсем частный и простейший случай и скорее подходит для мелких внутренних проектов.

Дальше:

осталось прибавить время на инсталляцию проекта
Ттест=Ксл*Тплан(0.25+0.05(Nos+Nconf-2))+Тинст

Не совсем понял при чём тут инсталляция проекта к затратам на тестирование? Да, это время безусловно будет потрачено, но сходу его относить к затратам на тестирование я бы не стал - деплоймент это несколько отдельный бизнес. Система, которую я на данный момент тестирую собирается минут за 20 и разворачивается с настройками более 2 часов. Занимается этим отдел разработки - это не мои затраты.

Ну так я не настаиваю, не учитывайте время на инсталляцию, если не вы инсталлируете и это время не тратите.

Имеем много припусков изначально и попытки учитывать риски в конце (кстати, можно пример? а то звучит как-то голословно - учитывайте риски).

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

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

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

[Case]

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

Кофе брейки? При работе с рисками проекта? :)

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

Это как по мне какая-то странная работа с рисками. Равно как и попытка оценки ненадёжности аппаратной части. Я бы говорил о недостаточной формализованности требований или инновационности проекта: его исследовательсткой составляющей - то есть о более предметных для рисков вещах. Иначе кк работать с такими рисками, о которых вы упомянули?

Насчёт статьи не знаю, много ограничений...

Так и оговорить их отдельно. Assumptions своего рода.

[Clauster]

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

Кофе брейки? При работе с рисками проекта? :)

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

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

Это как по мне какая-то странная работа с рисками. Равно как и попытка оценки ненадёжности аппаратной части. Я бы говорил о недостаточной формализованности требований или инновационности проекта: его исследовательсткой составляющей - то есть о более предметных для рисков вещах. Иначе кк работать с такими рисками, о которых вы упомянули?

См. выше. Добавлю ещё, что риски параметр вероятностный. Самый сложный по поведению объект в системе - человек. А чем смущает ненадёжность аппаратной части? Тут вообще примеров масса, хотя бы: недостаточная мощность процессора, регулярные отключения электроэнергии (перегрузки в сети) и т.п. То, что вы упомянули, это вообще, на мой взгляд, витание в облаках. Так можно и от темы уйти. Ну а самый простой способ работы с рисками - берёте 5-10 процентов от времени тестирования и всё. Главное понимать, есть ли риски вообще?
Сложилось впечатление, что вы как-то всё время пытаетесь сузить предмет обсуждения, ну это чисто тестерское. Попробуйте абстрагироваться и как-то пошире взглянуть, может некоторые вопросы сами собой отпадут.

Насчёт статьи не знаю, много ограничений...

Так и оговорить их отдельно. Assumptions своего рода.

Дык полстатьи будет описание ограничений!

[Case]

Коллега, не путайте меня - я сам запутаюсь.
Давайте тогда разберёмся что есть риски :)

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

"недостаточная мощность процессора" - это не риск, это факт, я бы сказал - показатель окружения. Что тут мешает вам оценивать затраты на тестирование? "Кофе брейк" это не риск это факт - брейки есть - их надо учитывать - но к рискам это не имеет никакого отношения. То что в какой-то конкретной компании кто-то кофе брейк назвал риском (я бы хотел поглядеть кстати на план работ по списку таких рисков ;)) не отменяет основ риск-менеджмента.

PS
Надо делать словарь терминов и определений: многие обсуждения к этому скатываются.

[daniel]

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

Я обычно говорю, что не меньше 30-40% от времени разработки, прекрасно понимая, как можно попасть...

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

Коллеги, а сколько проектов в вашей практике было сдано вовремя?

"гладко было на бумаге, но забыли про овраги"

[barancev]

Давайте, чтобы не быть голословными и зря не спорить, посмртрим на авторитетные источники, скажем -- CMU/SEI Technical Report on Taxonomy-Based Risk Identification (PDF, ~200K), особенно внимательно смотреть Appendix A. Эта таксономия охватывает столько потенциальных источников рисков, что никому мало не покажется -- от аппаратно-технических проблем до падения морального духа сотрудников, от плохо проработанных требований до политической ситуации в стране B)

Разумеется, ни один здравомыслящий человек в реальной жизни не станет рассматривать все эти источники с равной степенью серьёзсности. Из практических соображений рекомендуется в каждый момент выбрать 3-5 (ну, максимум, 10) наиболее критических рисков и сосредоточиться на них -- следить, предотвращать, преодолевать. Разумеется, этот "чёрный" список нужно регулярно пересматривать, так чтобы в каждый момент он состоял из рисков, критичных "сейчас", а не полгода назад. И у каждого этот хит-парад свой -- у кого-то на вершине недостаточная формализованность требований, а у кого-то, скажем, потенциально возможный blackout (чай, не одна только Чагинская подстанция работает на изношенном оборудовании). Все зависит от того, во сколько вам встанет, если это "возможное нежелательное явление" станет реальностью.

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

[Clauster]

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

Спасибо, вы прекрасно за меня ответили!

[Stas]

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

А что актуально ?

[Case]

К теме про риски.
Опубликован материал от Борланда: Представление о риске и управление им. Очень рекоммендую (буквально страница 5) - Источники Риска.

[Clauster]

А что актуально ?

смотри пост =Clauster May 30 2005, 01:19 PM Сообщение #13=

[Rost]

И все же уважаемые, тема пока что так и осталась не очень раскрытой.Плавно перешли к рискам и работе над ними. :-)
Возвращаясь к теме:
Я думаю что в таком случае очень поможет разговор с теми кто планирует разработку. Но разговор не на уровне - "...тут на кнопку пам, тут оно тара-бам и все чохом в окне..." а на уровне - "...мы собираемся использвать язык такой-то с такой-то СУБД. Такие-то аппаратные требования... Основная сложность будет в связке того-то и того-то, а так же в переводе из одного состояния стейт машины в другое, а именно, обработка системой данного перехода..." Это так же можно отнести к коэффициенту сложности. Но по крайней мере не совсем уж к эмпирическому (потолочному).
Кстати о коэффициенте сложности. Я бы его разбил на два: 1. Сложность системы, которая должна как раз проясниться после разговора с менеджером проекта, а лучше всех лидов проекта; 2. сложность тестирования (т.е. сложность создания initial state, сложность выполнения самого TC) это собственно пункт 1 со стороны тестировщика.

[Clauster]

2. сложность тестирования (т.е. сложность создания initial state, сложность выполнения самого TC) это собственно пункт 1 со стороны тестировщика.

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

[Rost]

Clauster
Что это за сложности такие? Чем сложнее система, тем её сложнее тестировать, это и так очевидно. Зачем выдумывать ещё какие-то сложности тестирования?

Эти сложности в результате помогают лучше и более точно спрогнозировать конечное время. Именно поэтому и придумали риск менеджмент, митигейшен планы и все остальное. Собственно за что и боримся. Я понимаю, что если цель - в течении 30-60 минут сказать сколько времени надо на тестирование чего-то еще не совсем описанного, то тут можно просто сказать 40-60% от времени разработки. Но если подходить к этому делу со всей ответственностью, вводить коэффициенты, то так просто это не делается. Приведу пример, что бы не выглядеть голословным. Допустим наш проект - embedded type. Т.е. сложность уже присутствует априори. Это и ограничение по железу, и уровень разработчиков и, немало важно, уровень тестировщиков. Так вот, сложный проект по созданию мобильного телефона. Сложность самого проекта наверняка будет одной из самых высоких, но вот тестирование производится со стороны конечного пользователя. Т.е. эмулятор и погнал тест кейсы проверять. Очевидно не слишком сложное тестирование и + не нужен большой опыт. В случае с одним коэффициентом что туда писать? Проект довольно сложный, однако тестирование вполне тривиальное. Именно по этому я и предложил разбивать сложность на сложность разработки и на сложность тестирования. Это никоим образом не камень в огород автора, это скорее небольшая поправка, которую можно внести в статью. :-) (Одно из множества ограничений)

[Clauster]

Приведу пример, что бы не выглядеть голословным. Допустим наш проект - embedded type. Т.е. сложность уже присутствует априори. Это и ограничение по железу, и уровень разработчиков и, немало важно, уровень тестировщиков. Так вот, сложный проект по созданию мобильного телефона. Сложность самого проекта наверняка будет одной из самых высоких, но вот тестирование производится со стороны конечного пользователя.
Т.е. эмулятор и погнал тест кейсы проверять. Очевидно не слишком сложное тестирование и + не нужен большой опыт.

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

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

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

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

[Clauster]

риск менеджмент, митигейшен планы ... embedded type

вы уж потрудитесь не русские слова писать не по-русски, а то ваши посты читать крайне неприятно

[Rost]

вы уж потрудитесь не русские слова писать не по-русски, а то ваши посты читать крайне неприятно

Извините. Mitigation plan - это план который выполняется в случае когда риск стал фактом.

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

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

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

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