Welcome to MSDN Blogs Sign in | Join | Help

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

 

Steps:

  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

 

Greg

Published Monday, April 05, 2004 8:50 PM by chappell

Comments

# re: Characteristics of a Good Test Case

Tuesday, April 06, 2004 12:23 AM by Brian Lutz
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=http://warriorsden.blogspot.com/2004_04_04_warriorsden_archive.html#108123237654179331>Here.</a>

# re: Characteristics of a Good Test Case

Tuesday, April 06, 2004 12:24 AM by Brian Lutz
Ack, guess it doesn't like that. Just click on the link for my name and it'll take you there.

# Entry Number 100

Tuesday, April 06, 2004 1:16 PM by MeriBlog : Meri Williams' Weblog
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...

# Hi

Wednesday, April 07, 2004 7:38 AM by Praveen Kumar
Nice ..

# Information to Google

Wednesday, April 14, 2004 3:58 PM by Random Thoughts of Jorriss

# Test Design and Test Cases

Friday, September 03, 2004 6:59 AM by Devankur Thakur

# Information to Google

Sunday, April 23, 2006 4:39 PM by Jorriss.Net
There is a free publication on MSDN geared towards architecture.&amp;nbsp; It's called Microsoft Architecture...
New Comments to this post are disabled
 
Page view tracker