Приёмочное тестирование: проверка соответствия требованиям и критериям приемки.

Введение

Испытание для определения соответствия требованиям спецификации или контракта.

В инженерии и ее различных областях приемные испытания – это испытание, проводимое для определения соответствия требованиям спецификации или контракта. Они могут включать химические, физические или функциональные испытания. В системной инженерии это может быть тестирование «черного ящика», выполняемое над системой (например, над программным обеспечением, партиями изготовленных механических деталей или партиями химической продукции) перед ее поставкой. В тестировании программного обеспечения ISTQB определяет приемные испытания как: финальное испытание в цикле обеспечения качества, пользовательское приемочное тестирование, которое проводится непосредственно перед окончательным выпуском для оценки способности продукта или приложения обрабатывать реальные сценарии. Путем имитации поведения пользователя оно проверяет, удовлетворяет ли система бизнес-требованиям, и отклоняет изменения, если определенные критерии не выполняются. Некоторые формы приемных испытаний включают пользовательское приемочное тестирование (UAT), тестирование конечными пользователями, операционное приемочное тестирование (OAT), разработку, управляемую приемочными тестами (ATDD), и полевые (приемочные) испытания. Критерии приемки – это условия, которым система или компонент должны соответствовать, чтобы быть принятыми пользователем, заказчиком или другим уполномоченным лицом.

Обзор

Тестирование — это набор действий, выполняемых для выявления и/или оценки характеристик одного или нескольких тестируемых объектов. Каждый тест, известный как тест-кейс, включает в себя набор предопределенных тестовых действий, разработанных для приведения тестируемого объекта в соответствие с целями тестирования, включая корректную реализацию, обнаружение дефектов, проверку качества и другие важные аспекты. Критерии приемочного тестирования пользователями (UAT) (в гибкой разработке программного обеспечения) обычно создаются бизнес-заказчиками и формулируются на языке бизнес-области. Это высокоуровневые тесты для проверки полноты пользовательской истории или историй, реализованных в ходе любого спринта/итерации. Критерии операционного приемочного тестирования (OAT) (независимо от использования гибкой, итеративной или последовательной модели разработки) определяются на основе функциональных и нефункциональных требований, охватывающих ключевые атрибуты качества, такие как функциональная стабильность, переносимость и надежность.

Процесс

Комплекс приемочных испытаний может потребоваться выполнить несколько раз, поскольку не все тестовые случаи могут быть выполнены в рамках одной итерации испытаний. Комплекс приемочных испытаний проводится с использованием заранее определенных процедур приемочных испытаний, чтобы указать тестировщикам, какие данные использовать, последовательность шагов для выполнения и ожидаемый результат после выполнения. Фактические результаты сохраняются для сравнения с ожидаемыми результатами. Это не системное тестирование (обеспечение того, что программное обеспечение не аварийно завершает работу и соответствует задокументированным требованиям), а скорее проверка того, что решение будет работать для пользователя (то есть, что пользователь примет решение); поставщики программного обеспечения часто называют это "бета-тестированием". Данное тестирование должно проводиться предполагаемым конечным пользователем или экспертом в предметной области (SME), предпочтительно владельцем или клиентом тестируемого решения, и предоставлять сводку результатов для подтверждения возможности продолжения после испытаний или проверки. В разработке программного обеспечения UAT, как один из заключительных этапов проекта, часто происходит перед тем, как клиент или заказчик принимает новую систему. Пользователи системы выполняют тесты, соответствующие реальным сценариям использования. Материалы, предоставляемые тестировщику, должны быть аналогичны материалам, которые будут доступны конечному пользователю. Тестировщикам следует предоставить реальные сценарии, например, три наиболее распространенных или сложных задачи, которые будут выполнять пользователи, которых они представляют. UAT служит окончательной проверкой требуемой бизнес-функциональности и корректной работы системы, имитируя реальные условия от имени платящего клиента или конкретного крупного заказчика. Если программное обеспечение работает в соответствии с требованиями и без сбоев при нормальном использовании, можно обоснованно экстраполировать тот же уровень стабильности в производственной среде. Пользовательские тесты, обычно выполняемые клиентами или конечными пользователями, как правило, не фокусируются на выявлении простых косметических проблем, таких как опечатки, или критических дефектов, таких как сбои программного обеспечения; тестировщики и разработчики выявляют и устраняют эти проблемы на более ранних этапах модульного тестирования, интеграционного тестирования и системного тестирования. UAT следует проводить на основе тестовых сценариев. Тестовые сценарии обычно отличаются от системных или функциональных тестовых случаев тем, что они представляют собой путь "пользователя" или "клиента". Широкий охват тестового сценария обеспечивает фокусировку на пути, а не на технических или системных деталях, избегая пошаговых инструкций для тестирования, чтобы учесть вариативность поведения пользователей. Тестовые сценарии можно разбить на логические "дни", которые обычно соответствуют смене действующего лица (пользователя/клиента/оператора) или системы (бэк-офис, фронт-энд). В промышленности распространенным видом приемочных испытаний является заводское приемочное тестирование (FAT). Это тестирование проводится перед установкой оборудования. В большинстве случаев тестировщики проверяют не только соответствие оборудования спецификациям, но и его полную функциональность. FAT обычно включает проверку комплектности, верификацию соответствия договорным требованиям, подтверждение функциональности (либо путем моделирования, либо традиционным функциональным тестированием) и окончательную инспекцию. Результаты этих испытаний дают клиентам уверенность в том, как система будет работать в производственной среде. Также могут существовать юридические или договорные требования к приемке системы.

