I'm SM for an agile team. One of our testers opened a couple of defects on a story (that really wasn't ready to be tested - but that's another issue). Before those defects were resolved, the tester continued to go through the remaining scripts and opened another defect. Didn't go over very well. Here's my question - Is it standard practice to piecemeal defects as you find them, or to test the entire story and THEN hand over the defects? I would think all at once would be better, but I'm not a programmer and I can't find any guidance online for this scenario. Thoughts?
In addition to the other answers, I have a few suggestions based on my experience.
- Communication needs to improve - It seems from the question that the tester did not know the story was ready for testing. That means the tester potentially raised defects for items that may have been completed while they were verifying and documenting the problem. The developers should have ensured the tester knew the story wasn't ready. The tester should have checked with the developers to make sure they weren't actively working on fixing the problem that was found. As Scrum Master, you need to make sure that your team members are communicating with each other and communicating important information.
- Your tester needs to know when a defect should be created - It's important to note that there is no single correct answer to this problem. Each team determines the criteria they use. The criteria I use on whether or not to create a defect are:
- 1. Does the developer know there's a problem? - If the developer knows that something isn't right with the code and is working on it, I don't create a defect because the problem will be fixed in-sprint.
- 2. Is it something the developer is currently working on? - If the problem is directly related to something the developer is currently actively working on, I probably won't create a defect unless the developer tells me they won't be able to fix it in the current sprint.
- 3. How difficult will it be to fix? - If it's something that will be too complex or time-consuming to fix in the current sprint, I'll create a defect for it.
- 4. How critical is it to fix in the current sprint? - If the problem involves other constraints such as breaking key functionality promised for a release, especially if there are contractual requirements to deliver the functionality in a specific time frame, I'll probably create a defect and negotiate with the product owner and scrum master to have that defect moved into the current sprint on an emergency basis, unless the developers are able to fix the problem immediately.
- 5. What does the developer say? - For problems related to functionality that's currently in development, I will typically ask the developer several questions:
- This thing is happening. Is this what should be happening or did I get something wrong? - Sometimes my interpretation of the user story doesn't match the developer's interpretation. Sometimes the requirements have changed and the user story hasn't been updated. And sometimes there really is a problem.
- Do you need me to create a defect? - Sometimes the dev will fix the problem immediately. Sometimes they'll ask me to create a defect. Sometimes they'll tell me it's actually missed functionality and I need to create a successor user story to add the functionality. And sometimes they'll tell me they haven't finished that part yet, although we've mostly got the team communications to a point where that's not a common problem.
- Are there any other parts of the story that I should avoid for now? - If the user story is partially complete, asking the dev what parts of it aren't ready for me helps me to avoid their time as well as mine.
- Everyone needs to remember that nobody can read minds - By this I mean that if nobody thinks to tell the tester that there are parts of the story that aren't ready, of course the tester is going to see the missing pieces as bugs. And if the tester doesn't think to ask the developers if everything is ready for them, of course the developers are going to be unhappy that someone is reporting incomplete work as bugs. A minute or so to ask/answer questions can save several hours of work and frustration.
This situation could have been avoided with a little communication from everyone involved. I'd recommend you use it in your next retrospective and let your team work out how to prevent it happening again.
If your story is ready for testing then you should raise the defect as soon as you find it. This will
- let you take the most relevant environment state into account
- let you use the single tool to track the defect (not to store somewhere the defect description that you have found but you have to wait unless the entire story has been tested)
Entering issues as you find them is pretty normal. It does require that you have a sane way of triaging defects and figuring out what's going to be worked on.
It does sound like you've got two other issues that need addressing:
- Figure out how to make sure that what's being tested is valid/complete/etc. I know most places I work, you include the version you tested against when you write up a defect, so if the report is entered against a version that's known to be incomplete, then the tickets often go back to the tester to reproduce against the new version.
- Developers taking it personally that there were defects - it sounds like there was a miscommunication about what was available for testing, but even in that case, the tester is doing what they're supposed to do - they're verifying the functionality the best they can.