I like well-composed test cases that help QA engineers outline the objectives and expected testing output. Discovering and fixing errors become easier in contrast to ad-hoc testing, lack of consistency.
A test case involves four mandatory sections: Title, Initial Requirements, Testing Steps, and Expected Results. But the final format and construction of a case would depend on the project specifics and regulations of a client company.
I will give you an example of creating an easy test case.
Imagine a simple login web page containing login and password boxes and buttons as Sign in, Forgot Password, and Register. The testing goal is to describe the user's ability to log in with valid user data.
Where to start a journey towards a perfect test case? In my practice, the best starting point is choosing the right style for a test case. Ask clients and colleagues follow-up questions and double-check specifications to get more valuable information.
I recommend using plain language for test cases. That would make writing clear for non-techies or those new to specific functionality. Striking a balance between the usefulness and readability of a test case is vital.
Some test case authors tend to use abbreviations nobody except them understands. That might result in a stressful misunderstanding. New team members would hardly grasp that 'conduct SUFF with VAD' stands for 'Sign in as a Facebook user with valid user data.' So don't overuse abbreviations and contractions.
Other authors may neglect to fill in each of the four test case sections. They may limit Initial Requirements to a single link to specifications, leave Steps empty, or have Expected Results duplicating information provided in Title.
They go wrong about that. All four sections require attention. But – observing the balance between usefulness and readability – it is better to keep descriptions concise.
Here is a simple rule I prefer: cut off unnecessary details irrelevant to a test case and make a case as plain as possible.
For Initial Requirements, it is enough to specify information critical to start testing, provide a link to instructions on setting up a test environment, or other similar data. Make the section look like the following: 'Connect a VPN to simulate a location (USA). Open the login page for users.'
Add Expected Results to each step so that all engineers understand things the same way. Besides, make sure this section comprehensively describes the system state. Avoid writing something like 'The user logged in.' Change that to 'Welcome, user_name; redirection to the homepage (Landing page).'
And a final tip: when filling in a case with steps, avoid dry technical language or over-described functionality and fixed test data.