Traditional test case writing practices are extremely inefficient<\/p>\n

When I say traditional, this is what I mean:<\/p>\n

– After sprint planning, tester goes to his little corner and studies the user story \/ requirement
\n– Then based on hunches and how the day at the office was, figures out some test scenarios
\n– Next go about writing those tests ‘in detail’ and link them to requirements for traceabiility
\n– Once the feature is marked as ‘ready for QA’ then ‘executes’ the tests
\n– Then send reports based on the ‘test case execution results’<\/p>\n

Next sprint, the PO want’s to try some changes in our user story, and the tester starts the cycle again – or chooses to not go through that hassle and leave the tests outdated.<\/p>\n

Now that’s traditional 15 years old stuff – it never worked back then, and certainly does not work today<\/p>\n

Then there’s the transformed ‘Agile’ team. In thier mind, since their agile they don’t write ANYTHING – that includes any kind of tests<\/p>\n

Now the test coverage depends even more on our tester’s mood swings and the weather outside!<\/p>\n

None of these approaches work, and certainly are not efficient of effective.<\/p>\n<\/div>