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.
In agile we do need test cases. Based on stories, we create test scenarios and based on test scenarios, we create test cases. You shared very informative content Sanjay, appreciate it.
Nice article. Instead of spending time in writing test cases, I think a checklist along with exploratory testing does wonders in Agile environment.
1. Maintenance is less
2. No need to run test cases in zephyr or any other TCM tool
3. Testers can focus on application more rather than on test cases.
Only Con I see of the above approach is how to showcase what all has been tested to stakeholders.
Thank you for providing this useful information.
I face issues in performing agile test cases, but I will surely follow this and complete my project deadline.
When should we write test cases when product is under development or when it is finished?
When product is under development a lot of consecutive changes are done. Is it worth to write them during development cycle and then revise them again and again?
Please also consider the time factor.
It doesn’t matter what methodology I’m using I still write test cases. If you are using Agile you are just constraint by time but the same coverage is expected.
That’s right, Darren. Having a good coverage is key. That’s why I think having a mix – test cases as a guideline and having a window dedicated to exploratory testing – works very well. I have ended up unfolding some very interesting defects that come open only when you run the tests as a user and not restrict to any scripted tests.
thank you for giving such a useful advise
it will be really helpful for me
Thanks mate for your comment!
But you do not need to put the same comment on all articles. If you want to add value to article by adding your views, that will be helpful!