Set a narrow review boundary
Use this suggested workflow practice after a custom internal system, the relevant record type, and the intended handover release are already scoped. The deliverable is one session-expiry acceptance worksheet and one completed synthetic test. The question is practical: if a staff member has typed edits that have not been confirmed by the server when their session expires, what can each reviewer observe before and after they sign in again?
Keep five facts separate. The last confirmed server record is what the system had already accepted. An unsaved draft is information visible in the editing session but not yet confirmed. Expired sign-in state means the current session can no longer continue. Reauthentication is the permitted return step. Verified post-return state is what the reviewer can actually read after returning. Treating these as one idea creates mistaken claims that an edit was saved, restored, or lost.
This review does not set session duration, authentication policy, permissions, token handling, encryption, compliance, logout behaviour, automatic saving, or persistence across sign-in changes. It also does not decide simultaneous-edit handling, backup restoration, real-data recovery, or a retry rule for a submitted request. Record any such question as a separate scope decision.
- Use a non-production environment
- Choose one synthetic record
- Name the existing user role
- State the agreed release reference
- Name the acceptance decision owner
Prepare an observable worksheet
Start with the dated scope, release or environment reference, stable synthetic record reference, named tester, developer contact, and business reviewer. Select an already scoped editable field and a harmless before-value. Capture evidence of the record before editing, such as a screenshot or agreed screen recording. The evidence should show the reference and the confirmed value without exposing real customer, staff, payment, or operational data.
Write the acceptance question in user terms: when this authorised test user edits this synthetic record and the session expires before save confirmation, what message appears, what action is available, and what value is visible after the user signs in again? Do not phrase it as a technical demand for a particular storage mechanism.
Agree a safe expiry trigger with the developer before testing. It may be an isolated test setting, a controlled test account condition, or another method the team already permits. The worksheet should name the trigger and who may apply it, but need not describe implementation details. Do not improvise a trigger in a live environment.
- Record the stable test reference
- Capture the before-state evidence
- Identify one editable field
- Agree the safe test trigger
- Confirm synthetic data only
Agree the test path before running it
Write a short sequence that a business reviewer can follow. First, open the confirmed synthetic record. Second, change the chosen field but do not use the normal save action. Third, apply the agreed safe expiry trigger. Fourth, record the user-visible message and available actions. Fifth, follow only the permitted next step, normally reauthentication if the product presents it. Sixth, reopen the same record and compare its visible value with the captured before-state and the unsaved value.
Agree what evidence is sufficient at each point. A before-state image establishes the confirmed starting value. An image or recording of the expiry message establishes the observed interruption. A post-return readback establishes the visible server record after return. If the product visibly offers draft recovery, capture the prompt, user action, and result. If it does not, record that recovery was not observed; do not infer that hidden recovery exists or does not exist.
Set a stop condition. Stop the test if the record reference cannot be verified, the trigger differs from the agreed method, the user reaches an unrelated workflow, or the team cannot tell whether a save was confirmed. Mark the test inconclusive and assign the next clarification rather than repeating actions until an attractive result appears.
- Describe each test action plainly
- Capture the expiry message
- Record permitted next action
- Read back the same record
- Stop when evidence is ambiguous
Decide exceptions honestly
Use a decision table in the worksheet. If the post-return value matches the before-state and no recovery was observed, record: server record unchanged; unsaved draft not demonstrated as recoverable; limitation accepted, deferred, or raised as a separate request. If a recovery prompt appears and the restored text can be observed, record only that observed route and its limitations. Neither outcome proves behaviour for every screen, browser, device, network condition, logout route, or later release.
If a save confirmation appeared before expiry, the event belongs to the confirmed-record path, not the unsaved-draft path. Verify the readback and record that the scenario changed. If the user sees an error, blank page, or unclear state instead of an understandable expiry path, preserve evidence and classify it as an unresolved handover exception. Do not prescribe a fix unless the responsible scope owner opens one.
If the team requests automatic saving, longer sessions, a different sign-in flow, recovery after logout, or production testing, separate the request from this acceptance decision. State the user need, affected record type, risk, owner, and whether the current release remains acceptable without it. A useful handover record makes the boundary visible rather than converting every concern into an implied promise.
- Classify confirmed saves separately
- Mark recovery as observed or unobserved
- Record the limitation plainly
- Assign every unresolved exception
- Open new requests separately
Work one fictional test through
Fictional example: an internal test user opens synthetic job JOB-TEST-042. Its confirmed internal note reads “Initial check complete.” The user changes it to “Initial check complete; call before visit” and intentionally does not select Save. The agreed test administrator applies the approved non-production expiry trigger. The screen displays a session-expired message and directs the user to sign in again.
After reauthentication, the tester opens JOB-TEST-042 by its stable reference. The visible note remains “Initial check complete.” The amended wording is not displayed, and no recovery prompt is observed. The reviewer compares the post-return screen with the captured before-state and records a known final outcome: the last confirmed server record remained visible; the unsaved amendment was not demonstrated as recoverable in this test.
The acceptance decision is not “all drafts are lost” and not “the system is secure.” It is narrower: for this release, record, role, field, trigger, and observed route, the team has evidence of the message, permitted reauthentication step, and post-return value. The business owner may accept that limitation for handover, defer it with an owner and review point, or request a separately scoped change.
- Label the example as fictional
- Use a harmless synthetic reference
- Compare three visible values
- Record the final decision
- Keep claims limited to evidence
Close the handover record
Close the worksheet with the scope reference, release or environment, test date, participants, synthetic record reference, trigger used, before-state evidence location, expiry evidence location, post-return evidence location, result, limitation, and decision owner. Include a short statement of what was not tested: for example, other fields, devices, browsers, network interruptions, real records, simultaneous edits, and authentication-policy settings. This makes later readers less likely to overextend the result.
A handover decision should be one of three clear outcomes: accepted for the stated bounded scenario; accepted with a recorded limitation and follow-up owner; or not accepted because the observed path does not meet the agreed acceptance question. “Looks fine” is not a decision because it hides the scenario, evidence, and limitation.
Reuse the worksheet only when the next test still has the same narrow purpose. If another record type, user path, release, or recovery expectation matters, create a new row or worksheet and agree its evidence before testing. This preserves an observable review trail while keeping the team focused on the already scoped system.
- Link all retained evidence
- State exclusions explicitly
- Choose one decision outcome
- Name the follow-up owner
- Store the completed worksheet
中文指南
先设定审阅边界
这项建议的工作方法适用于自定义内部系统、相关记录类型和交接版本都已确定之后。交付物是一份会话过期验收工作表和一次完成的合成数据测试。实际问题是：员工已经输入但服务器尚未确认的编辑，碰上会话过期时，审阅者在重新登录前后各能观察到什么？
必须分开记录五项事实。最后已确认的服务器记录，是系统此前已接受的内容。未保存草稿，是编辑期间看得到但未获确认的内容。登录状态过期，表示当前会话不能继续。重新认证是被允许的返回步骤。返回后的核实状态，是审阅者重新进入后实际读到的内容。把这些混为一谈，容易错误宣称编辑已保存、已恢复或已丢失。
本审阅不设定会话时长、认证政策、权限、令牌处理、加密、合规、登出行为、自动保存或跨登录保存。它也不处理同时编辑、备份恢复、真实数据恢复或已提交请求的重试规则。任何这类问题都应另记为范围决定。
- 使用非生产环境
- 选择一条合成记录
- 注明现有用户角色
- 写明交接版本编号
- 指定验收决定负责人
准备可观察工作表
先填写已确认范围日期、版本或环境编号、稳定的合成记录编号、测试人员、开发联络人及业务审阅人。选择一个已在范围内可编辑的字段和一个无害的原始值。编辑前保留记录证据，例如截图或双方同意的录屏。证据应显示记录编号和已确认值，但不应出现真实客户、员工、付款或运营数据。
用使用者语言写验收问题：这个获授权测试用户编辑此合成记录，在保存确认前会话过期时，看到什么提示、可以做什么，以及重新登录后能看到什么值？不要把问题写成要求某一种储存技术。
测试前先与开发人员同意安全的过期触发方法。可以是隔离测试设定、受控测试账号条件，或团队已允许的其他方法。工作表应写明触发方法和可执行的人，但无需披露实现细节。不要在生产环境临时尝试触发。
- 记录稳定测试编号
- 保留编辑前证据
- 确定一个编辑字段
- 同意安全触发方式
- 确认只用合成数据
执行前同意测试路径
写出业务审阅者能跟随的简短步骤。第一，打开已确认的合成记录。第二，修改选定字段，但不要使用正常保存。第三，使用已同意的安全过期触发。第四，记录用户可见提示和可用动作。第五，只执行被允许的下一步，通常是产品提示的重新登录。第六，用同一编号重新打开记录，并把可见值与编辑前证据及未保存值比较。
各阶段要先同意何种证据足够。编辑前画面证明已确认起点；过期提示的截图或录屏证明观察到的中断；返回后读回画面证明重新进入后可见的服务器记录。如果产品明确提供草稿恢复，要记录提示、用户动作和结果。若没有，不应推论存在或不存在隐藏恢复，只记录未观察到恢复。
设定停止条件。若无法核实记录编号、触发方式与约定不同、用户进入无关流程，或团队无法判断保存是否已确认，就停止测试。标记为证据不足，并指定下一项澄清事项，而不是不断重复操作直到得到好看的结果。
- 用清楚语言描述动作
- 截取过期提示画面
- 记录允许的下一步
- 读回同一条记录
- 证据不清就停止
诚实处理例外决定
在工作表中使用决定表。若返回后值与编辑前相同，且未观察到恢复，应记录：服务器记录未改变；未证明未保存草稿可恢复；该限制已接受、延后处理或另列需求。若出现恢复提示且可观察到恢复文字，只记录该实际路径及其限制。两种结果都不能证明所有页面、浏览器、设备、网络情况、登出路径或以后版本的行为。
若过期前已经出现保存确认，这属于已确认记录路径，而不是未保存草稿路径。核实读回内容，并记录场景已经改变。若用户看到错误、空白页面或不清楚状态，而不是可理解的过期路径，应保留证据并列为未解决交接例外。除非范围负责人另开事项，否则不要自行规定修复方案。
若团队提出自动保存、延长会话、不同登录流程、登出后恢复或生产测试，应把需求与本次验收决定分开。写明用户需要、受影响记录类型、风险、负责人，以及没有此项时当前版本是否仍可接受。好的交接记录会清楚显示边界，而不会把每个担忧变成默认承诺。
- 把已确认保存另行分类
- 标注已观察或未观察恢复
- 清楚记录限制内容
- 每个未决例外指定负责人
- 新需求另开处理项
完成一个虚构测试
虚构示例：内部测试用户打开合成工作记录 JOB-TEST-042。它已确认的内部备注是“初步检查完成”。用户把它改为“初步检查完成；到访前先致电”，并刻意不点保存。已同意的测试管理员执行获准的非生产过期触发。画面显示会话已过期，并指示用户重新登录。
重新认证后，测试人员用稳定编号打开 JOB-TEST-042。可见备注仍是“初步检查完成”。修改后的文字没有显示，也未观察到恢复提示。审阅人把返回后画面与编辑前证据比较，并记录已知最终结果：最后确认的服务器记录仍可见；本次测试未证明未保存修改能够恢复。
验收决定不是“所有草稿都会丢失”，也不是“系统安全”。更窄的结论是：针对这个版本、记录、角色、字段、触发方法和观察路径，团队拥有提示、允许重新认证步骤和返回后值的证据。业务负责人可接受该限制后交接、延后并指定负责人和复核点，或提出另一项已定义范围的变更。
- 明确标注虚构示例
- 使用无害合成编号
- 比较三个可见数值
- 记录最终决定结果
- 只作证据支持的表述
完成交接记录
完成工作表时，写入范围编号、版本或环境、测试日期、参与者、合成记录编号、所用触发方式、编辑前证据位置、过期证据位置、返回后证据位置、结果、限制和决定负责人。同时列出未测试事项，例如其他字段、设备、浏览器、网络中断、真实记录、同时编辑和认证政策设定。这样可避免后来的读者把结果扩大解释。
交接决定应是三种清楚结果之一：在所述有限场景下接受；带有已记录限制和后续负责人而接受；或因观察到的路径不符合已同意验收问题而不接受。“看起来没问题”不是决定，因为它没有说明场景、证据和限制。
只有下一次测试仍有同样狭窄目的时，才重复使用这份工作表。若另一种记录、用户路径、版本或恢复期望也重要，应新增一行或一份工作表，并在测试前同意证据要求。这样既保留可观察的审阅轨迹，也让团队专注于已确定范围的系统。
- 链接所有保留证据
- 明确写出排除事项
- 选择一个决定结果
- 指定后续处理负责人
- 保存完成的工作表
Sources and next step
Discuss your workflow scope with BossFlow · Compare system categories at SME Systems · All articles