Skip to main content

automate tests later

Last post 07:37 am November 20, 2018 by Julian Bayer
4 replies
12:00 pm November 19, 2018

"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


03:45 pm November 19, 2018

Why do you believe that the testing of work would constitute a good Product Backlog Item at all?


04:22 pm November 19, 2018

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? 


05:01 pm November 19, 2018

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. 


07:37 am November 20, 2018

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.

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.