Almost every process existing comes with it’s own share of understanding at individual level. Software Testing itself has always been a debatable topic and is surrounded by many myths all of which have counter facts associated with them. Head on to the post – Software Testing Myths and Facts to read some of such misconceptions.
Coming back to Agile Testing, below are common assumptions many teams have:
• Agile means
• ZERO documentation
Documentation is yet another critical process project teams run away from. With Agile in force, it is a generic response to get that – “Since we are following Agile, there is no documentation of requirements and other details”. Actually, If followed sincerely, The end result of an Agile project would result in much better and detailed documentation which would be well structured, easy to read and follow.
• No planning
Ask an agile team for their project plan, the maximum they would be able to provide is the current or current + next sprint backlog. On the contrary, Agile process insist on having the sprint backlogs ready for current along with upcoming 2 sprints along with all the estimates and acceptance criteria. Thus, in practice, planning in agile projects is more rigorous.
• Unit testing
• Is sufficient and thus remove the need for manual testing
It is a common misconception that if Unit Testing is performed effectively, testing activities may be skipped. While it is true that unit tests play a significant role in reducing bugs, the fact that they cater to specific and limited scope must be considered as well.
• Can be built into regression suite
In continuation to the point above, creating a regression suite from unit tests is also seen as a practice in some teams. Projects must understand that Regression Testing is altogether a separate activity with it’s own scope. While some of the unit tests would always be common to both regular test cases as well as Regression Test Cases, compiling all the unit tests in one place and calling it a regression suite is a complete no-no!
• Is impossible
Test Automation in Agile development projects is sometimes considered an impossible task! The main reason for the same is lack of time. But then, I think, the remedy to this points to the very first myth – “Agile means No Planning”. The need of Test Automation and scope for the same must be a part of planning process from the very beginning.
• Remove the need for manual tests
With automation in place, projects tend to avoid manual tests in respect of time and resources. Since, It is not possible to cover each and every case in automation, Manual Testing can never be replaced by Automation Testing. Even if the tests show 100% coverage in reports, exploratory testing generally done unintentionally as a part of manual testing would be at loss.
• Testing is not a part of ‘Done’
It is quite typical with the development teams to mark a story done after implementation from their end even before it is tested. Sometimes, to get the burndown chart right, teams even move the user story to “Done” state if it has a bug associated with it. The explanation with these cases is that the bug thus raised is already in backlog, so the user story should not move forward. In ideal practice, any story is not “Done” until is has been tested successfully with no pending bugs associated with it.
More Topics in this series: