Writing Thorough Test Cases

A test case is a statement that describes what the test will be performing. A test script is part of a test case and are the granular steps to perform the test case. A test case should aim to exercise as much of a set of requirements as possible, while still being concise.

Formally, a test case is:

[A] set of conditions or variables under which a tester will determine whether an application, software system or one of its features is working as it was originally established for it to do. [Wikipedia]

Let’s say we have a requirement for some login page that reads like this:

The system shall allow a user to login using a valid username and password.

If we break this down, we can see that this requirement simply is one that states a user should be able to log in. It does not mention anything about how long the username or password should or should not be. Also, nothing is mentioned about which characters are valid.

What kind of test cases could we write that would test this requirement?

Positive Path

The first step is to identify the positive, or “happy”, path. A test case should start with some sort of action word. When we are testing software, we are usually verifying some set of functionality. So, my test cases typically begin with the word “Verify”.

You can simply prefix the requirement with the phrase “Verify that” and adjust punctuation accordingly to make a good test case for this sample requirement.

So our test case would be:

Verify that the system allows an existing user to login using a valid username and password.

Our precondition for this test case would be that the tester has a known valid username and password.

I have further questions, though, regarding this requirement. One being, is the username field case sensitive? That could be something we could locate in a specification document somewhere if the project had one, or perhaps further down in the requirements document itself.

Negative Path

The negative path is where most defects are found. This is because developers do not tend to code defensively.

What are some test cases we could write for the negative path?

  1. We could test the boundary conditions.
  2. What happens when I enter a username that is very long?
  3. What happens when I don’t enter a username at all?
  4. What happens when I enter a username with special characters?

Can I execute arbitrary SQL through the any field on the page? This is called SQL Injection and is easily prevented by using best practices. I will cover that in a later blog post.

The list goes on.

For the sake of completeness and clarity, I have stubbed out some sample test cases that would test the negative path. I arbitrarily chose “100 characters” for the first negative test. In a real environment you would have that information:

Verify that an error message is displayed when a username greater than 100 characters is entered into the [Username] textbox.

Verify that an error message is displayed when the [Username] textbox is empty.

Verify that the user is unable to login using SQL injection.

This is a just a glimpse into what goes into writing good test cases. What other test cases could you write? Is this a good requirement? What are your thoughts, readers? Let me know in the comments!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s