Должны ли критерии приемлемости пользовательской истории служить основой для тестовых случаев при тестировании этой функции?
Или должна быть отдельная история для тестирования, критерии приемки которой заключаются в том, что тестируемая функция проходит соответствующий раздел спецификации функции?
Например:
История: Как пользователь, я хочу нажать кнопку «Показать карту», которая покажет карту Google с отмеченным адресом, о котором сообщается, чтобы я мог визуализировать, где происходит событие.
Каковы могут быть критерии приемлемости и как это будет связано с тестированием?
TL;DR
Критерии приемки должны быть частью тематической истории и основой для тестовых случаев. Не должно быть отдельной тестовой истории, они могут быть подзадачей истории!
Длинный ответ
Должны ли критерии приемлемости пользовательской истории служить основой для тестовых случаев при тестировании этой функции?
Конечно должны быть! Вы определяете, какие критерии должны быть соблюдены, чтобы история соответствовала своему варианту использования. Эти критерии должны быть проверены, чтобы убедиться, что история сделана. Это означает, что вы должны реализовать различные виды тестов (модульные тесты, регрессионные тесты...).
Или должна быть отдельная история для тестирования, критерии приемки которой заключаются в том, что тестируемая функция проходит соответствующий раздел спецификации функции?
В руководстве по Scrum очень ясно говорится об этом при определении термина «Готово»: «Каждое приращение… тщательно тестируется, чтобы убедиться, что все приращения работают вместе». Это означает, что история завершена, когда все задачи выполнены, включая тестирование. Так что никакой дополнительной истории или даже дополнительной команды для этого!
Пример
Каковы могут быть критерии приемлемости и как это будет связано с тестированием?
Я изменил ваш пример истории, удалив детали реализации, должны быть описаны только потребности клиента. «Клик-часть» перемещена в критерии приемки.
История
Как пользователь, я хочу иметь возможность отображать карту с отмеченным сообщенным адресом, чтобы я мог визуализировать, где происходит событие.
Критерии приемлемости
Теперь следует проверить эти критерии, постарайтесь подумать о сценариях с солнечным светом и распространенных ошибках — не забывайте о пограничных случаях.
Я не знаю вашего приложения, поэтому я стараюсь, чтобы оно было общим. У вас есть какие-то пользовательские тесты, когда товарищ по команде щелкает приложение и нажимает кнопку «Показать карту» (появляется отмеченная карта). Еще одна вещь - убедиться, что API карт Google может понять формат вашего адреса (может быть автоматизирован), или вы проверяете, что происходит, если Карты Google не работают. Кроме того, у вас есть какие-то модульные тесты, которые могут проверить, что происходит, когда поле адреса пусто.
В чем тогда разница с пользовательскими историями?
Вы также можете определить следующие пользовательские истории вместо «критериев приемлемости»:
Как пользователь мне нужна кнопка «Показать карту», чтобы я мог открыть представление карты (карты Google) Как пользователь я ожидаю, что указанный адрес будет отмечен на карте Как пользователь я хочу, чтобы кнопка «Показать карту» была отключена, когда не указан адрес
Упрощает планирование, расстановку приоритетов и отслеживание реализации.
Пользовательская история должна быть написана с упором на ценность для бизнеса, а не на функциональность.
Например, как пользователю, мне нужна возможность видеть место события на карте Google, чтобы я мог визуализировать местоположение.
Вы можете написать определенные функции, которые пользователь ожидает как критически важные.
Например, карта должна отображаться/всплывать, когда пользователь нажимает кнопку «показать карту».
Команда тестировщиков может проверять отдельные критерии приемлемости при тестировании истории.
Например, тестер может нажать на кнопку, чтобы убедиться, что на карте отображается свойство.
ДизайнерАналитик