distributedlife

Testing is about asking questions. As testers we ask questions of specifications, we hassle the analysts, we pester the developers, we ask questions of functionality and we ask questions of implementations. All of this is to provide assurance to the project owners that the solution delivered by the team is both correct (verification) and appropriate for their needs (validation).

The important task testers have is not just working out what questions to ask, but how to ask those questions. Being able to work out the how and articulate that is what makes a good tester.

Now when we ask a question to a person the how is trivial. We send an email or walk over to their desk and start talking or communicating in a pre-arranged language.

When we ask questions of implementation and functionality then it becomes a little bit harder. Often the question is the easy part. We’ve derived the question from a specification or past experience. It could be something like:

“attempt login to system where user credentials have been suspended”

This seems like a pretty simple question and that is my point. We want to ensure that when the user has suspended credentials that they cannot log into the system. I am of course assuming the requirements state that.

You may think that testing this is trivial; you get some credentials, suspend them and then try logging in. When you say it like that, it is simple. But you’re missing the point. This test case isn’t just for you. Like coding standards we need testing standards so that the poor chap who has to maintain the system and accompanying test cases understands what is going on.

What isn’t clearly stated is how do we suspend credentials. You may know how to suspend credentials. Good for you. What you need to do is document how someone else can suspend credentials. This is the how.

There are two things you can do at this point. You can add steps into your test case explicitly stating each action the user must take to establish the pre-conditions or, you can write a short how-to document about how to suspend accounts. Better yet, you can check the user manuals to see if such information already exists, if it does then link to it.

The number one criticism I get for my method of writing test cases is that it doesn’t provide enough information within the test case itself such that anyone can come onto the project and start testing. The how isn’t being clearly documented. In some instances, this is that case. I’m guilty of not writing how-to’s as often as I should, but I do write them and if you worked with me you can find them on our development wiki.

The alternative methods for writing test cases are the longer detailed variety where every user action is explicitly stated. In these test cases I still find statements like “preconditions: user credentials have been suspended”. There is no “how” documented here, there never has been. There is no point to explicitly detailing every action the user must take to log in. Logging into a system is not a complicated process, if you find it difficult then you should be talking to your user experience team as they have some work to do.

The complicated part is the part that always gets left out. How to establish the pre-condition, how to test the system. These bits get left out and they get left out because often the tester writing the test case doesn’t know the answer themselves. They know the question but they don’t know how to ask it. This is also why the how lets you tell the difference between a good tester and an average one.