Любые эмпирические правила для оценки усилий UAT - например, для количества сценариев по сравнению с количеством бизнес-требований?

Question

Я пытаюсь оценить количество или тестеры, необходимые для тестирования проекта. Один из способов состоит в том, чтобы определить количество сценариев, которые потребуются, и задавался вопросом, существует ли правило большого количества сценариев по сравнению с количеством требований. Я оценка 2 - 3.

• 1 для испытания типа солнечного дня
• 1 для отрицательного теста
• 1, по крайней мере, комбинируя тест 1 требование, по меньшей мере, один другими.

но это только мое первоначальное предположение. Если есть несколько лучших практик, я все уши. Опять же, это не для модульного тестирования или тестирования систем, это для пользовательских приемочных испытаний.

Answer 1

Лучшая оценка, которую вы получите, поступает от тестеров, проводящих тестирование. Вне этого типа оценки от тестировщиков вы можете найти какой-то процент времени тестирования по сравнению с временем разработки.

Скажите, что у вас была 100-часовая задача разработки. Вы тратите 20 часов на дизайн, 80 часов на сборку. Вы могли бы прийти к выводу, что для тестирования потребуется 15 часов, или 15% времени разработки. Затем вы можете применить 15% к вашей общей оценке развития для тестирования UAT, зная, что некоторые из них занимают больше времени, а некоторые меньше.

Answer 2

Hey Shinyfish, я понимаю импульс, чтобы хотеть формулу ... и я обещаю вам, что любая общая формула окажется ошибочной вне узкого контекста. Рассмотрим кого-то, кто говорит вам, что каждое требование должно иметь N тестов, связанных с ним. Теперь рассмотрим несколько требований к выборке, например.

1. поле имени пользователя требуется минимум 6 буквенно-цифровых символов, по сравнению с
2. Дозировка калькулятор правильно рассчитать дозу пациента опасности-о-медицине, в зависимости от их возраста, пола, массы тела.

Оба варианта являются возможными. Первый - относительно простые и довольно низкие ставки. Вторая имеет много потенциальных точек отказа, и, если она во многих случаях преуспевает, но не срабатывает в нескольких, казалось бы, случайных, она убьет кого-то. Любой, кто говорит вам считать ваши требования, а затем умножается на что-то, вводится в заблуждение или продает змеиное масло.

Аналогично, утверждая, что UAT займет 1/Nth время кодирования/может/быть полезной эвристикой в ​​каком-либо бизнес-контексте, но значение для N будет сильно отличаться между, скажем, запуском, создающим программное обеспечение для ведения блогов и разработкой следующего версия Photoshop. В этом отношении, что/вы/означаете UAT (и то, что делает ваше подразделение и системное тестирование (не)), вероятно, сильно варьируется от того, что люди советуют вам понимать на тех же условиях.

Вот правило, которое я мог бы использовать, чтобы оценить, сколько времени займет testing'll:

Во-первых, в той степени, что это возможно, рассматривать подобные проекты в рамках вашей организации.

• Сколько человек/дней тестирования получили?
• Были заинтересованы заинтересованные стороны в том, насколько тщательно продукт был протестирован?
• Как вы ожидаете, что этот новый проект будет похожим/отличным от предыдущих?
• Насколько опытные/опытные тестеры вы получите, по сравнению с предыдущими проектами?
• Насколько они будут понимать этот проект с самого начала, по сравнению с предыдущими проектами?

Конечно, иногда у вас нет соответствующих предыдущих проектов для сравнения. Если вы не ... знаете, что ваша оценка будет иметь гораздо большую погрешность. Я не могу говорить за вас, но 98.% разработчиков (тестеров, кодеров и т. Д.), С которыми я работал с хронически недооценивать. Если это верно для вас, постарайтесь соответственно компенсировать это. Возможно, самое главное, постарайтесь понять, насколько точна ваша оценка (или нет), а затем соответствующим ожиданиям заинтересованных сторон. Предоставление иллюзии уверенности редко помогает кому-либо.

Удачи!

Answer 3

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

1) Ваша обратно из расчета огибающей ... 2,5 тестовых случаев на требование (но точки Джефф Фрай мертв, иногда требуется больше, иногда меньше)

2) Быстро вычислить 1/N-й ответ времени ... Какой процент общего времени разработки и/или общего времени тестирования мы использовали в последний раз для проект этого общего типа? Достаточно ли было сделать эту работу?

3) Проведите час, вводя параметры и значения в инструмент тестового проектирования, например Hexawise, и создайте простой двухсторонний (или попарно) набор условий тестирования. Выполнение этого обычно даст вам минимальное количество тестов, за пределами которых вы, как правило, не хотите вырезать. Дополнительным преимуществом использования инструмента тестирования является то, что вы не только подтвердите, что заявленное требование №1: «сайт выглядит нормально при использовании браузера Google Chrome» и «Заявленное требование № 2»: пользователи могут изменить кредитную карту, которую они будут использовать для оплаты в конце транзакции », а также/Unstated/Requirement (что никто не думал включить)« Убедитесь, что пользователь, использующий Google Chrome, сможет изменить свою кредитную карту »получает тестирование также. Expedia, по-видимому, не придерживалась этого подхода, но я отвлекаюсь ... (Соответствующая сторона примечания: если вы не пробовали использовать пару-тройку методов тестирования или инструмент, такой как Hexawise, чтобы помочь с полуавтоматическим тестированием, чтобы увидеть значительное увеличение эффективности тестирования, когда вы начнете его использовать, будет проведено меньше тестов, необходимых для достижения всех возможных пар, чем вы могли бы подумать. Пример: для достижения этого типа требуется всего 35 тестов полное попарное покрытие по сравнению с 72 миллиардами тестов, которые потребуются для всестороннего тестирования при проверке функциональности «Получить направления» в Google Maps). Большинство ваших требований легко впишутся в инструмент проектирования тестов. Некоторые не будут.

4) Примите в среднем три оценки и добавьте к нему 20%, если подобные проекты были значительно занижены.

Джастин

Раскрытие: Я основатель Hexawise, который предлагает бесплатную версию нашего тестового дизайна инструмента в www.hexawise.com/users/new