≡ Menu
Pawel Brodzinski on Software Project Management

Using Test Cases during Testing

Consider the situation. You have your application ready to start tests and you have a bunch of nice test cases. You meet with your QA team where you see some fresh faces so you are about to tell them how you’d like them to do tests, especially how they should use your nice test cases. What do you say?

I’d tell them to forget about test cases for the first iteration of testing.

Why? It’s not because I believe the main value of writing test cases is the writing part. It’s not even about one of shortcomings of unit tests – risk of turning creativity off and blindly following the scenario.

The reason why I’d like to see my fresh QA team left unguided at the beginning is that I get a pretty unique occasion to have an unbiased eye to look at the application. Someone who doesn’t start with scenarios proposed by designers of the app and considered during development. Someone who just tries to figure things out and hits the wall hard with her head if there’s any.

Of course it works better with freshmen but even when you work with people who actually created test cases the advice is the same. After some time they won’t remember every detail they had thought of when designing tests. They’ll be back in the starting point, except they’ll be working on the real application, not the set of requirements or user stories. And that will make them think differently.

After the first iteration of tests go back to your test cases and tell QA people to go through them. Odds are they’ll be able to check out many of them after the first stage. It’s important to make sure that areas omitted during “figuring things out” part of testing are covered. After all writing part may be the most important but isn’t the only reason to write test cases.

You can also check: What is the main benefit of writing test cases?

in: software development

5 comments… add one

  • Krish July 9, 2009, 12:50 pm

    Interesting point. It is always useful to get a fresh perspective from persons uninitiated to the project. They always ask questions that help you rethink what you are trying to do.

  • Josh July 9, 2009, 8:32 pm

    I think this is a great point Pawel!

    If nothing else, this would serve well as a usability test. How intuitive is the interface? If you have done a really great job with it, someone who is untrained and without a guide should be able to sit down and start using at least some basic functionality.

    Josh Nankivel

  • Pawel Brodzinski July 10, 2009, 1:19 am

    I was always a big fan of exploratory testing when you don't follow beaten tracks but make your own journey through the application. Test cases are nothing more but a web of beaten tracks, which of course must be checked, but if we limit ourselves just to these paths we limit our chances to improve usability, ergonomics, GUI look & feel etc (as in your examples).

  • Josh July 10, 2009, 1:36 am

    Not only that, but with an unscripted run there is the possibility of uncovering bugs that wouldn't come out in the test cases.

    For instance, the user clicks on control b, then a, then c. That particular combination is nowhere in the test cases, but it ends up generating an error that needs to be handled.

    Josh Nankivel

  • Pawel Brodzinski July 10, 2009, 2:37 am

    Which is by the way one of problems with test cases – you can't cover every possible scenario with test cases.

Leave a Comment