≡ Menu
Pawel Brodzinski on Software Project Management

What Is the Main Benefit of Writing Test Cases?

Test cases are here for a long time. Used equally willingly by these who work with heavy-weight processes and those who choose the agile way. They can be stored in an appendix to documentation in BDUF (Big Design Up Front) project or be written on yellow cards along with user stories. Where’s their main value then?

Think about the comparison: test cases for application functionality are the same as unit tests for application code. Except of one thing: it is way harder to write good and complete list of test cases. You may safely assume that’s impossible. This means the main value of test cases isn’t in covering full application functionality because you simply won’t achieve that, no matter how hard you try.

Well, maybe it is a valuable tool for QA engineers? You know, they have some kind of walkthrough for testing sessions. Hm… show me quality engineers who prefer just to follow test cases instead of explore the application by themselves and I’ll tell who should be fired. Testing is such a creative task that there should be no place for follow-the-manual people in QA teams.

OK, test cases don’t ensure completeness of tests and don’t help QA people much. So? Show me the money, as one of my customers used to say. Where’s value?

The main benefit of test cases lies in the activity of writing them down. Or, to be more precise, in the process of thinking about them before they’re written down.

Test case is not much more than short scenario of application usage. Sometimes pretty weird scenario but still. Unfortunately we often forget about this perspective. We tend think in terms of code or requirements and forget about the very basic thing – no class in the code and no requirement alone makes any sense for the end-user.

Looking at application while being in end-user’s shoes benefits in two ways:

- You find black holes of your design which aren’t covered with user stories, or requirements

- You find usability issues since you see whole usage flow, not just a bunch of atomic functions

The main value of writing unit tests is actually within the writing part.

in: software design, software development

9 comments… add one

  • johnfmoore May 13, 2009, 1:58 pm

    Pawel,

    Good post, I agree. QA Test plans derive most of their value from the initial writing, the thought processes that go into that writing, and the first iterations through the code while writing the test cases.

    Blindly running through older test cases is one of the main causes I have seen for missing obvious product bugs as people who blindly follow the test plans often put aside the creative aspects of testing.

    John

  • steve May 14, 2009, 5:37 am

    Writing Test cases has some benefits.

    1. Delivery to offshore testers, particularly if development is onsite

    2. Test Design, it helps you design how you will test the product, much like a developer who is designing how he or she will program the software

    3. Repeatible process, particularly useful if bringing in a new tester

  • Paul Marculescu May 14, 2009, 6:11 am

    Test cases are a prerequisite for regression testing.

    Let’s take an example.
    You test the signup page in your web application and notice that even if you don’t enable the checkbox “I agree with the terms and conditions” you still get your account created.

    You mark it as a bug and write down how to reproduce it – that’s a test case. On the next build, you go through the test cases you wrote and check if they pass.

    I see no other way of being able to do this regression testing, unless you write down these test cases.

  • Pawel Brodzinski May 14, 2009, 10:30 am

    Steve,

    For me the second poing you bring is especially important. That’s exactly looking at the application via user eyes. And you look at the whole flow, not just one particular function.

  • Pawel Brodzinski May 14, 2009, 10:33 am

    Paul,

    Yes, but… Actually one of problems with test cases is that you can hardly keep them up-to-date. If you’d like to generat test case from each bug you find you’ll be soon overwhelmed with a number of test cases.

  • Laurent June 3, 2009, 6:18 am

    To Paul and Pawel,

    Those tests case should be automated.

    Then, it doesn't matter how many of them they are.

    So, you will still be confident that the new build doesn't break a previously fixed bug. This also gives increase the developer's confidence, since he knows that if he make a mistake, there are good chances it will be catch by those regression tests.

  • seenu April 24, 2010, 4:45 am

    Hi All,

    can any one tell me “what are the mandatory documents for the requirements phase”

  • Pawel Brodzinski April 24, 2010, 4:52 am

    I believe there is no such thing as mandatory documents for requirements phase in general. It depends heavily on environment you work in. If you think about agile projects you can do good with just a set of epic stories which describe on high level what the application should do.

    On the other hand if you work with one of highly formalized environments you may have a very detailed list of artifacts you have to produce to comply with methodology which is in use.

    So unfortunately there isn’t single answer to such a general question.

  • gopi September 19, 2013, 12:54 am

    Hi all,
    can any one tell me “What is importance of RTM (Requirement Traceability Matrix)”

Leave a Comment