Сколько времени должно быть выделено на тестирование и исправление ошибок [закрыто]
каждый раз, когда мне нужно оценить время для проекта (или просмотреть чужую оценку), время выделяется для тестирования/исправления ошибок, которые будут выполняться между Альфа-и производственными выпусками. Я очень хорошо знаю, что оценка до сих пор в будущем относительно набора проблем неизвестного размера не является хорошим рецептом для успешной оценки. Однако по целому ряду причин определенное количество часов неизменно присваивается с самого начала этому сегменту работы. И чем дальше это начальная оценка от реального, конечного значения, тем больше горя те, кто участвует в отладке придется взять позже, когда они идут "над" оценкой.
Итак, мой вопрос: какова лучшая стратегия, которую вы видели в отношении таких оценок? Фиксированный процент от общей оценки dev? Установить количество часов (с расчетом, что оно пойдет вверх)? Что-то еще?
что-то еще, чтобы рассмотреть: как бы вы ответили на это по-другому, если клиент несет ответственность за тестирование (в отличие от внутреннего QA), и вы должны назначить количество времени для ответа на ошибки, которые они могут или не могут найти (поэтому вам нужно выяснить оценки времени для исправления ошибок, но не для тестирования)
5 ответов
Это действительно зависит от многих факторов. Упомянем лишь несколько: методику разработки, которую вы используете, количество ресурсов тестирования, которое у вас есть, количество разработчиков, доступных на этом этапе проекта (многие руководители проектов будут перемещать людей на что-то новое в конце).
Как говорит Роб Рольник, 1: 1 - хорошее эмпирическое правило, однако в случаях, когда спецификация плоха, клиент может нажать на "ошибки", которые на самом деле плохо указаны. Я был недавно участвовал в проекте, который использовал много релизов, но больше времени было потрачено на исправление ошибок, чем на фактическую разработку из-за ужасной спецификации.
обеспечьте хорошую спецификацию / дизайн и Ваше время отладки испытания/ошибки будет уменьшено потому что будет легче для тестеров увидеть чего и как испытать и все клиенты будут иметь меньше ли-пути нажать для дополнительных особенностей.
может быть, я просто пишу багги-код, но мне нравится соотношение 1:1 между разработчиками и тестами. Я не жду, пока альфа проверит, а скорее делаю это на протяжении всего проекта. Логика? В зависимости от вашего графика выпуска может быть много времени между началом разработки и датами альфа, бета и отгрузки. Кроме того, чем раньше вы поймаете ошибки, тем проще (и дешевле) их исправить.
хороший тестер, который находит ошибки вскоре после каждой регистрации, бесценный. (Или, еще лучше, перед регистрацией из PR или DPK) проще говоря, я все еще очень хорошо знаком с моим кодом, поэтому большинство исправлений ошибок становятся супер простыми. При таком подходе я, как правило, оставляю примерно 15% моего времени разработки для исправления ошибок. По крайней мере, когда я делаю оценки. Поэтому в 16-недельном пробеге я бы ушел около 2-3 недель.
из Библии тестирования:
Тестирование Программного Обеспечения
p. 31: "испытание [...] составляет 45% от первоначальной разработки продукта."Хорошее эмпирическое правило, таким образом, чтобы выделить около половины ваших общих усилий на тестирование во время начальной разработки.
только хорошее количество накопленной статистики из предыдущих проектов может помочь вам дать точные оценки. Если у вас есть определенный набор требований, вы можете сделать приблизительный расчет, сколько дел у вас. Как я уже сказал, вам нужно иметь некоторую статистику для вашей команды. Вам нужно знать среднее число ошибок на локацию, чтобы оценить общее количество ошибок. Если у вас нет таких номеров для вашей команды, вы можете использовать средние по отрасли цифры. После того, как вы оценили LOC (количество вариантов использования * NLOC) и средние ошибки в строках, вы можете дать более или менее точную оценку времени, необходимого для выпуска проекта.
из моего практического опыта время, затрачиваемое на исправление ошибок, равно или больше (в 99% случаев:)), чем время, затрачиваемое на оригинальную реализацию.
используйте язык с дизайном по контракту или" кодовыми контрактами "(предварительные условия, утверждения проверки, пост-условия, инварианты классов и т. д.), Чтобы получить" тестирование " как можно ближе к вашим классам и функциям класса (методы и свойства). Затем используйте TDD для тестирования кода с его контрактами.
Используйте как можно больше самостоятельного создания кода, насколько это возможно. Сгенерированный код проверен, предсказуем, легче отлаживать и легче/быстрее исправлять, чем полностью ручной код. Зачем писать то, что ты может генерировать? Однако не используйте OPG (other-peoples-generators)! Кода Вы создаете код, вы контролируете и знаете.
вы можете ожидать, что потратите инвертирующее соотношение в течение вашего проекта-то есть-вы напишете много ручного кода и контрактов в начале (1:1) вашего проекта. Как вы видите шаблоны, научите генератор кода, который вы пишете, генерировать код для вас и повторно использовать его. Чем больше вы создаете, тем меньше вы разрабатываете, пишете, отлаживаете и тестируете. К концу проекта вы вы обнаружите, что ваше уравнение перевернуто: вы пишете меньше своего основного кода, и ваш фокус смещается на ваш "листовой код" (последняя миля) или специализированный (vs обобщенный и сгенерированный) код.
наконец -- получить анализатор кода. Хорошая, автоматизированная система правил анализа кода и движок сэкономят вам кучу времени на поиске "глупых ошибок", потому что есть хорошо известные gotchas в том, как люди пишут код на определенных языках. В Эйфеле у нас теперь есть Eiffel Inspector, где мы не только используем 90+ правила приходят с ним, но учатся писать наши собственные правила для наших собственных обнаруженных "gotchas". Такие анализаторы не только спасают вас от ошибок, но и улучшают ваш дизайн-даже зеленые программисты" получают это " довольно быстро и перестают делать ошибки новичка раньше и учатся быстрее!
эмпирическое правило для переписывания существующих систем таково: "если потребовалось 10 лет, чтобы написать, потребуется 10 лет, чтобы переписать."В нашем случае, используя Eiffel, дизайн по контракту, анализ кода и код Поколение, мы переписывали систему 14 год в 4 летах и полно поставим в 4 1/2. Новая система примерно в 4x-5x сложнее старой системы, так что это говорит о многом!