automate tests later
"Ideally, all test cases are supported by automated tests, but depending on the available technology and testing possibilities, they may be manual. It is also possible to develop the test cases manually and automate them later, e.g., during a future Sprint." - these statements are included in PSD class student workbook (v6.2) in "Test in Parallel With Coding" section.
A product backlog item for developing a functionality and complete testing using manual testing. And in next sprint, create automated test cases using another product backlog item. In this way, we are separating out all the testing activities. This is a good practice? or this is contextual.
Would like to hear from the forum.
Thanks,
Thota
Why do you believe that the testing of work would constitute a good Product Backlog Item at all?
Your approach may work but it is also doing nothing but contribute to your technical debt in every sprint. If you can be assured that you will be able to address the story to add the tests in the very next sprint, then you may be able to get away with it. But how long do you think it will take before the "test" story is bumped because of priorities of adding another new feature? And if you deliver more than one new "feature" in a sprint what are the chances that you would need the entire next sprint to do automated tests? Is that delivering a potentially shippable increment that provides value?
If the company values automated testing then why would it not be part of your work to deliver the feature, possibly even incorporated into the Definition of Done?
Unless the automated tests are deliverables, don't do it. and pile up the backlog unnecessarily. If the business demands, it's only then that you may go for automation. Because the primary focus of the scrum should be to deliver the MVP of a complex problem. and not automate. Automation comes as enhancement.
Unless the automated tests are deliverables, don't do it. and pile up the backlog unnecessarily. If the business demands, it's only then that you may go for automation. Because the primary focus of the scrum should be to deliver the MVP of a complex problem. and not automate. Automation comes as enhancement.
Why would business care if the tests are automated or not? Business cares about quality! It's the development team's job to deliver with quality.
To put it another way: A Scrum Team is tasked with developing a product at a sustainable pace and producing a release-quality product increment every four weeks. How sustainable would it be for the team to keep testing everything manually? Wouldn't the team end up with a situation where testing the full product increment might take up more than half the sprint or even longer at some point?
Given that Scrum demands a release-quality increment in ever Sprint (which is a month at max.) test automation is crucial to the success of a Scrum Implementation. Otherwise, how will you make sure all parts of your software still work as intended after you've been developing it for three years? Unless you are in very special circumstances, test automation is one of those pracitices the Scrum Guide doesn't specifically mention but very much implies.