Set the narrow review boundary
Use this suggested workflow practice after the release, record type, fields, and normal user roles are already scoped. The aim is not to prove that every update is safe. It is to create one pre-handover conflict acceptance matrix showing what the agreed product actually does when two authorised test users begin with the same synthetic record and make incompatible changes.
Keep the test isolated. Use a non-production environment, synthetic records, and authorised test accounts only. Do not use customer, staff, payment, or live operational data. Do not use the exercise to request new fields, roles, reports, integrations, cutover steps, or database changes.
State the acceptance question in observable language: when User A saves a change first, what does User B see when attempting to save a different change from the earlier revision, what happens to B’s proposed work, and what verified record remains after reconciliation? This keeps the review focused on evidence rather than assumed technical design.
Bring the dated scope or release reference, the record reference, the fields to be changed, the environment reference, two test-user names or roles, and the person who can accept the evidence. A user-story framing can help: name the actor, action, and reason, then define outcomes someone can check.
- Dated scope reference attached
- Isolated test environment named
- Synthetic record reference assigned
- Acceptance authority identified
Build the conflict acceptance matrix
Create one row for the exact scenario. Record the shared starting revision or other visible starting state, including the record reference and the time each user opened it. If the product has no visible revision label, capture another repeatable starting-state reference such as the same displayed values and an evidence identifier. Do not invent a revision number.
Give each user a different, deliberately incompatible intended change. For example, both may change the same status field to different agreed test values. Write each intended value before either save occurs. A conflict test is weaker if the changes affect unrelated fields or if one user’s action is unclear.
The matrix should have columns for User A’s first save, User B’s stale second-save attempt, the message or screen evidence shown to B, whether B’s unsaved proposal remains available, the person responsible for reconciliation, the final chosen value, and verification after refresh or reopening. Add an evidence location for screenshots, exports, or a recording where permitted.
Record observations, not conclusions. “B saw a conflict message and the unsaved value remained in the edit form” is evidence. “The system prevents all lost updates” goes beyond one scenario. If the observed behaviour differs from the agreed acceptance condition, mark it as unresolved rather than quietly changing the condition.
- Shared starting state captured
- Different changes written first
- First save result recorded
- Stale save outcome recorded
- Evidence location linked
Run the controlled two-user test
Prepare the synthetic record in its agreed baseline state. Ask both authorised users to open that same record before either person saves. Record the displayed starting values and any visible revision information. Confirm that both users can perform this routine action under the existing agreed access rules; do not alter permissions merely to make the test work.
User A changes only the planned field or fields and saves first. Capture the resulting record state, visible confirmation or error, and the actual saved value. User B must keep the earlier view open, make the separately planned change, and then attempt to save without manually refreshing first.
Observe the stale second-save outcome exactly. The product may warn, reject, merge, overwrite, refresh, or follow another agreed behaviour. This guide does not prescribe which mechanism is correct. It asks whether the actual response is visible enough for the business to make an acceptance decision and whether B’s proposed work can be recovered or recorded before reconciliation.
After the attempt, preserve B’s intended value and any explanatory note in the matrix before closing the page, changing the record again, or refreshing away evidence. Preservation can mean it remains on screen, can be copied into the matrix, or is otherwise retained by the agreed test method. Do not claim preservation if the proposal cannot be shown or reliably recorded.
- Both users opened baseline
- User A saved first change
- User B attempted stale save
- Unsaved proposal preserved
- Observed evidence retained
Decide exceptions without enlarging scope
If B receives a clear conflict outcome and the proposal is retained, the reconciliation owner compares A’s saved result with B’s intended change. That owner selects the final value according to the agreed business rule, records why, applies the permitted reconciliation action, and verifies the final record by a fresh read. Acceptance covers this documented scenario, not an untested rule for every field.
If B’s save succeeds and overwrites A’s first result, do not label the test passed merely because a final value exists. Record both actual outcomes, preserve any available evidence, and refer the difference to the named scope or acceptance decision owner. The owner may accept documented behaviour, request a change through the separate change process, or defer handover for this scenario.
If B cannot recover or document the unsaved proposal, treat that as a material evidence gap. Pause the acceptance decision for this row. Do not substitute memory, a recreated change, or a different test as proof of the original outcome. Record the next safe action and owner.
If the users were not truly concurrent, the record was not synthetic, permissions differed from agreed roles, or the environment was unstable, invalidate the row and repeat it only after the condition is corrected. An invalid test is not a failure of the product, but it is not acceptance evidence either.
- Exception decision owner named
- Reconciliation reason recorded
- Invalid conditions identified
- Change request kept separate
- Final read-back completed
Fictional worked matrix example
Fictional example only: in an isolated test system, User A and User B both open synthetic record TEST-204 showing status “Awaiting review.” The matrix records the same visible baseline and a shared starting reference. A plans “Approved for test”; B plans “Held for clarification.” These are intentionally different values for the same field.
A saves “Approved for test” first and the matrix records the displayed confirmation and refreshed value. Without refreshing, B tries to save “Held for clarification.” The product displays its observed stale-save response. B’s proposed wording remains visible in the form, so the test facilitator copies it into the matrix and retains the permitted screen evidence.
The named reconciliation owner reviews the two intended changes and selects “Held for clarification” under the fictional test rule that an open clarification takes priority. The owner records that reason, applies the allowed action, then a fresh reader opens TEST-204 and confirms the final status. The matrix records what happened; it does not assert how the product implements conflict handling.
If B had instead overwritten A silently, the fictional row would show that observation, mark the acceptance condition unresolved, and send the decision to the agreed owner. It would not infer a database fault, redesign the system, or use real work records to repeat the test.
- Fictional record clearly labelled
- Both intended values retained
- Reconciliation owner recorded
- Fresh verification captured
Complete the handover evidence
Before handover, review the matrix with the business approver and implementation contact. Confirm that it identifies the release, environment, synthetic record, test users, starting state, separate changes, save order, observed stale-save response, preservation method, reconciliation owner, final record, and evidence location. A future reader should be able to understand the decision without replaying a conversation.
Write one of three outcomes for each row: accepted as observed, unresolved and requiring a separate decision, or invalid and to be rerun. Avoid broad wording such as “concurrency complete.” Acceptance is limited to the scenario, record type, fields, and product release stated in the matrix.
Store the completed matrix with the handover evidence. Link related material only where useful: the agreed workflow acceptance example for the normal path, the access-permission record for who was authorised, and the change-decision record if behaviour requires new scope. Keep those decisions separate so this test remains auditable.
The resulting record gives the team a practical basis for discussing conflict behaviour before routine use. It does not promise outcomes under production load, across every device or integration, or for future releases. Repeat or extend the review only when the scope, release, or accepted scenario changes.
- Release and environment identified
- All test evidence locatable
- Outcome status selected
- Approver decision recorded
- Handover boundary stated
中文指南
界定本次审阅范围
这份建议流程实践适用于系统版本、记录类型、字段和一般用户角色已完成范围确认之后。目标不是证明每一次更新都安全，而是在交接前建立一份冲突验收矩阵，记录两名获授权测试用户从同一笔合成记录开始、作出不相容修改时，已约定产品实际呈现的行为。
测试必须隔离进行：使用非生产环境、合成记录和获授权的测试账号。不要使用客户、员工、付款或真实运营资料；也不要借此要求新增字段、角色、报表、整合、切换步骤或数据库修改。
把验收问题写成可观察的语言：用户 A 先保存后，用户 B 从较早版本尝试保存不同修改时看见什么；B 的拟议内容如何处理；协调后最终核实的记录是什么。这样讨论的是证据，而不是假设某种技术设计。
准备已注明日期的范围或版本参考、记录编号、要修改的字段、环境参考、两名测试用户的姓名或角色，以及可接受证据的负责人。也可用用户故事表达：写清角色、动作和原因，再列出可检查的结果。
- 已附范围参考文件
- 已指定隔离测试环境
- 已建立合成记录编号
- 已确定验收负责人
建立冲突验收矩阵
为这个准确场景建立一行矩阵。记录双方共用的起始版本或其他可见起始状态，包括记录编号和各自打开记录的时间。若产品没有显示版本编号，可记录可重复的起始状态，例如相同的字段显示值和证据编号；不要虚构版本号。
让每名用户准备不同且刻意不相容的修改。例如，两人都把同一状态字段改为不同的约定测试值。任何一方保存前，先写下两个拟议值。若修改的是互不相关字段，或其中一方动作不清楚，冲突测试的证明力会变弱。
矩阵应包括：A 的首次保存、B 的过期第二次保存尝试、B 看见的讯息或画面证据、B 未保存提议是否仍可取得、协调负责人、最后选定的值，以及刷新或重新打开后的核实结果。按允许的方式，加入截图、导出文件或录屏的证据位置。
记录观察结果，不要跳到结论。“B 看见冲突讯息，未保存的值仍在编辑表单中”属于证据；“系统防止所有更新遗失”超出单一场景。若观察结果与原先验收条件不同，应标记为未解决，而不是悄悄改写条件。
- 已捕捉共同起始状态
- 已先写明不同修改
- 已记录首次保存结果
- 已记录过期保存结果
- 已链接证据存放位置
执行双用户受控测试
先把合成记录准备为约定的基准状态。请两名获授权用户在任何一方保存前都打开同一笔记录，记录显示的起始值和任何可见版本资料。确认双方在既有约定权限下都能完成这个日常动作；不要为了让测试通过而调整权限。
用户 A 只修改计划中的字段并先保存，捕捉保存后的记录状态、可见确认或错误，以及实际保存的值。用户 B 必须保留较早的画面，作出预先计划的不同修改，并在未手动刷新前尝试保存。
准确观察过期第二次保存的结果。产品可能警告、拒绝、合并、覆盖、刷新，或出现另一种已约定行为。本指南不规定哪一种机制正确；重点是响应是否足够清楚，让业务方能作验收决定，并让 B 的拟议工作能在协调前被恢复或记录。
尝试之后，在关闭页面、再次修改记录或刷新而失去证据前，先在矩阵中保留 B 的拟议值和说明。保留可以是内容仍显示在画面上、可复制到矩阵，或依约定测试方式保存。若无法展示或可靠记录，不应声称已保留。
- 双方已打开基准记录
- 用户 A 已先保存修改
- 用户 B 已尝试过期保存
- 未保存提议已经保留
- 观察证据已经留存
处理例外而不扩大范围
若 B 得到清楚的冲突结果且提议被保留，协调负责人应比较 A 已保存的结果与 B 的意图。负责人依照已约定的业务规则选择最终值，记录原因，完成获允许的协调动作，并以新的读取核实最终记录。验收只覆盖这个已记录场景，不代表每个字段都有未经测试的规则。
若 B 的保存成功并覆盖 A 的首次结果，不应因为存在最终值就判定通过。记录两个实际结果，保留可取得的证据，并交给指定的范围或验收决策负责人。负责人可接受已记录的行为、经独立变更流程提出修改，或暂缓这个场景的交接。
若 B 无法恢复或记录未保存提议，应视为重要证据缺口。暂停这一行的验收决定。不要以记忆、重新做一次修改或不同测试代替原本结果的证明。记录下一项安全行动及其负责人。
若用户并非真正并发、记录不是合成资料、权限不符合约定角色，或环境不稳定，应使该行无效，并在条件修正后才重测。无效测试不等于产品失败，但也不是验收证据。
- 已指定例外决策负责人
- 已记录协调选择原因
- 已识别无效测试条件
- 变更请求保持独立
- 最终读取已经核实
虚构案例完整演示
以下完全是虚构案例：在隔离测试系统中，用户 A 与用户 B 都打开合成记录 TEST-204，状态为“等待审阅”。矩阵记录相同的可见基准和共同起始参考。A 计划改为“测试批准”；B 计划改为“待澄清”。两者刻意修改同一个字段为不同值。
A 先保存“测试批准”，矩阵记录显示的确认和刷新后的值。B 不刷新，尝试保存“待澄清”。产品显示实际观察到的过期保存响应。B 的拟议文字仍在表单中，因此测试协调人把它复制到矩阵，并保留允许的画面证据。
指定的协调负责人审阅两项意图，并按虚构测试规则选择“待澄清”，因为未解决的澄清优先。负责人记录原因，执行允许的动作；随后由新的读取者打开 TEST-204，确认最终状态。矩阵只记录发生的事实，不断言产品如何实现冲突处理。
如果 B 反而静默覆盖 A，虚构案例应如实记录该观察，标示验收条件未解决，并交由约定负责人决定。它不应推断数据库故障、重新设计系统，或以真实工作记录重复测试。
- 虚构记录已有明确标签
- 双方拟议值均被保留
- 协调负责人已有记录
- 新读取核实已完成
完成交接验收证据
交接前，与业务批准人和实施联系人一起复核矩阵。确认其中包含版本、环境、合成记录、测试用户、起始状态、不同修改、保存顺序、观察到的过期保存响应、保留方法、协调负责人、最终记录和证据位置。未来读者无需重听聊天也应能理解决定。
每一行只写三种结果之一：按观察结果接受、未解决并需要独立决定、或无效并需重测。避免“并发已完成”这类宽泛表达。验收只限矩阵所写的场景、记录类型、字段和产品版本。
把完成的矩阵与交接证据一起保存。只在有帮助时关联相关资料：一般流程的验收示例、谁获授权的权限记录，以及行为需要新范围时的变更决定记录。各项决定应保持分开，令本测试可追溯。
这份记录让团队在进入日常使用前，能有实际依据讨论冲突行为。它不承诺生产负载、每种设备或整合、或未来版本的结果。只有范围、版本或已接受场景改变时，才重做或扩展审阅。
- 版本环境已经标明
- 全部证据可以定位
- 验收状态已经选择
- 批准决定已经记录
- 交接边界已经说明
Sources and next step
Discuss your workflow scope with BossFlow · Compare system categories at SME Systems · All articles