Thursday, August 18, 2011

Who/What/When/How/Why of Testing

I've been working with a client who has a group of academic engineers. These are very smart people who haven't ever built a product or worked in commercial software. So they asked me, "Can you teach me testing?"

Well, yes. I can teach you about testing. It's going to take a while. Ultimately, most of these guys don't need to become software testers, though. They just need a framework for figuring out how to figure out if their system does what it ought to do. The more sophisticated test design can be handled by the actual test team. These engineers just have to get far enough that they can work effectively with the testers.

Here are the very basics of what I told them:

Who should test?
Anyone can test. QA engineers (aka testers aka QE engineers) are simply people who specialize in testing activities. That doesn’t mean they’re the only ones who can do it! Use QA engineers as sources of knowledge and ideas just like you’d use a software architect, or a build engineer. They’ll do a lot of testing, but with a little help, you can also test.

What should you test?
Since testing is about gathering relevant information about potential and/or actual behavior, many things can be tested. Frequently, portions of software and systems as a whole are tested. However, software designs, UI designs, hardware, and even requirements or documentation can be tested. In short, if you (or someone involved in a project) want information about something, test it!

When should you test?
The earlier you test, the more time you have to react to what you learn from testing. So if you can test part of something, that’s fine - it’s early feedback. Testing continues for as long as you will do something with the information. That means you can continue to monitor and test, even after you’ve shipped the software. After all, you can still use what you learn, just in the next release.

How should you test?
Pretty much anything is fair game in testing. There are some guidelines and techniques that we can cover, but if it gets the information you need in a repeatable and sound manner, then go for it.

Why should you test?
You should test to get information that you can use. If you don’t have a use for the information you’ll learn from a test, then don’t bother doing the test. If you don’t know what information you might get from a test, then you need to better define your test (translation: go talk to someone who tests for a living).

For many testers, this is "back to basics" information. For someone new to professional software engineering, though, basics are a great place to start!


  1. My test strategy matrix has these 6 questions:

    Who (Identify the Testing Personnel)
    What (Understand the Requirements/Functionality)
    When (Know the Testing Schedule)
    How (Use the Testing Techniques)
    Why (Analyze the Impact)
    Where (Configure the Test Environment)

  2. I think that your "who" should be - anyone with common sense.
    btw, this reminds me of an article about teaching programmers to test:

  3. I think the most important thing under "who" is "anyone with common sense"...

  4. Nice post. The best answer should come from someone who has experienced working with an independent software testing company. Who should test, what should be tested are basic question however, how to perform testing is a crucial aspect.