Критерии Приёмки

Критерии Приёмки (здесь и далее по тексту -- Лектио) -- это часть урока Суть Приёмки Работ. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.

Материалы

Предшественник этого Лектио -- Проверки и Приёмки.

Текст

Критерии Приёмки

И проверка, и приёмка подразумевают тестирование изделия. Однако приёмка отличается от проверки и проверка отличается от приёмки.

Существуют два схожих по себе определения для проверки и подтверждения. Оба, вероятно, включают Тестирование, чтобы установить истину или подлинность чего-либо. Однако эти определения имеют отличия. В управлении проектами и системном проектировании верификация и валидация -- это отдельные процессы.

Представьте, что вы припарковали свой автомобиль на стоянке, находясь в деловой поездке. Вы знаете, что общество должно платить за парковку, но этот конкретный бизнес покрывает плату за парковку для своих клиентов. Если компания подтвердит вашу парковку, ваша парковка будет бесплатной. Сопровождающий на парковке может проверить квитанцию, но не может. Если ваша парковка не подтверждена, вы должны заплатить.

Разберемся с определением Верификации. Верификация -- это проверка и подтверждение определенных выполненных требований. А Валидация -- проверка и ожидания, что продукт отвечает потребностям пользователей.

Чтобы верифицировать рабочий продукт, необходимо убедиться, что произведенный продукт соответствует его спецификациям и другим требованиям. Для проверки необходимо убедиться, что продукт решает проблемы, которые он должен был решить.

Применительно к вновь построенному самолету проверка заключается в том, чтобы убедиться, что самолет произведен так, как был спроектирован. Чтобы подтвердить летную годность самолета, он должен летать. Испытательный полет подтвердит не только то, что самолет построен в соответствии со своими спецификациями, но также и то, что его характеристики соответствуют требованиям.

Проще говоря, проверка не отвечает на вопрос, правильно ли разработан продукт, а проверка отвечает на вопрос, правильный ли продукт разработан. Подведем итог, Верификация - проверка наличия чего-то, а Валидация -- работоспособность чего-либо.

Например, проверка этой самой lectio, которую вы сейчас читаете или слушаете, будет включать в себя определение ее требований и проверку того, выполняются ли все эти требования. Однако только ваше понимание разницы между верификацией и валидацией может подтвердить это. Если многие учащиеся не осознают разницу, необходимо пересмотреть требования и обновить lectio.

Приемочные испытания могут включать, как верификацию, так и валидацию. Внутренние заинтересованные стороны обычно проверяют, соответствует ли разработанный продукт критериям приемки, прежде чем предлагать клиенту подтвердить свои выводы. Заказчики или их представители обычно подтверждают, принимают ли они продукт от его разработчиков. Проверка клиента также может включать проверку. Другими словами, Приёмка -- это некие испытания включая Верификацию и Валидацию в соответствии с Требованиями заказчика. Однако третьи стороны также могут проводить Верификацию и/или Валидацию.

Во-первых, закон может налагать некоторые ограничения. Например, клиент может быть готов купить вакцину, но если эта вакцина не была одобрена Управлением по контролю за продуктами и лекарствами (FDA), ее нельзя продавать в Соединенных Штатах. Важной частью процесса утверждения FDA является подтверждение его полезных и вредных эффектов. Во-вторых, внешние заинтересованные стороны, особенно независимые третьи стороны, могут запускать любой или оба процесса, будучи приглашенными любой стороной или когда две стороны спорят по поводу результата Тестирования.

Наконец, некоторые Проверки зависят от использования продуктов конечными пользователями и их производительности.

А Нефункциональные тесты оценивают производительность групп разработчиков и готовность рабочего продукта к передаче, установке, запуску и, возможно, обслуживанию. То есть нефункциональное тестирование показывает "как" система работает. К примеру, тест на нагрузку, стресс.

Что касается интеграций или фаз разработки, функциональные тесты можно разделить на две категории: прогрессивные тесты и регрессионные тесты.

Те пользовательские истории, которые использовались для последней разработки, можно идеально использовать для тестирования прогресса. Обычно эти истории включают в себя любые приемочные испытания. И наоборот, те пользовательские истории, которые использовались для всех разработок, предшествовавших предыдущей, можно идеально использовать для регрессионного тестирования.

Специально организованное Тестирование может затрагивать конкретные проблемы или области, требующие улучшения. Например, рабочее тестирование продукта оценивает функциональность рабочих продуктов, производительность тех команд, которые их разработали, и/или другие результаты разработки. Юзабилити-тестирование направлено на поиск областей для улучшения и удобства пользовательского опыта (UX). Приемочные испытания проводятся для проверки того, соответствует ли разработанная система требованиям завершения, обычно называемым критериями приемки. То есть готов ли продукт для следующей эксплуатации.

Большинство Ручных Тестов включает в себя контроль того, соответствует ли рабочий продукт его требованиям, поиск ошибок, проблем с пользовательским интерфейсом и/или областей для улучшений при ручном выполнении действий на веб-сайте, мобильном приложении или другом приложении конечного пользователя.

Термины

Верификация, Валидация, Проверка, Приемка, Требования

Вопрос(ы)

Исходя из выше описанного текста: Проверка отвечает на вопрос, был ли разработан правильный продукт, так как он решает проблемы, которые должен был решить. -- Правда/Неправда

Следующее лектио -- Что Есть Отчетность