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

[greesha]

Если команда опытная, а объём тестирования уже более-менее понятен и может быть разбит на законченные блоки, можно попробовать экспертную оценку методом Agile: Planning Pocker. Результаты получаются на удивление точными.

Странно, но ссылок на русскоязычные ресурсы не нашёл. Хотя, вроде бы, видел где-то перевод вот этой статьи:
http://www.crisp.se/planningpoker/

[VITAL]

У нас в компании для определения трудоемкости тестирования появилось желание выделить некие неделимые функциональные блоки продукта (Заполнение лог-файла, заполнение карточки справочника, и т.д.). Трудоемкость тестирования каждого блока фиксирована. Т.е. при написании стратегии тестирования мы просто берем блоки, которые будут в разрабатываемой функциональности и суммируем их трудоемкости тестирования. Для чего это надо. Чтобы дать на ранних стадиях более достоверную информацию о трудоемкости тестирования для руководителя проекта. А также чтобы эта трудоемкость была максимально прозрачна для всех (чтобы вопросов было меньше). Почему-то у меня в душе есть очень большие сомнения что такой метод будет работоспособным. В чем мои сомнения:
1. Мне кажется просто невозможным выделить все блоки, чтобы потом что-то по ним спрогнозировать.
2. Разработка временами кардинально меняется. Так что трудоемкость будет не верной.
3. На момент определения трудозатрат не всегда вообще еще ясно даже разработчику в полном объеме из чего будет состоять функциональность и как она будет реализована.
Сейчас определение трудозатрат происходит следующим образом:
1. Изучение тестовой основы (требования, ТЗ, проекты разработчиков и т.д.);
2. Выделение объектов тестирования.
3. Для каждого объекта определяется вид тестирования.
4. По каждому объекту выписывается список функций (уровень детализации не очень высокий)
5. Определяем на каких стенда нужно будет протестировать
6. На основе всего этого делаем вывод о трудоемкости тестирования с учетом возможных рисков и собственного опыта.
Существующий метод вроде бы полностью удовлетворяет.
Занимался ли кто-нибудь выделением этих самых блоков и каков результат? Оправданы ли мои сомнения?

[ShortLegged]

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