Set a narrow review boundary
Use this suggested workflow practice only after the internal system, active record group, intended release and normal search purpose are already scoped. The purpose is to agree what a reviewer can observe when an authorised person searches for a record before handover. The deliverable is a completed search-state acceptance matrix, supported by synthetic test data and retained evidence. It is not a request for a new search feature, a performance test, a redesign of filters, or a general sign-off for the system.
Start with the dated scope or release reference, nonproduction environment, record group, and the role already permitted to search it. Name the practical question in plain language: for this role and these agreed filters, how can a reviewer tell the difference between no search having run, an authorised known match, an authorised no-match, and a search that did not complete? Keep the question limited to what is visible and repeatable.
Do not use real customer, staff, payment or live operational records. Do not change roles, permissions, data retention, indexing, ranking, fuzzy matching or search algorithms for this review. The exercise cannot prove that a record does not exist outside the viewer’s authorised scope. It can only establish what the agreed role sees after a specified search against a specified synthetic dataset.
- Record the dated scope and release reference
- Name the nonproduction environment and record group
- Confirm the authorised test role and reviewer
- State the agreed filters and search entry point
- Exclude live records and permission changes
Name the four observable states
Write the state labels before running tests. No query yet means the user has not submitted the agreed query. Its starting screen may show an empty area, a prompt, a default list, or something else; record the actual visible condition without calling it a result. A known match means the exact synthetic query returns the planned authorised record under the agreed filters.
Verified no-match means that the reviewer submits an exact planned query, the search visibly completes, and the agreed result state explains that no authorised matching record was found for the current scope or filters. The evidence must include the query, filters and visible explanation. A blank panel, cleared table or missing row alone is insufficient because it does not reveal whether a search ran, whether filters applied, or whether the request failed.
Failed or incomplete search means the expected result cannot responsibly be read as a no-match. Examples include a visible error, an incomplete loading state, an unavailable dependency notice, an expired session indication, or a developer-agreed simulation that prevents completion. Record only what the reviewer observes. Do not relabel the state as zero matches, invent a cause, or attempt an unapproved workaround.
- Separate no query from submitted search
- Define one authorised known-match query
- Define one authorised verified no-match query
- Agree the visible failure or incomplete indicator
- Reject empty space as stand-alone proof
Prepare a synthetic dataset
Create the smallest dataset that makes the four states distinguishable. Give each synthetic active record a stable reference that cannot be confused with a person’s name or a row position. Include one record intended to match exactly, and at least one other record that makes the chosen no-match query meaningful. Record the data-preparation owner and when the dataset was checked.
For example, use synthetic active record SRCH-2048 with display label North Test Service and status Active. Agree that the authorised test role may view that record through the selected search page. Use SRCH-2048 as the known-match query. Use SRCH-2099 as the no-match query only after the preparer and reviewer check that this reference is absent from the agreed synthetic active-record scope. This is a fictional example, not a claim about a client or production data.
Capture the access scope and filters beside each query. A no-match after an Active-only filter says something different from a no-match across another agreed view. If the test role cannot see a record because of existing permissions, do not use that condition to prove no-match. Replace it with a synthetic reference known to be absent from the authorised test population.
- Use stable synthetic record references
- Include one exact known matching record
- Check the no-match reference is absent in scope
- Write filters beside every test query
- Record dataset preparer and check date
Build the acceptance matrix
Use one row for each state. The columns should be: test identifier; authorised role; starting screen; filters; exact query; expected state; expected visible explanation; safe next step; actual observed state; evidence reference; reviewer; decision; and open exception owner. This structure keeps expectation separate from observation and prevents a pass being inferred from a screenshot without context.
For no query yet, the safe next step is to enter the planned query and submit it; do not classify the screen as no-match. For known match, the safe next step is to open or inspect only the agreed synthetic record. For verified no-match, the safe next step can be to review spelling, stable reference and agreed filters, then repeat the same bounded test if needed. It is not an instruction to broaden access or probe for unauthorised records.
For failed or incomplete search, the safe next step is to preserve the screen, capture the exact query and filters, note any visible message, and route the unresolved exception to the agreed owner. A developer may arrange a safe simulation in nonproduction, but reviewers should agree the visible condition beforehand. The matrix records the observed outcome; it does not prescribe how the system must create the error.
- Use expected and observed columns separately
- Capture role, filters and exact query
- Describe the visible explanation precisely
- Attach evidence to each completed row
- Assign each unresolved exception an owner
Run the fictional walkthrough
This fictional walkthrough shows the boundary. Mira is an authorised test coordinator in a nonproduction environment. She opens the agreed active-record search page with the Active filter selected. Before entering anything, the page shows its ordinary starting condition. The matrix records No query yet, not No matches, because she has not submitted a query.
Mira enters SRCH-2048 and submits. The planned synthetic active record appears with its stable reference and label. The reviewer captures the query, Active filter and result screen, then records Known match. Mira next enters SRCH-2099, using the same role and filter. The page completes the search and displays the agreed no-match explanation. The reviewer records Verified no-match because the reference was prechecked as absent from this authorised synthetic scope and the completed state is visible.
For the final row, the developer triggers a previously agreed nonproduction simulation. Mira submits SRCH-2048 and sees the agreed error or incomplete-search indicator instead of a result. She records Failed or incomplete search, retains evidence, and names the technical exception owner. She does not call the result zero matches and does not repeat the query until the agreed exception decision permits it.
- Mark the example as fictional in the record
- Keep the same role and filter where intended
- Capture known match before testing no-match
- Preserve the simulated error evidence
- Leave failed search unresolved until decided
Decide exceptions and hand over
A pass requires the agreed state, visible explanation and evidence to agree for that matrix row. A mismatch is an exception, even if the reviewer believes the cause is obvious. Record whether the result is blocked, needs clarification, needs a defect decision, or is accepted with a stated limitation. Name the person who can make that decision and the next review point. Do not quietly replace an expectation after seeing the screen.
Use the matrix at handover as a bounded record of search-state evidence, not a warranty about every search term, browser, future dataset or user role. It does not establish response times, completeness of all data, or the existence of records outside the agreed scope. Link it to the release record and keep any screenshots or recordings labelled with the state, query, filters and test date.
This guide complements, rather than replaces, separate reviews for permissions, archive retrieval, report totals, imports, session behaviour and workflow acceptance. It is also distinct from SME Systems education about choosing software or comparing CRM, ERP and custom systems. Here, the system choice and scope are already settled; the only question is whether handover reviewers can distinguish a completed authorised no-match from an unrun, failed or incomplete search.
- Require evidence before accepting a row
- Keep failure distinct from no-match
- Record decision authority and next review point
- Link the completed matrix to the release
- Keep separate reviews within their own boundaries
中文指南
先设定审阅边界
只在内部系统、活动记录类别、拟交付版本和正常搜索用途已经确定后，才使用这项建议性流程做法。目的不是重新设计搜索，而是在交接前约定：已授权人员搜索记录时，审阅者实际能看到什么。交付物是一份完成的搜索状态验收矩阵，附带合成测试资料和保留证据；它不是新增功能申请、性能测试、筛选器重做或整套系统签收。
先准备已日期化的范围或版本编号、非生产环境、记录类别，以及本来就有搜索权限的角色。用普通语言写下问题：在这个角色和这些已同意筛选条件下，审阅者怎样分辨尚未搜索、已授权的已知匹配、已授权的无匹配，以及未完成或失败的搜索？问题必须限于可见、可重复的事实。
不要使用真实客户、员工、付款或线上营运资料。不要为了本审阅改动角色、权限、保存规则、索引、排序、模糊匹配或搜索算法。这个练习不能证明记录在查看者授权范围以外不存在；它只能确认指定角色在指定合成资料范围内看到的结果。
- 记录范围和版本编号
- 注明非生产环境与记录类别
- 确认授权测试角色和审阅人
- 写明筛选条件与搜索入口
- 排除真实资料和权限改动
定义四种可见状态
在测试前先写好状态名称。尚未搜索，表示用户尚未提交约定查询；起始画面可能是空白区、提示、默认列表或其他内容，必须如实记录，而不能叫它搜索结果。已知匹配，表示精确的合成查询在约定筛选条件下返回预定且授权可见的记录。
已验证无匹配，表示审阅者提交预定精确查询，搜索明显完成，而且约定的结果状态说明在当前范围或筛选条件下没有找到授权可见的匹配记录。证据必须包括查询文字、筛选条件和可见说明。单独的空面板、清空表格或缺少某一行都不够，因为它们没有说明搜索是否运行、筛选是否生效或请求是否失败。
失败或未完成搜索，表示预期结果不能负责任地解读为无匹配。例如可见错误、持续加载、依赖服务不可用提示、登入状态过期，或开发人员预先同意的模拟而导致搜索无法完成。只记录审阅者实际看到的内容；不要把它改写成零结果、臆测原因或采用未经同意的绕过方法。
- 区分未搜索和已提交查询
- 定义一个授权已知匹配查询
- 定义一个授权无匹配查询
- 同意失败或未完成的可见标记
- 拒绝把空白当作单独证据
准备合成测试资料
建立足以区分四种状态的最小资料集。每条合成活动记录应有稳定编号，不能和姓名或表格行号混淆。包括一条预定精确匹配的记录，并至少有另一条记录，使选定的无匹配查询具备意义。记录资料准备负责人和资料检查时间。
例如，可使用合成活动记录 SRCH-2048，显示名称为 North Test Service，状态为 Active。先同意授权测试角色可以在选定搜索页面查看此记录，再以 SRCH-2048 作为已知匹配查询。只有资料准备人和审阅者确认 SRCH-2099 不在约定的合成活动记录范围内，才可把它作为无匹配查询。这是虚构例子，不是客户或生产资料的陈述。
把访问范围和筛选条件写在每个查询旁边。Active-only 筛选下的无匹配，与另一种已同意视图内的无匹配含义不同。如果测试角色因既有权限而看不到某条记录，不可用该情况证明无匹配；应换成已知不在该授权测试资料群体内的合成编号。
- 使用稳定的合成记录编号
- 包含一条精确已知匹配记录
- 核实无匹配编号不在范围内
- 每次查询附上筛选条件
- 记录资料准备人和检查日期
建立验收矩阵
每种状态使用一行。建议栏位为：测试编号、授权角色、起始画面、筛选条件、精确查询、预期状态、预期可见说明、安全下一步、实际观察状态、证据编号、审阅人、决定和未解决例外负责人。这个结构把预期和观察分开，避免只凭一张没有背景的截图就推断通过。
对于尚未搜索，安全下一步是输入预定查询并提交，不可把起始画面归类为无匹配。对于已知匹配，安全下一步只是打开或检查约定的合成记录。对于已验证无匹配，安全下一步可以检查拼写、稳定编号和已同意筛选条件，再按需要重做同一个有限测试；它不是扩大权限或探查未授权记录的指示。
对于失败或未完成搜索，安全下一步是保留画面、记录精确查询和筛选条件、写下可见讯息，并交给约定负责人处理未解决例外。开发人员可在非生产环境安排安全模拟，但审阅者应预先同意可见状态。矩阵只记录观察到的结果，不规定系统必须怎样制造错误。
- 预期与实际观察分栏
- 记录角色、筛选和精确查询
- 准确描述可见说明
- 每行附上可追溯证据
- 为未解决例外指定负责人
完成虚构演练
以下虚构演练说明边界。Mira 是非生产环境中的授权测试协调员。她打开约定的活动记录搜索页，Active 筛选已选定。她尚未输入任何内容时，页面显示正常起始状态。矩阵记录为尚未搜索，而不是无匹配，因为她尚未提交查询。
Mira 输入 SRCH-2048 并提交。预定的合成活动记录显示稳定编号和名称。审阅者截取查询、Active 筛选和结果画面，然后记录为已知匹配。接着 Mira 在同一角色和筛选条件下输入 SRCH-2099。页面完成搜索并显示已同意的无匹配说明。由于此编号已预先核实不在授权合成范围内，且完成状态可见，审阅者记录为已验证无匹配。
最后一行中，开发人员触发预先同意的非生产模拟。Mira 提交 SRCH-2048，却看到约定的错误或未完成搜索标记，而不是结果。她记录失败或未完成搜索，保留证据并写下技术例外负责人。她不会把结果叫作零匹配，也不会在约定的例外决定允许前重复查询。
- 在记录中注明例子为虚构
- 需要时保持角色和筛选相同
- 先取得已知匹配的证据
- 保留模拟错误的证据
- 失败搜索在决定前保持未解决
决定例外并交接
一行要通过，约定状态、可见说明和证据必须互相一致。即使审阅者认为原因很明显，任何不一致都是例外。记录它是受阻、需要澄清、需要缺陷决定，还是以说明限制的方式接受；写下可作决定的人和下次复核点。不要看见画面后悄悄修改原有预期。
交接时，把矩阵用作有限的搜索状态证据记录，而不是任何搜索词、浏览器、未来资料集或用户角色的保证。它不证明响应时间、所有资料完整性，或约定范围以外记录的存在。把它连接到版本记录，并让截图或录屏标有状态、查询、筛选条件和测试日期。
本指南补充而不取代权限、归档查找、报表总数、导入、会话行为及流程验收等独立审阅；也不同于 SME Systems 关于选择软件或比较 CRM、ERP 与自定义系统的教育页面。这里系统选择和范围已经确定，唯一问题是交接审阅者能否分辨已完成的授权无匹配，与未运行、失败或未完成的搜索。
- 接受每行前要求完整证据
- 始终区分失败和无匹配
- 记录决定权限和下次复核点
- 把完成矩阵连到版本记录
- 让独立审阅各守其边界
Sources and next step
Discuss your workflow scope with BossFlow · Compare system categories at SME Systems · All articles