The acceptance test suite may need to be performed multiple times, as all of the test cases may not be executed within a single test iteration. The acceptance test suite is run using predefined acceptance test procedures to direct the testers on which data to use, the step by step processes to follow, and the expected result following execution. The actual results are retained for comparison with the expected results. It is not system testing (ensuring software does not crash and meets documented requirements) but rather ensures that the solution will work for the user (i. e. tests that the user accepts the solution); software vendors often refer to this as "Beta testing". This testing should be undertaken by the intended end user, or a subject matter expert (SME), preferably the owner or client of the solution under test, and provide a summary of the findings for confirmation to proceed after trial or review. In software development, UAT as one of the final stages of a project often occurs before a client or customer accepts the new system. Users of the system perform tests in line with what would occur in real life scenarios. The materials given to the tester must be similar to the materials that the end user will have. Testers should be given real life scenarios such as the three most common or difficult tasks that the users they represent will undertake. The UAT acts as a final verification of the required business functionality and proper functioning of the system, emulating real world conditions on behalf of the paying client or a specific large customer. If the software works as required and without issues during normal use, one can reasonably extrapolate the same level of stability in production. User tests, usually performed by clients or by end users, do not normally focus on identifying simple cosmetic problems such as spelling errors, nor on showstopper defects, such as software crashes; testers and developers identify and fix these issues during earlier unit testing, integration testing, and system testing phases. UAT should be executed against test scenarios. Test scenarios usually differ from System or Functional test cases in that they represent a "player" or "user" journey. The broad nature of the test scenario ensures that the focus is on the journey and not on technical or system specific details, staying away from "click by click" test steps to allow for a variance in users' behaviour. Test scenarios can be broken down into logical "days", which are usually where the actor (player/customer/operator) or system (backoffice, front end) changes. In industry, a common UAT is a factory acceptance test (FAT). This test takes place before the installation of the equipment. Most of the time testers not only check that the equipment meets the specification but also that it is fully functional. A FAT usually includes a check of completeness, a verification against contractual requirements, a proof of functionality (either by simulation or a conventional function test), and a final inspection. The results of these tests give clients confidence in how the system will perform in production. There may also be legal or contractual requirements for acceptance of the system.

Испытания на приемку в эксплуатацию

Операционное приемочное тестирование (OAT) используется для проверки операционной готовности (предварительной подготовки к выпуску) продукта, услуги или системы в рамках системы управления качеством. OAT является распространенным типом нефункционального тестирования программного обеспечения, применяемым преимущественно в проектах разработки и сопровождения программного обеспечения. Этот вид тестирования фокусируется на готовности системы к эксплуатации и/или включению в производственную среду.

Тестирование приемлемости в экстремальном программировании

Приемочное тестирование — это термин, используемый в гибких методологиях разработки программного обеспечения, в частности в экстремальном программировании, обозначающий функциональное тестирование пользовательской истории командой разработки программного обеспечения в процессе реализации. Заказчик определяет сценарии для проверки корректности реализации пользовательской истории. Пользовательская история может иметь один или несколько приемочных тестов, в зависимости от того, что необходимо для подтверждения работоспособности функциональности. Приемочные тесты являются системными тестами «черного ящика». Каждый приемочный тест представляет собой ожидаемый результат работы системы. Заказчики отвечают за проверку корректности приемочных тестов и анализ результатов тестирования, чтобы определить приоритетность неудачных тестов. Приемочные тесты также используются в качестве регрессионных тестов перед выпуском в продуктивную среду. Пользовательская история считается завершенной только после успешного прохождения всех приемочных тестов. Это означает, что для каждой итерации необходимо создавать новые приемочные тесты, иначе команда разработки сообщит об отсутствии прогресса.

Критерии принятия

Согласно Институту управления проектами, критерии приемки – это "набор условий, которым необходимо соответствовать до того, как будут приняты результаты работы". Требования, указанные в критериях приемки для конкретного компонента системы, как правило, очень детализированы.