Do I Need to Write Test Cases in Agile Testing?

Should I write test cases in agile testing?

Do you come across this question a lot? Or, are you the one seeking an answer to this interesting question?

Well, I come across this question quite often.

In one of my previous articles on QST, I wrote about benefits of exploratory testing and common challenges faced during Exploratory Testing.

In this article, I am trying to look at different aspects of agile testing to help you decide whether to write test cases in agile testing or not.

In a more traditional approach of testing, you have clear demarcations between different phases. You first gather requirements which come in the form of use cases or BRS/SRS documents.

Then you plan your tests and start designing your test cases.

When you are busy performing these activities, development team is busy coding the new features to deliver to test. You have a clear plan of when is the code drop planned for testing.

Ideally, you have a defined phase of when your test case execution starts and when the planned completion date is.

In traditional approach, there is a lot of test documentation produced which needs maintenance throughout the project.

As a result of this, testers end up with lesser to test (almost nothing!) available to test toward the start. And by the end, they have a hundred things to pick up and the entire focus is on testing.

In Agile, you work in short sprints/iterations and focus to deliver small features to live at the end of sprint cycle taking the MVP (Minimum Viable Product) approach.

As you have only a few new requirements each sprint, and agile focuses on continuous testing, you end up having lesser documentation.

Agile advocates the principle of “working software over comprehensive documentation.” [Check agile manifesto]

This doesn’t mean that all documentation is unnecessary – documentation is necessary but it is not that important.

Definitely, not as important as working software! Coming to the big question…

Should I Write Test Cases in Agile Testing?

1. A mix of documented Test Cases, and Exploratory Testing works!

In traditional way of testing, you often end up having a lot of test cases. As you add more and more test cases to your repository, over time, it becomes difficult to maintain them.

And, don’t discount the time you spend on writing them in the first place.

Now, you can continue making your life messy in agile too because there is no one stopping you from doing that.

OR, you can try to have maximum coverage still keeping the total number of test cases low by covering major scenarios in different verification steps of the same test case.

This does not mean you shouldn’t test not-so-critical verification steps at all. Just don’t write them as test cases and keep growing the count.

Instead, try to cover them during Exploratory Testing.

2. Checklists and MindMaps work!

Instead of writing test cases in agile, you can also opt for preparing a check-list which lists all critical checks you need to do.

You might just end up with one-liners but it will solve the clause of having some test documentation and also make sure you do not miss anything. Running this check-list besides general tests covering major scenarios does the trick!

In software testing, there is no ‘one-size-fits-all’ fix to everything. One approach that worked wonders for one project might lead to a complete disaster for you.

So, you need to evaluate each project / product that comes on your desk on a case-to-case basis and decide what works best for you.

The ideas I have listed above works if you have a rapid development environment and you have a team who trust their testing team and believe in what they do. (I know it’s hard to find such a team!)

If you are in a contract where you might end with questions at the end of the cycle “Show me what you tested!” and need to produce test cases as evidence of what your test case execution included, you should opt for writing well-documented test cases.

This might happen in life-critical industries like health where writing detailed acceptance criteria is a must. Softwares used by doctors and medical professionals cannot go wrong.

If you have an enterprise product which doesn’t undergo changes too often, writing elaborate test cases might actually work for you.

Because you will be running the same test cases over and over, you will get the value for money and effort invested.

So there you have it.

I hope I was able to throw some light on this topic and to help you find an answer to the question whether you should write test cases in agile testing or not.

I would like to know what approach you take – so drop in your comments below.

Editor’s note: This is a guest post by Sanjay Zalavadia, VP of Client Service at Zephyr. If you would like to give back to the testing community, you can send in your guest posts via this form.