Avoid test cases in agile?
In agile testing, i get a need to document test cases also even though we have less resources of time and effort. For my belief, agile should accept only exploratory testing and document the defects. But still without test cases, i may miss out some of the test scenarios from the requirement. So can anyone explain me best possible way to test in agile on both approaches of test case driven and ET considering very less time.
Remember that Agile doesn't mean quick and dirty, just as Exploratory doesn't mean it.
There are countless ways to manage your testing as part of an Agile project, what I can do is to explain how we do it at PractiTest and this is also how some of our users do it too.
The main principle we try to follow is to use a balanced blend of scripted and session-based tests.
When we are working on specific features and verification testing we run Session Based tests, and we obviously document these sessions in our system.
But we also have scripted tests that cover the same features, and as part of our testing operations we can choose to run these tests to complete the verification process.
One of the things that allows us to do this is the fact that we have, as part of the tasks to every user story, time set aside to update tests that may be linked to this feature. But we still need to remind the rest of the team about the importance of performing this tasks, and at times we even need to compromise on this.
Something else ti take into account is that many times we can use part of the session logs we kept during the SBT and re-use them as the basis for our feature scripted tests.
In any case, just remember that, if your product requires scripted tests it should be the responsibility of the whole team to make sure there is time set aside in your user stories to write them.
I'm seeing a few new startups playing with the idea of writing the requirements in a form of test cases.
This has a nice added benefit of managing test cases and requirements in the same tool. The downside it takes more up front work when planning. You might be taking 2-3 days in a typical 2 week sprint in planning, vs. 1/2 day planning in a normal 2 week sprint.
Thank you for the good explanation.
There are certain benefits that Exploratory testing brings into agile along with some challenges!
I tried to document them sometime back and created a guest blog for it on a testing blog... I hope this helps in better understanding of both benefits and challenges.
Agile never says 'no test cases'. It only says write only those scenarios which you want to test now (current sprint or next sprint). Avoid writing test cases for a feature planned for implementation in future or test cases which you don't want to execute now or immediate next.
Regarding testing, again, agile doesn't tell to avoid regular planned testing. In fact, it stresses on incremental integration testing, and also stresses on automation, because there will be need to do regression testing in every sprint.
Last edited by landu; 11-29-2015 at 10:01 PM.
Reason: Added signature
Very aptly put @landu
Originally Posted by landu
But adding a flavor of exploratory testing into each agile sprint proves very useful. You could define a phase (like 1 day at the end of the sprint or test cycle) for exploratory testing and don't refer to test cases in place for that 1 day. You will definitely feel more free in exploring the application and find new ways (read 'simulate user behaviors') of identifying bugs.
Bottom line - A mix of both works amazingly for teams.