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

[Clauster]

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

Что у вас за терминология? Ничего не понимаю

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

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

[Case]

Clauster, тогда уж приводите примеры, а то как-то всё необоснованно.

[Rost]

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

Именно этим я сейчас занимаюсь и полностью с Вами согласен, все оооочень непросто.

Понятно, что сделать робот - не так просто. Именно сейчас такой робот в стадии разработки. Но суть не в этом, а в том, что не все то что разработано можно проверить простому (или даже продвинутому) тестировщику. Есть вещи, которые возлагаются на написание unit test, что само по себе не относится к тестировщикам. Вообще я согласен, что тема ушла в одну конкретную деталь. Я хотел только прибавить одну из составляющих сроков по тестированию, которая может быть полезна при небольших, но довольно сложных проектах.

[Clauster]

Clauster, тогда уж приводите примеры, а то как-то всё необоснованно.

а при чём тут я??? Примеры для чего?

[Clauster]

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

А я только хотел сказать, что нет смысла использовать два в принципе одинаковых коэффициента, когда можно всё заложить в один. Ведь если проект тестируется "с нуля", сложность тестирования находится в прямой зависимости от сложности проекта. Да и вообще можно сделать один единственный коэффициент, типа коэффициент изменения сроков тестирования, и в него закладывать всё, что душе угодно. Ну и опять-таки повторюсь, что я пытаюсь донести идею, а реализация у каждого должна быть своя, в силу специфики, вот мы с вами и не можем разобраться, потому что я не понимаю, в чём заключается сложность тестирования у вас и что вы мне пытаетесь объяснить (это я не к тому, что это надо мне объяснять ;) ), потому как работаем мы совершенно по-разному.

Ну и для регрессионного тестирования (наверно на это вы намекали) метод вряд ли подходит.

[Innale]

Я тут пытаюсь построить модель для оценки трудозатрат на тестирование, собрала лист факторов которые воздействуют на трудозатраты (извиняюсь, я лучше буду по англицки)
- Development effort
- Regression testing required (No Regression, Avarage, High, Full)
- New/Old functionality (тестеры знают как запускать или нет)
- Software stability (e.g. Application test status)
- Testing Complexity (насколько тестируемая аппликация сложна для запуска)
- Experienced Manpower

Подскажите пожалуйста, есть литература какая-то на эту тему?

[Clauster]

В теме проскакивают ссылки на некоторые источники. А вообще, непонятно, на какую "эту" тему?

[Innale]

В теме проскакивают ссылки на некоторые источники. А вообще, непонятно, на какую "эту" тему?

1) Ссылки "проскакивают" на источники по "Risk Management" которые отношения к теме не имеют
2) "эту" тему -Оценка трудозатрат на тестирование - тема топика

[Clauster]

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

[Green]

Ребята,

на самом деле, все очень просто.


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

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


В отношении рисков...

Риски - это то, что может произойти, но может и НЕ ПРОИЗОЙТИ. Следовательно, они не могут использоваться для вычисления трудозатрат. Они могут только изменить УЖЕ ВЫЧИСЛЕННЫЙ показатель в ту, или иную сторону. Так что говорить о рисках на стадии определения трудозатрат по проекту бессмыслено. Вот, когда трудозатраты определены, теперь пользуясь перечнем выявленных рисков можно определить насколько трудозатраты могут быть увеличины (или уменьшены) В СЛУЧАЕ НАСТУПЛЕНИЯ риска.

[Boltick]

Я наверное позновато, но всеже...

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

Нельзя ли формулу привести... :)
или привести как пример ресурс, где раскрыта методика вычисления


Заранее спасибо
Алексей Булат

[Green]

А вот готовой формулы и нет.


Точнее, я пока такой не встречал.

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

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

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

[dimasoft]

К задаче можно подходить двояко:
- снизу;
- сверху.

Сверху.
Решающую роль играет опыт предыдущих аналогичных проектов. В прошлый раз примерно такую же задачу мы тестировали 5 часов, выполнили 50 тестов, протестировали на 65% от общего списка требований.

Снизу.
На проекте имеем 100 требований. Каждое требование тестируется одиним тестом. Количество прогонов теста - от 4 раз (минимум) до 8 раз (максимум) - зависит от количество наборов тестовых данных. В среднем тест занимает от 2 до 5 минут. Каждый третий тест падает (по предыдущему опыту), значит плюс 5 минут на занесение проблемы в базу дефектов. Все суммируем по минимуму - получаем самый оптимальный вариан. Затем суммируем время наихудшего варианта. Берем среднее.

Интересные оценки. Тесты автоматические? Дефекты у вас автоматически регистрируются?
Что-то не верю я в такие оценки...

[Green]

К задаче можно подходить двояко:
- снизу;
- сверху.

Сверху.
Решающую роль играет опыт предыдущих аналогичных проектов. В прошлый раз примерно такую же задачу мы тестировали 5 часов, выполнили 50 тестов, протестировали на 65% от общего списка требований.

Снизу.
На проекте имеем 100 требований. Каждое требование тестируется одиним тестом. Количество прогонов теста - от 4 раз (минимум) до 8 раз (максимум) - зависит от количество наборов тестовых данных. В среднем тест занимает от 2 до 5 минут. Каждый третий тест падает (по предыдущему опыту), значит плюс 5 минут на занесение проблемы в базу дефектов. Все суммируем по минимуму - получаем самый оптимальный вариан. Затем суммируем время наихудшего варианта. Берем среднее.

Интересные оценки. Тесты автоматические? Дефекты у вас автоматически регистрируются?
Что-то не верю я в такие оценки...

А во что Вы верите?
В Бога?
Или в ?

[Case]

На проекте имеем 100 требований. Каждое требование тестируется одиним тестом.

Сергей, салют! Пардон что аппелирую к комменту 2005 года Просто сейчас увидел эти строчи в цитате и захотеслоь уточнить: 1 требование покрывается 1 тестом?

[Green]

На проекте имеем 100 требований. Каждое требование тестируется одиним тестом.

Сергей, салют! Пардон что аппелирую к комменту 2005 года Просто сейчас увидел эти строчи в цитате и захотеслоь уточнить: 1 требование покрывается 1 тестом?

Слава,

и ты туда же!
Это же пример, описывающий подход. Главное - принцип, а цифры подставляй любые, соответствующие ситуации.

[Case]

Да не "туда" я :) Просто уточнил, чесное слово.