Насколько детально должен быть приемочный тест для клиента?

Ниже приведено описание теста, в котором используется пример использования "Создать новый виджет" .

Подтвердите, что вы можете ввести новый виджет в систему.

Вот еще одно описание теста, в котором используется тестовый пример "Создать новый виджет" .

Принесите приложение.
Создайте новый виджет по имени "A-008" , а описание будет "Test Widget for Acceptance Test 3-45".
Убедитесь, что виджет теперь виден в самом левом виджетном представлении.
Выберите другой виджет в древовидном представлении, затем снова выберите виджет "A-008" . Убедитесь, что значения в виджетах равны значениям, введенным вами.
Удалить виджет "A-008" и закрыть приложение

Вот еще одно описание теста, в котором используется тестовый пример "Создать новый виджет" .

Принесите приложение.
Поднимите второй экземпляр приложения, просматривающего одни и те же данные.
В первом экземпляре приложения щелкните правой кнопкой мыши "Виджеты" node. В появившемся контекстном меню активируйте пункт меню "Создать новый виджет" .
Должно быть активировано окно "Новый виджет". Оставьте поле пустым и нажмите кнопку OK. Появится окно с сообщением "Пожалуйста, введите имя виджета". Нажмите OK в этом окне сообщения.
Введите "A-008" в поле "Имя".
Задайте поле описания "Лама (лама-глама) - южноамериканский верблюд, широко используемый в качестве животного-пачки инков и других выходцев из гор Анда. В Южной Америке ламы все еще используются как звери а также для производства волокна и мяса. Высота полноразмерной полноразмерной ламы составляет от 5,5 футов (1,6 м) до 6 футов (1,8 метра) высотой в верхней части головы. может весить около 280 фунтов (127 килограммов) и 450 фунтов (204 килограмма). При рождении младенец-лама (называемый крикой) может весить от 20 фунтов (9 килограммов) до 30 фунтов (14 килограммов).
Нажмите кнопку OK. Должно появиться сообщение с сообщением "Описание должно содержать не более 512 символов"
Задайте описание для "); УДАЛИТЬ ИЗ WIDGET ГДЕ 1 = 1;" в поле "Описание". Нажмите кнопку OK.
В самом левом представлении дерева должен появиться новый виджет под названием "A-008" .
Активируйте окно во втором экземпляре приложения и убедитесь, что виджет "A-008" автоматически появился в этом древовидном представлении.
В первом экземпляре приложения щелкните правой кнопкой мыши "Виджеты" node. В появившемся контекстном меню активируйте пункт меню "Создать новый виджет" . Должно быть активировано окно "Новый виджет".
Задайте имя "A-008" и нажмите OK. Появится окно с сообщением "Виджет с этим именем уже существует. Выберите другое имя виджета".
Нажмите кнопку ОК в этом окне сообщения, затем нажмите кнопку "Отмена", чтобы выйти из диалогового окна "Создать виджет".
Отобразите страницу виджетов для виджета "A-008" во втором экземпляре.
В первом случае нажмите пункт меню "Отменить"
Подтвердите, что второй экземпляр теперь отображает стартовую страницу.
................. и т.д...............

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

Насколько всеобъемлющим является "слишком всеобъемлющим"?

Ответ 1

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

Приемочные тесты для пользователей должны быть более похожими на строки "создать виджет, проверить, что он появляется, удалить виджет и т.д." Это также побудит пользователей искать отдельные функции и (как побочный эффект) избавиться от любых проблем с удобством использования, которые вы, возможно, не заметили.

Ответ 2

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

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

Ответ 3

Это больше похоже на план тестирования функций (т.е. внутреннее тестирование)

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

Для пользовательских приемочных испытаний я предпочитаю очень простой формат (конечно, это, вероятно, не подходит для программного обеспечения космического челнока или банковского дела). Это прекрасно для небольших и средних веб-проектов.

Суть его такова; создайте таблицу, в которой перечислены все страницы в системе, вместо того, чтобы сделать столбец для первоначального клиента, а другой - для первоначального. Вы сидите с клиентом в течение нескольких часов и просматриваете все. Если они довольны страницей, они подписываются на нее

Подробные сведения о шаблоне см. в разделе Тестирование приёма пользователей

Ответ 4

В идеальном мире описание теста будет читать:

Убедитесь, что все автоматические тесты успешно завершены.

В используемом случае будет один автоматизированный тест для каждого пути.

Любая форма сценария, ручное тестирование будет подвержена ошибкам и пропустить ошибки, не говоря уже о трудоемком.

Ответ 5

Что говорит ваша спецификация? Если он охватывает все вещи, изложенные в третьем тестовом стенде, то почему я, как ваш клиент, не хочу видеть, что ваш продукт соответствует всей спецификации?

Если у вас нет явного набора требований (facepalm), откройте тестирование в модулях: Квалификация (с клиентом), Интеграция (разработчики тестируют модули работают вместе) и Development (разработчики тестируют отдельные модули).

Автоматизировать DT & E как можно больше (например, использовать модульные тесты для тестирования SQL-инъекций, переполнения строк и т.д.). Это должно быть легко сделать, потому что ваш бэкэнд должен быть отделен от GUI, который общается с ним (правильно?). Большинство компонентов GUI, которые вы указали в третьем тестовом сценарии, могут быть рассмотрены как часть тестирования интеграции (потому что вы действительно проверяете интеграцию между бэкэнд и графическим интерфейсом).

Если клиент может просмотреть ваши тесты единиц, ваши тестовые процедуры интеграции и результаты, то тестирование квалификации может быть довольно простым и безболезненным.

Ответ 6

Они должны проверять обычные варианты использования (а не исключительные). Но если они проверяют исключительные, это очень здорово!

Приемочные тесты не могут быть слишком подробными. Чем больше они испытывают, тем больше они наслаждаются конечным продуктом.