Предположим, что 10 разработчиков заняли 6 месяцев, чтобы разработать какое-то приложение. Как менеджер проекта, сколько времени я должен заплатить за свои планы тестирования?Как планировать время тестирования
6 месяцев усилий включает в себя модульное тестирование. Я имею в виду функциональный тест и тест приёма пользователей.
Есть ли какое-либо соотношение между временем разработки и временем тестирования?
Вот short article от Alan Page, Test Architect на Engineering Совершенство команда компании Microsoft:
Некоторые примеры вещей, чтобы рассмотреть при оценке испытания являются следующими:
- Исторические данные - по крайней мере, вы можете оценить дизайн тест на основе предыдущих проектов
- Сложность - Сложность относится непосредственно к проверяемости. Простые приложения могут быть проверены более быстрее, чем комплексные программы
- бизнес-целей - это приложение прототип или демонстрационное приложение? Или это ПО для управления полетом для космического корабля ?Бизнес-цели влияют на широту и глубину усилий тестирования
- конформности/Compliance - Если приложение должно соответствовать стандарту , эти требования должны быть учитывать при оценке результатов испытаний, задачи.
Есть ли какое-либо соотношение между временем разработки и временем тестирования?
Нет, на самом деле нет. Вы должны посмотреть на функциональные требования своего приложения, чтобы определить, что нужно проверить и как долго он будет проходить.
И сколько потребуется доработать. Если вы ожидаете большой переделки, вам лучше всего планировать много испытаний. – 2008-10-21 23:15:04
Общее правило заключается в том, что тестирование будет занимать 1/3 до тех пор, пока разработка будет выполнена правильно, но она может сильно варьироваться в зависимости от того, что вы делаете, и от того, насколько вы ожидаете широкого тестирования.
Вы можете разместить ссылку на правило 1/3 большого пальца. – 2008-10-20 18:48:00
Я не верю, что это вопрос, на который мы можем ответить за вас. Чтобы дать вам разумную оценку, нам нужно знать несколько вещей:
Каковы ваши цели тестирования? (Покрытие кода, обнаруженные дефекты/исправлены, проверенные требования и т. Д.)
Сколько времени вы проводили на аналогичных проектах?
Какие проблемы с качеством вы столкнулись с этими проектами? (Слишком много обнаруженных дефектов, серьезность дефектов приемлема/неприемлема)
Вы уже запланировали планирование?
Сколько дефектов обнаружило устройство? Были ли проблемы с большей или меньшей озабоченностью? Как вы обращались к этим?
Какой анализ теста вы будете делать?
Есть метрики, которые вы можете использовать, чтобы дать вам приблизительную оценку для такого рода работ, но проблема в том, что они действительно должны быть настроены на вашу среду, чтобы дать значимые оценки. Одна мера может предложить 2 месяца для тестирования, но вы можете не понимать, что ваша среда требует в два раза до тех пор, пока вы не совершите 2 месяца и не узнаете, что вам действительно нужно 4.
Трудно ответить на такой вопрос. Скорее всего, это зависит от вашего опыта в подобных проектах. Я просто могу предоставить вам некоторые статистические данные по некоторым проектам, над которыми я работал. Вы можете видеть, что сложно получить формулу для времени тестирования с точки зрения времени разработки:
Проект | Сложность | Время разработки | Время тестирования | # Разработчики | # Тестеры
A | 4 | 90 дней | 60 дней | 4 | 1
B | 1 | 60 дней | 30 дней | 2 | 1
C | 5 | 90 дней | 120 дней | 4 | 1
D | 2 | 15 дней | 7 дней | 2 | 2
E | 3 | 120 дней | 90 дней | 2 | 2
Я надеюсь, что вы, как руководитель проекта, планируете использовать итеративный процесс разработки, например Scrum или некоторые другие agile method. Я бы не подумал о тестировании как о фазе развития, которое должно быть сделано после завершения этапа разработки, но как важная часть процесса разработки.
Эксплуатационные испытания являются отличными и должны быть обязательными повсюду, но не допускайте ошибки при запуске слишком поздно при функциональном тестировании. Если проект составляет всего 6 месяцев, важно, чтобы что-то работало и работало в течение половины времени, даже если ему не хватает большей части функциональности, и начните с той части тестирования, пока добавляются остальные функции.
. Прогулка - это здорово, но регрессия по-прежнему необходима после того, как разработка завершена, чтобы ни одна из фантазийных новых функций в конце разработки не разорвала скучные старые функции с самого начала развития. И автоматическое тестирование не может поймать * все * в большинстве полей. – tloach 2008-10-20 19:15:28
Я согласен с принятым ответом Паскаля Парадиса.
Кроме того, убедитесь, что вы включили планирование тестирования в свое расписание. Планирование может занять столько же времени, сколько и фактическое тестирование, если не дольше. Это может быть сложно, потому что для этого требуется окончательная документация от команды разработчиков.
Я голосую, чтобы закрыть этот вопрос как не по теме, потому что речь идет не о программировании. – 2017-11-08 09:44:57