Let’s pretend today is one of your first days on the job as a Tester at Company X. You see the following testcase:
What should you do?
1. Hide under the desk
2. Run for the door
3. Shout out “Help!!!!”
Hint: Those are all valid options- this is a horrible test case! It’s completely unclear about initial conditions, input, and output. A new member of the team would never be able to run this test case without additional briefing and handholding.
There are a million and one techniques for writing a solid test case. While semantics vary across different companies (and even across different product teams at Microsoft), good test cases clearly state following components:
I’ll go into more detail about these components later. In the mean time, let’s go back to our “Verify HighDPI” test case. If we’re going to improve this case, it should really be broken down into many smaller components. Let’s pretend our application will run on a device that will only do a DPI setting of 120, and the app needs to have License Agreement visible at this setting.
Title: “EULA (License Agreement) should appear at HighDPI”
Priority: 2 (Translation: This isn’t a case we need to run every day, but we need to run it before releasing code to other teams and our customers)
Initial Conditions: System HighDPI is set to the following supported values: 120 only
Expected Output: The initial Setup screen should contain a legible EULA.
Dependencies: Can only be run after running Test Case #8- “HighDPI can be enabled”
We’d want to also write additional cases similar to this one. It’s important that all test cases share the following qualities: Maintainable, Repeatable, Traceable, Efficient, Executable by other Testers, etc, etc.
This test case has some strengths and weaknesses. If there’s such a thing as a “perfect” test case, I haven’t found it, but maybe you have- feel free to drop some feedback in the Comments! J