Rusty Definition of Done updates

[Sebastian_Brudzinski (Sebastian Brudziński)]

Hey all,

our Definition of Done hasn’t been reviewed or updated for a while. Some of the points are no longer relevant (e.g. we don’t have component leads), and as such we would like to propose several changes to make our DoD up-to-date and relevant.

After updates, we would want to start monitoring it more rigorously, with a checklist attached to the Jira issue.

The current DoD is

1. Functionality described in the story is implemented and accepted by the Product Owner. Technical tasks are accepted by the Component lead.
2. Unit tests are written for any new code
3. Updated RESTful interfaces are included in test automation
4. Code has been peer reviewed, committed to the development branch and builds clean
5. Story has been reviewed via the TEST or UAT build (not on a dev box!).
6. No open "Blocker" or "Critical" bugs are open on the story (e.g. bugs found during testing)
7. CHANGLOG entry is added for all services impacted during work on ticket.

A Definition of Done (DoD) for Bug is following:
1. **1-7** from above apply.
2. New unit tests are added that wouldn't pass before fix, if possible.
3. Bug root cause analysis is done and the Bug Root Cause Analysis page is updated.

Here is the updated DoD we propose (changes in bold).

1. The functionality described in the story was implemented (or bug fixed) according to the provided acceptance criteria or reproduction steps.
2. Test coverage for any new or modified code is at least 80%.
3. Updated RESTful interfaces are included in test automation.
4. Code has been committed to the development branch and builds clean on CI server (including tests and static code analysis)
5. Code has been peer-reviewed by at least one person who wasn’t directly involved in the development and the code review feedback was addressed.
6. Story has been reviewed via the TEST or UAT build (not on a dev box!) and the summary of the conducted tests has been attached to the ticket.
7. No open “Blocker” or “Critical” bugs are open on the story (e.g. bugs found during testing).
8. CHANGELOG entry is added for all services impacted during work on the ticket.

We have also been wondering about the relevance of the Bug root cause analysis page from the DoD for bugs (https://openlmis.atlassian.net/wiki/spaces/OP/pages/113248022/Bug+Root+Cause+Analysis). Given that we often work on bugs that were reported several months or years ago, diving deep into the cause of those bugs back then might not bring much value. I’d propose that we either drop it or only include new regressions in this requirement.

Please let me know whether you have any concerns about the updates to DoD. Given there are no objections we will make those updates go live next week.

Best,
Sebastian

[joshzamor]

Hi @Sebastian_Brudzinski,

No major concerns.

@Sebastian_Brudzinski

Test coverage for any new or modified code is at least 80%.

We’ve stayed away from this in the past as some packages are just better to not hit this; usually DTO type packages. Are we sure we want a blanket 80% target?

@Sebastian_Brudzinski

We have also been wondering about the relevance of the Bug root cause analysis page from the DoD for bugs (https://openlmis.atlassian.net/wiki/spaces/OP/pages/113248022/Bug+Root+Cause+Analysis )

Are we wondering because it’s not useful, and because we haven’t updated that page since 2017? The goal of that page/process was to curtail some of the repeated mistakes we were making then. i.e. we’d fix a symptom while not addressing a root cause, and then have the same/related symptom pop up shortly again after “fixing”. How’s the team doing in that regard?

[Sebastian_Brudzinski (Sebastian Brudziński)]

Thanks for the comments @joshzamor

@joshzamor

We’ve stayed away from this in the past as some packages are just better to not hit this; usually DTO type packages. Are we sure we want a blanket 80% target?

I was convinced we still have this in the Sonar quality gate, but maybe that’s not the case… I also recall that in the past for DTO classes we had some kind of automated verification (generated tests for trivial setter/getter checks).

@joshzamor

Are we wondering because it’s not useful, and because we haven’t updated that page since 2017? The goal of that page/process was to curtail some of the repeated mistakes we were making then. i.e. we’d fix a symptom while not addressing a root cause, and then have the same/related symptom pop up shortly again after “fixing”. How’s the team doing in that regard?

No, I mean mainly because of what I stated in the original post. The question is whether it makes sense to come back to bugs that were created 2 or 3 years ago and analyze their root cause. I could see the added value for the bugs we recently found and decided to fix (especially new regressions and critical bugs) as this may show inefficiencies in the process we currently have and allow us to adapt.

Best,
Sebastian