Перейти к содержимому

Тестирование юзабилити (usability)
онлайн, начало 1 апреля
Школа тест-менеджеров v. 2.0
онлайн, начало 1 апреля
Программирование на C# для тестировщиков
онлайн, начало 3 апреля
Тестирование производительности: JMeter 5
онлайн, начало 3 апреля
Фотография

сроки тестирования. как их оценивать?


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 22

#21 greesha

greesha

    Опытный участник

  • Members
  • PipPipPipPip
  • 363 сообщений
  • ФИО:Печёнкин Григорий Михайлович
  • Город:Мытищи

Отправлено 19 Февраль 2009 - 08:32

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

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

#22 VITAL

VITAL

    Новый участник

  • Members
  • Pip
  • 13 сообщений
  • ФИО:Ворончихин Александр Витальевич
  • Город:Ижевск

Отправлено 10 Ноябрь 2009 - 10:43

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

#23 ShortLegged

ShortLegged

    Постоянный участник

  • Members
  • PipPipPip
  • 155 сообщений
  • Город:Moscow

Отправлено 10 Ноябрь 2009 - 12:16

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


Школа Тест-Аналитика
онлайн
Организация автоматизированного тестирования
онлайн
Школа тест-менеджеров v. 2.0
онлайн
Тестирование юзабилити (usability)
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале