Пользовательское приемочное тестирование — это заключительный этап проверки, на котором представители компании или пользовательского сообщества подтверждают, что система соответствует требованиям, для удовлетворения которых она была разработана, и пригодна для использования по назначению. Оно проводится после функционального тестирования, как правило, в среде, максимально приближенной к производственной, и по его результатам принимается решение о выпуске системы в эксплуатацию.
Это отвечает на вопрос, отличный от вопросов, возникающих при предыдущем тестировании. Тестирование разработчиками и обеспечением качества устанавливают, ведет ли себя система в соответствии со спецификацией; приемочное тестирование устанавливает, действительно ли то, что было указано, соответствует потребностям бизнеса. Работа может пройти все функциональные тесты, но при этом не пройти приемочное тестирование, потому что спецификация была неполной, потому что процесс был неправильно понят или потому что не был учтен реальный сценарий, который никто не задокументировал.
Наиболее распространенная путаница возникает между приемочным тестированием и тестированием удобства использования. Приемочное тестирование проводится людьми, знакомыми с бизнес-процессом, которые прорабатывают различные сценарии, чтобы подтвердить, что система их поддерживает. Тестирование удобства использования предполагает наблюдение за репрезентативными пользователями, которые взаимодействуют с продуктом без посторонней помощи, чтобы выяснить, можно ли его понять и использовать. Замена одного другим — серьезная ошибка: система может быть принята знающими заинтересованными сторонами, но остаться непригодной для использования теми, для кого она была создана.
Выбор участников определяет, что именно может выявить данное упражнение. Тестирование, проводимое проектной командой или заинтересованными сторонами, которые были вовлечены в процесс на протяжении всего его выполнения и знают, как должна работать система, подтверждает, что разработанная система соответствует общему пониманию и не выявляет ничего противоречащего этому. Привлечение людей, которые будут непосредственно работать с системой и которые не участвовали в обсуждении проекта, выявляет расхождения между запланированным и фактическим процессом.
Разработка сценариев должна основываться на реальной работе, а не на списках функций. Проверка операционных задач, которые должна поддерживать система, включая сложные исключения, составляющие значительную часть реальной практики, позволяет выявить проблемы, которые не обнаруживаются при проверке каждой функции по отдельности. Реалистичные данные имеют не меньшее значение, поскольку системы, корректно работающие с чистыми тестовыми данными, часто дают сбои на некорректных, неполных и необычных записях, содержащихся в производственной среде.
Этап структурно уязвим для сжатия, поскольку он находится в конце графика, который, как правило, уже сдвинулся с графика. Приемочное тестирование затем проводится за гораздо меньшее время, чем планировалось, участниками, которые втискивают его в свои обычные обязанности, а обнаруженные дефекты сортируются для исправления после запуска. Планирование его с реалистичной продолжительностью, заблаговременное обеспечение времени участников и предварительное согласование серьезности обнаруженных дефектов, которые могут задержать релиз, — вот что предотвращает превращение его в формальность.
Критерии сортировки дефектов следует согласовывать до начала тестирования, а не обсуждать под давлением после получения результатов. Определение того, какие категории проблем препятствуют выпуску продукта, какие устраняются немедленно после этого, а какие фиксируются для последующего анализа, позволяет избежать споров в момент, когда коммерческое давление с целью продолжения тестирования наиболее велико, а оценка наименее надежна.
Поскольку приемка подтверждает пригодность системы для бизнес-целей, но ничего не говорит о том, смогут ли конечные пользователи фактически использовать систему, необходимы обе формы проверки. На практике этап приемки планируется в рамках разработка продукта в рамках процесса выпуска, в то время как отдельный вопрос о том, смогут ли реальные пользователи выполнить свои задачи, решается посредством пользовательское исследованиеА для внутренних систем реализм сценариев в операционном плане обычно зависит от вовлечения ИТ отдел а также команды, которые будут поддерживать систему после запуска.