On Monday a tester opens “Create a service request”. On Friday the release manager asks whether the new portal is ready to ship. A tick beside the case won’t answer that question. The team needs to know which build was tested, what happened after submission and what still needs to be checked.
One requirement, three records
In the fictional ServiceDesk Release project, creating a request should produce a reference and an entry in the customer’s list. Here is where each part of that story belongs:
- Test case – what should work?
- A signed-in customer enters “Demo printer won’t connect” and a description, submits the form and reloads the list. Expect exactly one request with a reference, the original text and an open status. This procedure can be used again for the next portal build.
- Test plan – which cases matter for this release?
- A change to the request form calls for the creation case. Include the case for missing required fields as well. A successful submission tells you little about whether someone can correct a rejected form.
- Test run – what happened on this occasion?
- Record the build, environment, outcome and observation together. A failed run is evidence. After the fix, record the retest separately so the team can still see what happened in each build.
What a useful result looks like
Suppose the portal shows reference DEMO-42. The confirmation alone doesn’t tell you the request was saved. Reload the list before recording a pass. A sample entry for this fictional run might read:
Test environment, build RC2, customer role. One submission produced DEMO-42. After reload the list contained one request with the original title and description. Its status was Open. Passed.
If the same submission produced two entries, the expectation in the library is still correct. Record the discrepancy in the run. Check the references as well as the titles. Two deliberately separate requests can have the same title. If nobody has agreed how the system should behave, the team first needs to settle the acceptance criterion.
Find the three records in the demo
- Open the web demo. In the test case library, choose Anfragen → Service-Anfrage erstellen. The public project uses German sample data even with the English interface. A local English example uses Requests → Create a service request.
- Open the most recent run under Release-Abnahme (Release acceptance). Look for cases with recorded results and those still waiting for one.
- If you practise recording an observation, use fictional data and mark the result as practice. There is no executable customer portal in the sample. Visitors share the project and it resets overnight.
If you edit the library case later, check whether the plan needs to be synchronised before the next run. An existing planned case does not automatically pick up the new instructions. See Your first test run for the Windows and browser workflows.