Test the system before launchПроверка системы перед запуском
A working screen demonstrates that a function opens. Acceptance testing asks whether a specific role can take an operational situation to the required result. That needs known starting data, an expected outcome and execution evidence, including cases where work must stop or pass to another person.Показ работающего экрана отвечает на вопрос, открывается ли функция. Приёмочная проверка отвечает на другой: сможет ли конкретная роль довести рабочую ситуацию до нужного результата. Для этого нужны известные исходные данные, ожидаемый итог и свидетельство выполнения, включая случаи, когда действие должно остановиться или перейти к другому сотруднику.
Connect tests to operational risksСвязать проверки с рабочими рисками
The test lead develops scenarios with process owners. Each scenario references a requirement: accept an order, change it before fulfillment, complete work or deny a prohibited action. Prioritize cases where failure changes a customer commitment, data or actual execution. A screen check cannot replace the complete path for these cases. An infrequent scenario can still be mandatory.Ответственный за проверку собирает сценарии вместе с владельцами процессов. Каждый сценарий ссылается на требование: принять заказ, изменить его до исполнения, закрыть работу или отказать в запрещённом действии. Сначала выделите случаи, ошибка в которых меняет обязательство перед клиентом, данные или фактическое исполнение. Для них нельзя заменять полный путь проверкой отдельного экрана. Редко используемый сценарий тоже может быть обязательным.
For each requirement, identify the normal path, exception and role that accepts the outcome. Cancellation differs from creation, and partial fulfillment differs from full completion. Make missing scenarios visible in the register. A large number of simple passing tests cannot compensate for an untested handoff needed to complete an order.Для каждого требования отметьте обычный путь, исключение и роль, подтверждающую итог. Проверка отмены отличается от проверки создания, а частичное исполнение от полного. В реестре должны быть видны отсутствующие сценарии. Большое число простых успешных проверок не компенсирует непроверенную передачу, без которой заказ нельзя завершить.
Derive scenarios from the workflow mapПолучить сценарии из карты процесса
Prepare repeatable test conditionsПодготовить повторяемые условия
A test case contains the starting state, role, action sequence and expected record changes. Use fictional or appropriately anonymized data with a known result. Record the configuration version, language, device and connected components where relevant. Before executing, verify the destination of messages and external actions so a test operation does not become an accidental live order.Карточка проверки включает исходное состояние, роль, последовательность действий и ожидаемые изменения записей. Используйте вымышленные или согласованно обезличенные данные с известным результатом. Запишите версию конфигурации, язык, устройство и подключённые компоненты, если они влияют на работу. Перед запуском теста проверьте назначение сообщений и внешних действий, чтобы тестовая операция не стала случайным рабочим заказом.
Decide how to return data to the starting state or create a fresh independent set for a rerun. Reusing a completed order changes the conditions and may conceal a defect. Mark a scenario blocked when a required component is unavailable. Testing in a substitute environment can help, but its differences from the intended operational environment must remain explicit.Заранее определите, как вернуть данные к исходному состоянию или создать новый независимый набор для повтора. Повторное использование уже завершённого заказа меняет условия и может скрыть ошибку. Если обязательный компонент недоступен, отмечайте сценарий как заблокированный. Проверка на заменяющей среде полезна, но её отличие от будущего рабочего окружения должно остаться явным.
Inspect the outcome beyond the screenПроверить результат за пределами экрана
The operator executes under the operational role while the reviewer compares the result with expectations. Beyond a success message, inspect the changed record, receiving-side state and required document. Device tests need the actual output: readable printing, required fields and content that is not clipped. Retain a test-record reference and enough outcome evidence for another person to review.Исполнитель проходит сценарий под рабочей ролью, а проверяющий сравнивает результат с ожиданием. Помимо сообщения об успехе проверьте изменённую запись, состояние на принимающей стороне и нужный документ. Для устройств важен фактический вывод: читаемая печать, нужные поля и отсутствие обрезанного содержания. Сохраняйте ссылку на тестовую запись и подтверждение результата, достаточное для повторного разбора.
Include repeated submission, stale data, an interrupted response and denied access. Check whether the next permitted step is understandable as well as whether an error appears. When the first attempt has an uncertain outcome, the team must be able to establish its state before retrying. Treat these scenarios as requirements to test, without assuming the system already supports the desired behavior.Добавьте повторное нажатие, устаревшие данные, прерванный ответ и отказ в доступе. Проверяйте не только наличие ошибки, но и то, понятен ли следующий допустимый шаг. При неизвестном результате первой попытки команда должна уметь выяснить её состояние до повтора. Эти сценарии формулируют как требования к проверке, не предполагая заранее, что система поддерживает нужное поведение.
Close defects with a verified rerunЗакрывать ошибку повторной проверкой
A defect report identifies the scenario, data, reproduction step, expected result and actual result. Describe impact concretely: an order cannot complete, the wrong record changes or a document lacks a required field. Record any temporary workaround and its limits separately. A workaround does not establish that the defect is fixed or acceptable for operational launch.В сообщении об ошибке укажите сценарий, данные, шаг воспроизведения, ожидаемый и фактический результат. Влияние описывают конкретно: нельзя завершить заказ, меняется неверная запись или документ не содержит нужного поля. Отдельно фиксируют временный обходной путь и его ограничения. Наличие обхода не означает, что сам дефект исправлен или приемлем для рабочего запуска.
After a configuration change, the reviewer reruns the original case under clean conditions and then related cases. A cancellation fix may affect partial completion or transfer to another system. Retain the fix version and rerun outcome. “Fix applied” and “test passed” must remain distinct statuses, even when the register is a simple spreadsheet.После изменения настройки проверяющий повторяет исходный сценарий на чистых условиях, затем связанные случаи. Исправление отмены может затронуть частичное завершение или передачу в соседнюю систему. Сохраните версию исправления и итог повторной проверки. Статусы «исправление внесено» и «проверка пройдена» должны различаться, даже если реестр ведётся в простой таблице.
Make acceptance an evidenced decisionПринять решение с перечнем ограничений
The process owner accepts the mandatory scenario results and unresolved limitations rather than an overall pass percentage. Show failed, blocked and unexecuted tests separately. An accepted limitation needs an accountable decision, a workable handling method and a condition for reconsideration. A mandatory outcome without evidence cannot be marked ready simply because its planned date has arrived.Владелец процесса принимает не общий процент успеха, а результаты обязательных сценариев и перечень нерешённых ограничений. Непройденные, заблокированные и не выполненные проверки показывают отдельно. Для допустимого ограничения нужны ответственное решение, рабочий способ обработки и условие повторного рассмотрения. Если обязательный результат не подтверждён, его нельзя считать готовым только из-за даты в плане.
Hand the launch lead an acceptance package containing scope, versions, outcomes, open issues and owners. For SABSUS, confirm the available test environment and evidence methods in the selected configuration. If rules, data or integrations change after acceptance, identify affected scenarios and repeat them before using the changed operational route.Передайте пакет приёмки руководителю запуска: область проверки, версии, результаты, открытые вопросы и владельцы. Для SABSUS уточните доступную тестовую среду и способы подтверждения результатов в выбранной конфигурации. Если после приёмки меняются правила, данные или интеграции, определите затронутые сценарии и повторите их до использования изменённого маршрута.
Connect acceptance to the launch decisionСвязать приёмку с решением о запуске
Quick answersКороткие ответы
Can a demonstration establish acceptance?Можно принять систему по демонстрации?
A demonstration helps explain behavior. Acceptance needs repeatable scenarios, operational roles, known data and verified outcomes.Демонстрация помогает понять работу. Для приёмки нужны повторяемые сценарии, рабочие роли, известные данные и подтверждённые результаты.
Is a blocked test a failed test?Заблокированный тест считается неуспешным?
Report it separately: a missing prerequisite prevents an established outcome. It is neither a passing test nor proof of a defect in the scenario itself.Его показывают отдельно: результат пока не установлен из-за отсутствующего условия. Это не успешная проверка и не доказанный дефект самого сценария.
Who confirms that a defect is fixed?Кто подтверждает исправление?
The reviewer reruns the scenario and related cases. The process owner decides whether the verified outcomes are sufficient for operational launch.Проверяющий повторяет сценарий и связанные случаи. Владелец процесса решает, достаточно ли подтверждённых результатов для рабочего запуска.