Структурированные подходы UAT

Question

Являясь разработчиком, я часто выпускаю различные версии приложений, которые я хочу проверить пользователями для выявления ошибок и подтверждения требований.

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

Хотелось бы узнать, какие подходы или процедуры принимаются другими пользователями при запросе UAT во время итеративного развития.

Спасибо.

Answer 1

Как правило, я создаю скрипт в excel с каждым списком функций и столбцом «Ожидаемый результат» и «Фактический результат» с столбцом «Ожидаемый результат», заполненным тем, что должно произойти. Для моего собственного использования я включаю столбец, который является идентификатором элемента. Это соответствует идентификатору задачи из Team Team или WSB из созданного плана проекта.

Answer 2

Я нахожу, что скрипты для написания сценариев не требуют больших затрат времени, часто дольше времени, затраченного на то, чтобы установить исправление. При большом объеме работы, который мы здесь делаем, у нас просто нет времени для создания эффективных тестовых сценариев.

С нашими изменениями мы проводим тестирование через два уровня, поддержку приложений и принятие бизнеса. Мы надеемся, что при техническом подходе и бизнес-подходах большинство аспектов изменений будут проверены. Чтобы сообщить им, что они должны проверить, мы приложим список действий, которые были внесены в результате изменения (добавление продукта, удаление продукта, редактирование продукта).

Это, в сочетании с сильным модульным тестированием, является наилучшим подходом к среде с большим объемом, на мой взгляд.

Answer 3

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

Answer 4

Вы ищете эффективный и эффективный способ проведения UAT структурированным образом. Я настоятельно рекомендую использовать подход с парным или комбинаторным дизайном. Я использовал этот подход в более чем 2 дюжинах доказательств концептуальных проектов и обнаружил, что по сравнению с традиционными методами идентификации тестовых случаев вручную этот подход последовательно приводит к значительному количеству дефектов, обнаруженных за час тестера. Фактически, в среднем, как сообщается на недавнем компьютере IEEE article, я написал в соавторстве, мы обнаружили, что на 2,4 X было столько дефектов за час тестера в среднем.

Подход описан в видео here. Извините, если это похоже на «использовать мой инструмент». Я не хочу, чтобы это было так. Это подход , который принесет значительные преимущества, а не конкретный инструмент, который вы решили использовать для разработки ваших тестов. Джеймс Бах также предлагает бесплатный инструмент под названием AllPairs на своем сайте satisfice.com. Я хочу сказать, что использование любого такого инструмента приведет к значительному улучшению результатов, поскольку эти инструменты предназначены для максимального охвата при минимальном количестве тестов. Они избегают повторения; кроме того, они автоматически идентифицируют и закрывают потенциальные пробелы в охвате, которые не могут быть закрыты вручную.

Хотя может быть контр-интуитивно понятно, что такой инструмент, как Hexawise, сможет идентифицировать (в секундах) тесты UAT, которые должны выполняться лучше, чем тестеры, смогут идентифицировать и документировать (в днях), это тем не менее верно. Попробуйте сами.Попросите одного тестировщика UAT в вашей команде выполнить 20 сквозных тестов «черный ящик» или «серый ящик», которые создаются с помощью Hexawise, и другие тестеры проверяют, что они обычно будут делать. Я бы поставил хорошие деньги, что тестер, выполнивший 20 тестов на Hexawise, обнаружил бы еще много дефектов за час тестера (и нашел бы «важные», а также «несущественные» дефекты).

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

Justin (Основатель Hexawise)