How do I keep useful records when testing a work process or tool?
Quick answer
Use one test record for each distinct attempt. Note what you were testing, the setup and starting conditions, the exact steps, what you expected, what actually happened, and evidence that supports the observation. Add a date or test identifier to distinguish attempts. Keep observations separate from guesses, and record changes between attempts so someone else can understand what was—and was not—tested.
The question, the details, the next step.
I’m trying a new work process and want useful records, not a long diary. What should I capture?
Make one compact record for each test attempt. The goal is to let you—or a colleague—answer: What was tried, under what conditions, and what happened?
Use these fields:
- Test ID and date: a short label, such as T-01, plus the date.
- Purpose: the question you want the test to answer.
- Setup: relevant starting conditions, inputs, settings, materials, or roles.
- Steps: what you did, in order, with enough detail to repeat the attempt.
- Expected result: what you thought would happen, stated before interpreting the result.
- Actual result: what you observed, including differences from the expectation.
- Evidence: a suitable reference, such as a file name, non-sensitive screenshot label, or measured value. If there is no evidence to attach, say so.
- Notes: anything that changed, interrupted, or may have affected the attempt.
Keep it brief, but do not leave out conditions that could explain why two attempts differ.
How detailed should the steps be? I don’t want to document every obvious action.
Write steps at the level needed for a colleague to repeat the test and recognize the same decision points. Include specific inputs, options selected, and timing or order when relevant. Note what you did if the process offered a choice. Skip routine actions that cannot affect the result.
Imagine handing the record to someone who was not there. Could they tell which version of the process you used and what you entered? If not, add that detail. Avoid wording like “used the usual settings” unless you name where those settings are recorded or identify them with a placeholder.
Can you show me what a completed record might look like?
Here is a fictional example. The process and results are illustrative, not a claim about a real workplace or tool:
Test ID/date: T-01 / [date] Purpose: Check whether the revised intake steps capture all required fields. Setup: Hypothetical test using [sample record ID]; process version [v2]; reviewer role [role]. Steps: 1. Opened the sample record. 2. Followed the revised intake instructions. 3. Submitted it for review. Expected: The form would contain the five fields listed in [internal requirements reference]. Actual: Four fields were present; the [field name] was blank. Evidence: [redacted screenshot filename] and [review note reference]. Notes: This was one attempt with one sample record. No second attempt was made.
The last line limits what the observation supports. One attempt shows what happened in that attempt; it does not establish how often the issue occurs. If you repeat the test, create T-02 and record any changed conditions rather than silently overwriting T-01.
What should I do when I’m unsure why the result differed, or when the evidence contains work information?
Record the observation first, then label possible explanations as hypotheses. For example: “Observed: the field was blank. Possible explanation to check: the instruction may not identify who completes it.” That keeps a guess from being mistaken for a finding. For the next attempt, change one relevant condition at a time where practical, and note exactly what changed. If several things change together, the comparison may be harder to interpret.
For evidence, follow your workplace’s rules for handling work information. Do not paste confidential or personal details into a record that is not approved for them. Use an approved location or a placeholder such as [restricted evidence reference], and keep enough context to find the evidence through the appropriate process. If you cannot retain an artifact, state what you observed and why no artifact is included.
Here is a blank worksheet you can copy for each attempt:
Test ID/date: [ ] Purpose or test question: [ ] Process/tool and version: [ ] Setup and starting conditions: [ ] Steps, in order: [ ] Expected result: [ ] Actual result: [ ] Evidence reference or reason none is attached: [ ] Changes, interruptions, or hypotheses: [ ] Limit of this observation: [ ]
Before sharing a record, check that it distinguishes fact from interpretation, identifies the process version and attempt, and makes no claim broader than the evidence.
A practical checklist
Give each attempt a unique ID and date.
State the test question and identify the process or tool version.
Record relevant starting conditions, inputs, settings, and ordered steps.
Write the expected result before interpreting what happened.
Describe the actual result and link or refer to suitable evidence.
Label explanations as hypotheses and note limits, changes, or missing evidence.
A few more useful answers
Should I combine several attempts in one record?
Keep a separate entry for each attempt so changed conditions and results remain clear. You can use one summary to compare attempts, with each entry identified by its test ID.
What if I did not define an expected result beforehand?
Say that the expected result was not recorded before the attempt. Write down what you observed, then set an explicit expectation for the next test rather than presenting a later guess as the original expectation.
How do I make a record useful without attaching screenshots or files?
Describe the observable result precisely and note that no artifact is attached. Where appropriate, include a reference or placeholder that points to evidence stored through an approved workplace process.