Characteristics of a Good Test Case

Let’s pretend today is one of your first days on the job as a Tester at Company X. You see the following testcase:


            “Verify HighDPI


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:


  • Identification

  • Description

  • Input & Output

  • Environmental Needs

  • Dependencies

  • Administrativa (Priority, Previous Pass/Fail results, etc)


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



  1. Launch Setup


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



Comments (7)
  1. Brian Lutz says:

    I wrote a response to this post that ended up being fairly lengthy, so I ended up posting it to my own Blog. (Man, I really need to get off Blogspot.) Anyway, the post can be found

    <A HREF=>Here.</a&gt;

  2. Brian Lutz says:

    Ack, guess it doesn’t like that. Just click on the link for my name and it’ll take you there.

  3. Hey folks — this is entry #100. Not bad for around 6 months of existence, but still not up to the level of tech or posting regularity that I had envisaged. I won’t make too many excuses, but rest assured…

  4. Praveen Kumar says:

    Nice ..

  5. Jorriss.Net says:

    There is a free publication on MSDN geared towards architecture.&amp;nbsp; It’s called Microsoft Architecture…

Comments are closed.

Skip to main content