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

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

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

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

Удачи!

Answer 3

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

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

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

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

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

Джастин

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