_test_the_ship's_catapult_systems_during_acceptance_trials.jpg/1280px-thumbnail.jpg)
В инженерии и ее различных поддисциплинах приемочные испытания — это тесты, проводимые для определения того, выполняются ли требования спецификации или контракта . Они могут включать химические испытания , физические испытания или эксплуатационные испытания . [1]
В системной инженерии это может включать тестирование методом черного ящика, проводимое на системе (например, части программного обеспечения , множестве изготовленных механических деталей или партиях химических продуктов) перед ее поставкой. [2]
В тестировании программного обеспечения ISTQB определяет приемочное тестирование как :
Формальное тестирование с учетом потребностей, требований и бизнес-процессов пользователей, проводимое для определения того, удовлетворяет ли система критериям приемки [3] , и предоставления возможности пользователю, клиентам или другому уполномоченному органу решить, следует ли принимать систему.
— Стандартный глоссарий терминов, используемых в тестировании программного обеспечения [4] : 2
Финальный тест в жизненном цикле QA, тестирование пользовательского принятия, проводится непосредственно перед финальным релизом, чтобы оценить, может ли продукт или приложение справиться с реальными сценариями. Воспроизводя поведение пользователя, он проверяет, удовлетворяет ли система бизнес-требованиям, и отклоняет изменения, если определенные критерии не выполняются. [5]
Некоторые формы приемочного тестирования: приемочное тестирование пользователем (UAT), тестирование конечным пользователем, приемочное тестирование эксплуатацией (OAT), разработка на основе приемочных испытаний (ATDD) и полевые (приемочные) испытания. Критерии приемки — это критерии, которым система или компонент должны соответствовать, чтобы быть принятыми пользователем, заказчиком или другим уполномоченным лицом. [6]
Тестирование — это набор действий, проводимых для облегчения обнаружения и/или оценки свойств одного или нескольких тестируемых элементов. [7] Каждый тест, известный как тестовый случай, выполняет набор предопределенных тестовых действий, разработанных для управления выполнением тестового элемента для достижения целей тестирования; включая правильную реализацию, идентификацию ошибок, проверку качества и другие ценные детали. [7] Тестовая среда обычно разрабатывается так, чтобы быть идентичной или максимально приближенной к ожидаемой производственной среде. Она включает в себя все объекты, оборудование, программное обеспечение, встроенное ПО, процедуры и/или документацию, предназначенные или используемые для выполнения тестирования программного обеспечения. [7]
Тестовые случаи UAT и OAT в идеале разрабатываются в сотрудничестве с бизнес-клиентами, бизнес-аналитиками, тестерами и разработчиками. Эти тесты должны включать как тесты бизнес-логики, так и условия операционной среды. Бизнес-клиенты (владельцы продукта) являются основными заинтересованными сторонами этих тестов. Поскольку условия тестирования успешно достигают своих критериев приемки, заинтересованные стороны уверены, что разработка движется в правильном направлении. [8]
Возможно, набор приемочных тестов придется выполнять несколько раз, поскольку все тестовые случаи не всегда могут быть выполнены в течение одной итерации теста. [9]
Набор приемочных тестов запускается с использованием предопределенных процедур приемочных тестов, чтобы указать тестировщикам, какие данные использовать, какие пошаговые процессы выполнять и какой результат ожидать после выполнения. Фактические результаты сохраняются для сравнения с ожидаемыми результатами. [9] Если фактические результаты соответствуют ожидаемым результатам для каждого тестового случая, то считается, что тестовый случай пройден. Если количество не прошедших тестовых случаев не превышает предопределенного порогового значения проекта, то считается, что тестовый набор пройден. Если это так, то система может быть отклонена или принята на условиях, предварительно согласованных между спонсором и производителем.
Ожидаемый результат успешного проведения теста:
Целью является обеспечение уверенности в том, что разработанный продукт соответствует как функциональным, так и нефункциональным требованиям. Цель проведения приемочного тестирования заключается в том, что после его завершения и при условии соблюдения критериев приемки ожидается, что спонсоры подпишут разработку/улучшение продукта как удовлетворяющее определенным требованиям (заранее согласованным между бизнесом и поставщиком/разработчиком продукта).
Тестирование пользовательского принятия (UAT) представляет собой процесс проверки того, что решение работает для пользователя. [10] Это не системное тестирование (гарантия того, что программное обеспечение не дает сбоев и соответствует документированным требованиям), а скорее проверка того, что решение будет работать для пользователя (т. е. проверка того, что пользователь принимает решение); поставщики программного обеспечения часто называют это «бета-тестированием».
Это тестирование должно проводиться предполагаемым конечным пользователем или экспертом по предметной области (SME), желательно владельцем или клиентом тестируемого решения, и предоставлять сводку результатов для подтверждения продолжения после испытания или обзора. В разработке программного обеспечения UAT как один из заключительных этапов проекта часто происходит до того, как клиент или заказчик принимает новую систему. Пользователи системы выполняют тесты в соответствии с тем, что будет происходить в реальных сценариях. [11]
Материалы, предоставленные тестировщику, должны быть похожи на материалы, которые будут у конечного пользователя. Тестировщикам следует предоставить реальные сценарии, такие как три наиболее распространенные или сложные задачи, которые будут выполнять пользователи, которых они представляют. [12]
UAT выступает в качестве окончательной проверки требуемой функциональности бизнеса и надлежащего функционирования системы, имитируя реальные условия от имени платящего клиента или конкретного крупного клиента. Если программное обеспечение работает так, как требуется, и без проблем при нормальном использовании, можно обоснованно экстраполировать тот же уровень стабильности в производстве. [13]
Пользовательские тесты, обычно выполняемые клиентами или конечными пользователями, обычно не фокусируются на выявлении простых косметических проблем, таких как орфографические ошибки, или на серьезных дефектах, таких как сбои программного обеспечения ; тестировщики и разработчики выявляют и устраняют эти проблемы на ранних этапах модульного тестирования , интеграционного тестирования и системного тестирования.
UAT следует выполнять по сценариям тестирования. [14] [15] Сценарии тестирования обычно отличаются от системных или функциональных тестовых случаев тем, что они представляют собой путешествие «игрока» или «пользователя». Широкий характер сценария тестирования гарантирует, что внимание сосредоточено на путешествии, а не на технических или системно-специфических деталях, избегая шагов тестирования «щелчок за щелчком», чтобы допустить вариативность в поведении пользователей. Сценарии тестирования можно разбить на логические «дни», которые обычно являются временем изменения актера (игрока/клиента/оператора) или системы (бэк-офиса, фронтенда). [16]
В промышленности обычным UAT является заводское приемочное испытание (FAT). Это испытание проводится перед установкой оборудования. В большинстве случаев тестировщики не только проверяют, соответствует ли оборудование спецификации, но и полностью ли оно функционально. FAT обычно включает проверку полноты, проверку на соответствие договорным требованиям, доказательство функциональности (путем моделирования или обычного функционального испытания) и окончательную проверку. [17] Результаты этих испытаний дают клиентам уверенность в том, как система будет работать в производстве. Также могут быть юридические или договорные требования к приемке системы.
Эксплуатационное приемочное тестирование (OAT) используется для проведения эксплуатационной готовности (предварительного выпуска) продукта, услуги или системы как части системы управления качеством . OAT — это распространенный тип нефункционального тестирования программного обеспечения , используемый в основном в проектах по разработке и обслуживанию программного обеспечения . Этот тип тестирования фокусируется на эксплуатационной готовности системы, которая будет поддерживаться и/или станет частью производственной среды. [18]
Приемочное тестирование — термин, используемый в гибких методологиях разработки программного обеспечения, в частности в экстремальном программировании , и относящийся к функциональному тестированию пользовательской истории командой разработчиков программного обеспечения на этапе внедрения. [19]
Заказчик указывает сценарии для тестирования, когда пользовательская история была правильно реализована. История может иметь один или несколько приемочных тестов, все, что нужно для обеспечения работы функциональности. Приемочные тесты — это системные тесты черного ящика. Каждый приемочный тест представляет собой некоторый ожидаемый результат от системы. Заказчики несут ответственность за проверку правильности приемочных тестов и просмотр результатов тестов, чтобы решить, какие неудачные тесты имеют наивысший приоритет. Приемочные тесты также используются в качестве регрессионных тестов перед выпуском в производство. Пользовательская история не считается завершенной, пока она не пройдет приемочные тесты. Это означает, что для каждой итерации должны быть созданы новые приемочные тесты, иначе команда разработчиков сообщит об отсутствии прогресса. [20]
Типичные типы приемочных испытаний включают в себя следующее:
По данным Института управления проектами , критерии приемки — это «набор условий, которые необходимо выполнить, прежде чем результаты будут приняты». [26] Требования, содержащиеся в критериях приемки для определенного компонента системы, обычно очень подробны. [27]