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

Question

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

• Убедитесь, что вы можете ввести новый виджет в систему.

---

Вот еще одно описание теста, тестирование «Создать новый виджет» потребительной случай.

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

---

Вот еще одно описание теста, тестирование «Создать новый виджет» потребительной случай.

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

Это выглядит как план тестирования функции для меня (то есть внутреннего тестирования)

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

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

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

Для получения полной информации о шаблоне, см: User Acceptance Testing