Are test cases getting diminished in agile software development?
"We don't have time to write test cases in agile model."
"We don't need test cases as we're directly writing automation scripts."
"There is no defined QA role in agile model as all are engineers only."
"Agile suggests less documentation and hence test cases aren't required."
I am sure many of us would have observed or heard one or more aforementioned statements either in our organisation or while talking to your friends working in other organisations.
There could be various context or rationale in which above conclusion(s) would have been made and whatever they are, there is declining trend in qualitative aspect in which test cases are being maintained. I am sure there will be organisations which are maintaining them diligently and wanted to surface gaps so that it can be pondered over and corrective action can be taken.
Here are some vital points which emphasise on having structured and up-to-date test case (TC) repository:
- How to find what's total count of TCs we have for respective product or application?
- As we know that 100% TCs can't be automated, either due to business reasons or technical limitations, how do we find out list of TCs which needs to be manually executed while performing regression testing?
- How do we find out backlog of manual TCs which needs to be automated?
- How do we track gaps in test coverage which got surfaced due to a bug reported at production environment?
- How do we have traceability of new TCs which got added due to new features added in new releases?
- Some teams maintain TCs using spreadsheets and/or wikis and how various summaries are being generated?
- How a QA engineers shares TCs w/ developer that s/he authored (for ensuring that they are covered) for a new feature before a story is handed over to him/her for testing?
- How new member(s) of team understand complete scope or coverage? Yes, there are KT sessions and we all know effectiveness, limitations and time delays associated with them.
We need to have a holistic approach which arriving at conclusion and not just w.r.t. current context. We need to put ourselves in shoes of person who may own our roles/responsibilities and if s/he can manage it w/o much of hassles.
Hope this helps and provides us few pointers which help us in effectively managing TC repository for our applications. Love to hear your feedback or comments about it.
Senior Software Engineer at Microsoft
6 年Hi Manoj, you have picked up real pain points here in agile and I would like to share how my organization handles it.? 1. QE associates particular manual/automation test cases to related story. And add a tag to the story like 'Scope for more testing' if QE feels that more test cases should be added later to that story. 2. While working on a story QE adds a tag accordingly for 3 options (a. Automated b. To be Automated c. Can't be Automated). That way, it is very easy to see summarized report and once QE have time then they can automate remaining scripts. 3. It is mandatory for every developer to write at least one integration test case (manual/automation) before moving any story to 'Ready for Testing' phase. 4. If any of the automation script started failing during daily run, it is respective developer's responsibility who submitted culprit code to fix that automation script.
Quality Engineering Leader | Digital Transformation | Cybersecurity
6 年Hi Manoj, your pointers are correct on test cases and its uses on test coverage, candidates for automation, gap analysis, live issue RCA etc. Having said that it is becoming increasingly "popular" now a days to reduce efforts on test case writing/ management in the name of agile. In my view a balanced approach is to be developed where in we are writing key test cases / use cases and too much efforts on this activity can be avoided. Couple of years back, test case writing for a feature used to take 3-4 days, and now entire sprint is of one week. Time is changing and we will have to continuously innovate without deviating focus on quality.
Engineering Leader | Product & Engineering | ISM & Application Foundation Services | IIM-K Alumnus (Gold Medal)
6 年Somehow I am inclined to think Agile as Chaos. Here role of a third party scrum master is of foremost importance - else it becomes either client's mindset to exploit or vendors leverage on committed work.
Manager - Amazon
6 年Theoretically it should not since Agile keeps testing and its strategies first... While practically it does no matter how hard we try ... They get diminished to changing requirements, fast deliveries and lesser resources