Skip to main content

Best practise for covering unit test development of existing code

Last post 06:56 pm January 10, 2019 by Daniel Wilhite
4 replies
03:17 pm January 10, 2019

Hi guys,

we have a product that has been in use for some time now but with very little in the way of unit test coverage.

Going forward in our sprints we are featuring unit testing as a task in the delivery of a user story.

However, we have existing code/functionality that is not yet covered by unit testing and i'm wondering how best to allot time for that in the sprints as we increase that coverage..

Should I create a user story in each sprint for 'retrospective unit test coverage'?

Should I just reserve some time and not bring as many stories into the sprint during planning so that we have some time available - but not specifically call it out?

any other suggestions?

 

regards,

Matt

 


04:11 pm January 10, 2019

It’s up to the team to decide. Do you think it sounds like a credible user story though?Why not just include a criterion in the Definition of Done to increase code coverage by a certain percentage each Sprint increment?


05:15 pm January 10, 2019

Hi Matt - I often talk with teams that inherit an existing product, which has no test coverage.  This is simply technical debt that must be paid back over time.  I agree with Ian's point about the Definition of Done - a good step to take

What I also see as an additional, effective technique is to make all of the technical debt transparent to your Product Owner, helping them understand how technical debt negatively impact team health (who wants to work in such a code base - developers may leave), slows the output of the Development Team, and adds to quality problems due to lack of automation.  Then come up with a working agreement in each Sprint Planning session between the Product Owner and Development Team as to how much of the technical debt will be paid back (e.g let's reserve 10% of capacity to write missing unit tests).  You don't have to write user stories for this.

 

Chris


05:29 pm January 10, 2019

Hey there,

I agree with Ian when he says "include a criterion in the Definition of Done to increase code coverage by a certain percentage each Sprint incremen", do that and than let the team decide what the best way to complete this DOD. I worked at the same way in a team in 2018 when our DOD was something like "coverage must be at 90%" so every retrospective we see our Coverage indicator and if its bellow 90% we put a item in our backlog to "ajust" that.

Now in my experience the point here is not the tecnical part of doing de coverage, I really belive that you team can do this, but the point here(that i had troubles) is how we convince the user, client, PO and etc to spend time(or money) in coverage tests.

And the answer for me when this happened in my team was saying that every sprint they will have a increment with quality, so my client/user/PO was comfortable enough to let the team do Spikes, Devops Automation or any technical thing that does not affect the user/client directly(like a new front, or functionality).

 

This was the trick for me here when I had the same situation in my work, change the mindset,and it did not work at the first time, I needed to be very insistent and resilient to let the they comfortable with that.

 

 


06:56 pm January 10, 2019

As everyone has said, you are asking the age old question of how to deal with technical debt.  And true to Scrum, all of have seen/done this many ways and you will always get answer of "the team needs to decide the right way to handle it".  That is absolutely the best answer you can get. 

Should I just reserve some time and not bring as many stories into the sprint during planning so that we have some time available - but not specifically call it out?

If you read the Scrum Guide correctly it there is no one that can make that call.  There is nothing in the guide that mentions limiting the number of stories included in Sprint Planning.  It just says that the Sprint Backlog is created from Product Backlog items. It discusses how PBIs should be refined enough that the Development Team can agree it can be completed in a single sprint. There is also mention that the Development Team controls what constitutes the Sprint Backlog.  

I'll you go and ahead give you a suggestion for how I approach it so that you can have one more perspective.  Facilitate the entire SCRUM Team in a discussion about it.  Help the PO understand that Technical Debt actually has 2 values, negative if you ignore it and positive if you fix it.  Then working with the PO, introduce stories into the Product Backlog. The PO is responsible for ordering the PBIs in a way that ensures the Dev Team is providing the needed value and everyone should honor that.  If they don't have stories or understand the value derived, then they will always order new ideas above technical debt. Transparency is key.  And in every case, the Scrum Teams have decided how they want to handle this.

 


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.