I have recently been moved to a new team. There are a lot of practices that I think are not on terms with the Scrum Guide but for now I want to discuss two strange practices.
- While we developers are working on tasks, the Quality Assurances people start testing them via as many scenarios they can think of; they then add any found issues as Bugs. Any sane person would say that this is wrong. If you think a developer might miss a case or scenario then you can add them in the task's description or create a sub task.
I raised this point with the QAs and the Agile Coach and the reply was that Scrum allows us to change certain things as we learn from experience, so we have introduced this thing. I want to know if this practice is right or wrong. I can't really do anything practical about it except raising the issue in the Retrospective.
- Second question is about testing of completed tasks. A developer completes their tasks, let's say 4 days before the sprint's end. The QA finds a thing missing in implementation. Should it be reported as a Bug or the task should be reassigned to a developer, with a comment or edit in description and moved back to progress?
Right now, in our team, if QA finds a problem with task, they keep the tasks in testing but add a new Bug as sub and assign them to developer.
- If the issue is returned, the developer already knows how to change the color, they will fix the problem, it will be quick.
- If a bug is reported and the bug gets assigned to a different developer, the it will be a waste of time. The new developer will have to see how to better do the task. A missing semicolon might be the reason.
Now my question is: what is the better approach for the above two cases?