I have heard that when testing stories developed in the current sprint, no issues are raised they are not completed (i.e. definition of done was not fulfilled) and that you should only raise issues when you find another, unrelated issue etc. While it does make sense not to raise issues on something that developers still can work on till the end of the sprint, I fail to find some best practices. Is that a correct approach?
Should defects be raised during sprints or just noted in the stories and assigned to developers?
testing;agile;scrum
It depends on your process. In my world, a defect is something that escapes your quality practices. But its up for you to define exactly what those are.Some processes have a clear separation between the development team and the test / quality team. This is the world that I live in now. The development team is responsible for unit and integration tests and the quality team is responsible for deliverable-level (application and system level) regression and acceptance tests. In this environment, any issue that was not found by the development team in their testing would be recorded as a defect as it escaped the development team's quality activities - code reviews and tests.The agile methods promote a highly integrated cross-functional team. In this environment, the quality activities also also integrated. Different people may be leading different activities, but everyone's involved every step of the way. Because of that, there's not always a clear hand-off from a development team to a quality team. As such, I would consider a defect to be something that makes it through to the end of the iteration and into the release.However, something to consider is communication. In my first example, I may note an issue that I find in testing that is minor, but don't have the necessary path to fix in the development cycle. I may log a defect to communicate that I found an issue and allow it to be dispositioned. The project lead or quality team may say that it's actually a big deal (to the customer or from a product quality perspective) and demand it get fixed in the development cycle, or it may be planned for a later release.In the end, you do need to do the right thing to enable you to understand your product quality and communicate the current state of the development effort to the appropriate stakeholders.