Насколько подробным должен быть приемочный тест?
Вот описание теста, тестирующего сценарий использования "Создать новый виджет".
- Подтвердите, что вы можете ввести новый виджет в систему.
Вот еще одно описание теста, тестирующее сценарий использования "Создать новый виджет".
- Поднимите заявку.
- Создайте новый виджет с именем "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" во втором случае.
- В первом случае нажмите пункт меню "Отменить"
- Убедитесь, что второй экземпляр теперь отображает стартовую страницу.
- .................так далее..............
Каждый пример проверяет, что вы можете создать новый виджет. В третьем тесте я тестировал функциональность как опытный программист, думал: "Хорошо, где все места, где может появляться ошибка", и проверял каждый из них. Подходит ли третий для приемочных испытаний?
Насколько всеобъемлющий "слишком всеобъемлющий"?
6 ответов
Пользовательские приемочные тесты должны быть подробными и простыми, но не такими подробными, как ваш третий пример. Приемочное тестирование означает, что клиент получит то, на что он согласился. Если вы просто скажете: "Нажмите на это, затем на это, и т. Д. И т. Д.", Это больше похоже на функциональный тест. Вы не запрашиваете пользователей, чтобы убедиться, что функциональность соответствует тестовому примеру, изложенному в приемочном тесте. Вы только просите их пройти через тесты, которые вы могли бы просто автоматизировать.
Пользовательские приемочные тесты должны проводиться в духе "создания виджета, проверки его появления, удаления виджета и т. Д.". Это также побудит пользователей искать отдельные функции и (как побочный эффект) избавиться от любых проблем с юзабилити, которые вы, возможно, пропустили.
Я думаю, что ваши приемочные тесты должны быть в первую очередь хорошими тестами. Иногда "хороший" путь обеспечит правильную обработку ошибок. У вас должны быть другие тесты, которые подтверждают вашу безопасность и проверяют правильные случаи, но приемочный тест - это больше проверка того, что правильное приложение создано, чем проверка того, что каждое возможное условие обрабатывается правильно. Если у вас есть хорошие модульные тесты и вы используете лучшие практики, то я думаю, что хороший путь тестирования вполне уместен.
Например, я не обязательно проверял бы, что у меня нет проблем с внедрением SQL, если бы я использовал технологию, которая обеспечивает параметризованные запросы или когда я генерирую запросы вручную (я не делаю), что модульные тесты проверяют это инъекция не удалась. Учет угловых случаев в модульных тестах делает менее важным сосредоточиться на них в приемочных тестах. Если вам нужно привести для примера несколько примеров того, как ваша внутренняя реализация решает их проблемы, то обязательно сделайте это, но я бы не стал проверять то, что, как я знаю, адекватно решено с помощью другого тестирования.
Для меня это больше похоже на план тестирования функций (т.е. внутреннее тестирование)
Приемочные испытания обычно относятся к тому, что вы показываете покупателю. Я думаю, вы могли бы дать клиенту такой тест - удачи, хотя
Для тестирования приемлемости пользователей я предпочитаю очень простой формат (конечно, это, вероятно, не подойдет, скажем, для программного обеспечения космического челнока или банковского дела). Это хорошо для небольших и средних веб-проектов
Суть этого такова; создайте таблицу, в которой перечислены все страницы системы, затем создайте столбец для клиента на начальном и еще один для себя на начальном. Вы сидите с клиентом несколько часов и проходите через все. Если они довольны страницей, они подписывают ее
Для получения полной информации о шаблоне см.: Приемлемое тестирование пользователя.
Что говорит ваша спецификация? Если он охватывает все вещи, описанные в вашем третьем тестовом примере, то почему бы мне, как вашему клиенту, не захотеть видеть, что ваш продукт соответствует всей спецификации?
Если у вас нет явного набора требований (facepalm), разбейте тестирование на модули: квалификация (с заказчиком), интеграция (разработчики тестируют модули вместе) и разработка (разработчики тестируют отдельные модули).
Максимально автоматизируйте DT&E (например, используйте модульные тесты для проверки SQL-внедрения, переполнения строки и т. Д.). Это должно быть легко сделать, потому что ваш бэкэнд должен быть отделен от графического интерфейса пользователя, который с ним общается (верно?). Большая часть графического интерфейса, который вы описали в третьем тестовом примере, может быть рассмотрена в рамках Integration Testing (потому что вы действительно тестируете интеграцию между бэкендом и GUI).
Если клиент может просмотреть ваши модульные тесты, процедуры и результаты интеграционных тестов, то квалификационное тестирование может быть довольно простым и безболезненным.
В идеальном мире описание теста будет выглядеть так:
- Убедитесь, что все автоматизированные тесты успешно завершены
В каждом случае использования будет один автоматический тест для каждого пути.
Любая форма ручного тестирования по сценарию будет подвержена ошибкам и пропускает ошибки, не говоря уже о трудоемкости.
Они должны проверить нормальные случаи использования (не исключительный). Но если они тестируют исключительные, это очень круто!
Приемочные испытания не могут быть слишком подробными. Чем больше они тестируют, тем больше им нравится конечный продукт.