Test-Case Documentation
A test case is only useful if someone other than its author can follow it. GullySystem turns business journeys into numbered scenarios with clear steps, data and expected results, written for your own staff to run.
What Makes a Test Case Actually Usable
A test case that only its author can follow is not documentation, it is a private note. A usable one states its precondition, the exact steps to take, the data to use, and the result to expect — written so a colleague who has never seen the feature before can run it correctly on the first attempt, and so the same case still makes sense to whoever reads it a year later.
What Each Case Contains
Preconditions
What must already be true before the case starts — a logged-in role, an existing order, a specific account state.
Numbered Steps
Each action written as a single, unambiguous instruction, in the order it must be performed.
Test Data
The specific values to use, including the deliberately awkward ones — a blank field, an expired date, a duplicate entry.
Expected Result
What should happen if the software is working correctly, stated precisely enough that pass or fail is not a matter of opinion.
Traceability
A link back to the requirement or user story each case is proving, so coverage gaps are visible at a glance.
Written From What Exists, Not From a Blank Page
Cases are built from whatever is already available — requirement documents, user stories, a walkthrough with the person who knows the business rules, or the working application itself where no other specification exists. Where the intended behaviour is genuinely unclear, we flag it as a question rather than guessing and writing a case around an assumption.
An Apparel Brand's Return and Exchange Flow, as an Example
An apparel brand's return policy allows a size exchange but not a refund within a set window, with different rules for sale items. The resulting test cases spell out each combination separately — a sale item exchange request, a return requested one day past the window, a customer attempting to exchange for an item at a different price — so a new staff member testing a future release does not have to re-derive the policy from memory before checking it.
Frequently asked questions
Can you write test cases without a requirements document?
Yes. Where no formal specification exists, cases are built from user stories, a walkthrough with whoever owns the business rules, or the current behaviour of a working application, with anything genuinely unclear raised as a question rather than assumed.
Which format or tool do you deliver cases in?
Whatever your team already uses — a spreadsheet, a test-management tool, or a tracker like Jira with a testing plugin — so the documentation fits into your existing workflow rather than asking you to adopt a new one.
Will our own staff be able to run these cases without you?
That is the intent. Cases are written in plain language for a non-technical reader, with enough detail in each step that someone unfamiliar with the feature can execute it correctly on the first attempt.
What drives the cost of documenting test cases?
The number of journeys and user roles being covered, how many edge cases and data variations each journey needs, and how much existing documentation there is to work from versus how much must be gathered through interviews.
What decides how long documenting test cases takes?
Mostly the availability of whoever knows the business rules where no written specification exists, along with how many journeys and roles are being documented and how many revisions are needed once a draft is reviewed.
Do you keep the documentation updated as the software changes?
We can, under an ongoing arrangement, or hand it over for your team to maintain. Either way, cases are written to be easy to update — a numbered library rather than a single unstructured document — so a change to one journey does not require rewriting the rest.
What do you need from us to start documenting?
Access to the application, whatever requirement documents or user stories already exist, and one person who can answer questions about intended behaviour where the documentation is silent or out of date.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private