2


I am working in sprint. At the end of sprint I need to send a defect report per sprint. Considering the below scenario please let me know your views.

Two teams(A & B) are working at different locations in Sprint-2 and I am a tester from Team-A and report the defects for the items developed by Team-A in each sprint

Question
1. I reported few defects in Sprint-2 for the functionality developed by Team-B in previous sprint. Do I have to consider this as observation or defect and report to Team-A?


2. I reported 5 defects of Sprint-2 for the functionality developed by team-A. All the defects are fixed and closed by me in the same sprint. Before the end of sprint I observed 2 defects got reopened for some reason. Now the defect count should be 5 or 7(5+2) should be considered for this sprint?

Thanks
Khan

migrated from stackoverflow.com Jun 11 '14 at 10:04

This question came from our site for professional and enthusiast programmers.

  • 6
    I'm a little confused as to why you're reporting defects within a sprint. My understanding is that work is 'done' or 'not done' within a sprint. Being 'done' would imply no defects. Not being done implies more work needs to be done so identifying defects is futile. Can you elaborate? – Derek Davidson PST PSM II CSP Jun 11 '14 at 9:21
  • I totally agree sprint is measured work is "done or not done". To keep track of defects created in sprint we are maintaining the report. This will help the developer to understand the defects being created in each sprint wrt user story, so that they can focus on reducing it in future sprints and to let the other team due to these defects those particula user stories are not closed – user3728779 Jun 11 '14 at 9:34
  • @DerekDavidsonPSTPSMIICSP: "Being 'done' would imply no defects" - So you don't have any more defects in your software after someone says it is "done"? – JensG Jun 11 '14 at 10:20
  • 2
    @JensG Sure, defects occur after work is 'done'. But they usually surface after the sprint in which the work is done. This is simply because work that is done, by definition, has no known defects. – Derek Davidson PST PSM II CSP Jun 11 '14 at 10:25
7

I think there's a fundamental issue with the definition of 'done' in your example.

If a 'defect' is identified within a sprint, I'd argue that there is no defect. The item is simply not 'done' and should be re-worked until it is. I would amend the definition of done to include the requirement that items have no known defects (if it isn't already included).

For defects identified after the sprint is finished, simply create a new item to fix the defect.

With regard to the report that you are creating, I have trouble understanding its value.

I think the place for a developer to understand that their work may be below par is either during the sprint or at the retrospective, from their peer group. Not from a report.

Also, if your definition of done is clearly stated, there is no need to let other teams know that items have defects and so, should not be considered 'done'. Items are 'done' or 'not done' at the end of a sprint, irrespective of whether defects arise later.

  • I agree that if its "not done" user story will not get closed. From a tester perspective to define the quality of the user story we need to identify the defects per user story. If no defects then user story is good incase if its has 1/2/3... then i have to report the defects. Based on this I asked above questions – user3728779 Jun 11 '14 at 11:27
1

Something seem wrong: It sounds like the tester (you) is not a part of the team but is a sort of outside assistent, reporting on errors.

If you think recording all errors helps quality, why stop at bugs that you find as a tester? Why no record bugs that the compiler finds? Why not record unmatched parenthesis or uninitalized variables, which the compiler reports about?

Three rules-of-thumb and one workflow:

  1. Within a Sprint, you do not waste time recording bugs - you fix them.

  2. You do not deliver work with known errors because it is not 'done'. You don't need to file bugs on workitem N, because the programmer is not 'done' with workitem N. He is only 'done' when everyone agrees it is done, it complies with the definition of done, and there are no errors in it (not that I just said the same thing in 3 different ways). Only then does the programmer go on to the next workitem. So there is no need to record the erorr.

  3. When dealing with an error, especially from other Sprints or Teams, follow this workflow:

    • can the programmer fix it in < 4 hours? If YES, then fix it. Done
    • if not, can the Team fit it in the current Sprint? If YES, then put it on the Scrumboard and fix it. Done.
    • If not, take it up with the Product Owner. The error can not be fixed in the current Sprint. Can he place the error as a Product Backlog Item on the Product Backlog to be fixed later? If YES, then put it on the PB.
    • Last and least desirable option: If it can't be fixed together with the current Sprint, and it can't be postponed, the PO can abort the current Sprint. The Team moans and then fixes the error.
0

In your statistics report on the number of defects you should differentiate between different kinds of defects:

  • Defects on stories that have been delivered in previous sprints. Unless the teams consistently work on separate parts of the application (i.e. a front-end and a back-end team), there is not really a point in separating these defects out per team.
  • Defects on stories in the current sprint that were found and fully fixed.
  • Defects on stories in the current sprint that are open at the end of the sprint. It doesn't matter here if the issues has been closed and reopened during the sprint. Only the status at the moment of the demo is relevant.

The first two categories can then be subdivided further by issue resolution (fixed, duplicate, rejected).

This way, there is a clear distinction between the number of issues related to current work and the number of issues related to past work.

When dealing with defect statistics, there are two things that you should be careful with:

  1. Multiple defects in one report.
  2. Morphing defects: After fixing the original defect, the same ticket gets reused to report a different issue.

Both are a nuisance when solving/verifying issues, but they are an outright nightmare for the statistics. In both cases, it should really be reported as multiple, distinct, issues.


Regarding whether stories are done if there are defects open on them: Generally, a story should not be considered to be done if it has open defects associated with it, but you should also allow the Product Owner to accept a story anyway if, in the opinion of the PO, the defects are not important enough to block the story on.
There can be business reasons to accept minor issues with a product, but that call can only be made by the representative of the customer (i.e. the Product Owner).

0
  1. I reported few defects in Sprint-2 for the functionality developed by Team-B in previous sprint. Do I have to consider this as observation or defect and report to Team-A?

This depends on whether or not a user story in Sprint-2 passed or failed. If it is a failed user story in sprint-2, report the failure and mention you think the cause is in Team-B's code and let the developers figure it out and get this test to pass. Or if the Sprint-2 user story test passed but you noticed something else failed, create a new bug report item so it can be fixed in the next sprint.

  1. I reported 5 defects of Sprint-2 for the functionality developed by team-A. All the defects are fixed and closed by me in the same sprint. Before the end of sprint I observed 2 defects got reopened for some reason. Now the defect count should be 5 or 7(5+2) should be considered for this sprint?

This is purely up to your team/company on their rules for counting defects and how they are interpreted. If someone wants a low defect count to curry favor or avoid punishment, some may want to have rules that encourage "when in doubt, enter failure) or if someone is gaming the system and wants to look good because they found/fixed a lot of failures, the rules may be in such a way "when in doubt, don't create additional failure counts". When too severe of consequences or rewards are contingent on these failure counts, regardless of the direction, people are going to skew the values and game the system.

Lines of code for example may be a better measurement of size/complexity of an app if calculated when an entire project is completed and compared to itself (more control of coding style, languages and frameworks used, etc.) during different versions/releases without the concern of those writing the code who may attempt to influence the numbers one way or the other.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.