Следуя подходу agile, мы хотим работать итеративно и иметь возможность частых выпусков.
Это может сделать традиционную UAT сложной задачей.
Есть много из методов, которые могут помочь, таких как:
- Обеспечение высокого качества вашего процесса сборки, например, с помощью автоматического регрессионного тестирования, непрерывной интеграции и т. д. c. Это помогает снизить риск появления дефектов, достигающих стадии UAT.
- Использование чего-то вроде поведенческой разработки (BDD), которая определяет работу по ожидаемому поведению. Это помогает уменьшить потребность в UAT и в некоторых случаях может устранить ее.
- Тщательно спланируйте, как и когда происходит UAT, чтобы он мог вписаться в процесс итеративного выпуска.
Например, одна команда Scrum, с которой я работал, использовала следующий подход к UAT:
У них была специальная среда UAT, и она выпускала ее на протяжении всего спринта. Всякий раз, когда они делали релиз для среды UAT, они выпускали примечание к выпуску, в котором подробно описывалось, какие функции были изменены / добавлены.
Тестеры UAT были из-за пределов ИТ. В их календарях есть слоты, посвященные тестированию UAT. Например, некоторые из них имели двухчасовой интервал во вторник и пятницу каждую неделю.
Механизм обеспечения обратной связи от UAT был максимально автоматизирован. Команды разработчиков будут реагировать на обратную связь UAT очень быстро и будут либо:
- Внести изменения в код
- Исправить любые дефекты
- Откатить изменение функции и график это для более позднего спринта