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

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 символов»
  
• Установить описание на "'); УДАЛИТЬ ИЗ ВИДЖЕТА, ГДЕ 1 = 1;" в поле «Описание». Нажмите кнопку ОК.
• В самом левом виде дерева должен появиться новый виджет с именем "A-008".
  
• Активируйте окно во втором экземпляре приложения и убедитесь, что виджет "A-008" автоматически появился и в этом древовидном представлении.
  
• В первом случае приложения щелкните правой кнопкой мыши узел «Виджеты». В появившемся контекстном меню активируйте пункт меню «Создать новый виджет». Окно «Новый виджет» должно быть активировано.
  
• Установите имя «A-008» и нажмите OK. Должно появиться окно с сообщением «Виджет с таким именем уже существует. Пожалуйста, выберите другое имя виджета».
  
• Нажмите кнопку «ОК» в этом окне сообщения, затем нажмите кнопку «Отмена», чтобы выйти из диалогового окна «Создать виджет».
• Отображение страницы виджета для виджета «A-008» во втором экземпляре.
• В первую очередь нажмите пункт меню «Отменить»
• Убедитесь, что второй экземпляр теперь отображает стартовую страницу.
• ................. и т.д. ..............

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Для получения полной информации о шаблоне см .: Приемочное тестирование пользователя

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

В идеальном мире описание теста будет выглядеть так:

• Подтвердите, что все автоматизированные тесты успешно завершены

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

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