Can QA test in-progress tasks? How are bugs reported for incomplete stories?

Question

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.

1. 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.

---

2. 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.

My question is: is this approach right? For example, there is a task to change the color of two buttons, one should now be green and other should be red. A developer works on this task, they first understand the task. How they should do this, use CSS or JavaScript (this is just a simple example, so please bear with me)? They change only one button, or forget to change other button, or change both but due to bad coding only one gets changed. Now the developer moves this task to testing, QA tests the task, and finds that only one button is changed. Now should the issue sent back to developer or a Bug should be reported?

• 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?

Answer 1

The Development Team should have all of the skills necessary to turn Backlog Items into increments of working software. For that to be true they need to have the skills to complete all testing on the team, during the Sprint.

Separate QA is pointless if your Development Team creates working software. It sounds like there is a gap on your team where test should be. I would bring this up at the retrospective and try to explore why you have an "Us vs Them" dynamic between the Development Team and QA individuals.

Some guides:

1. Cross-functional team - there should be no sub teams, only a group of individuals, with all the skills necessary, held accountable for creating working software.
2. Backlog Items should be minimal but sufficient - is there is enough information then there are less likely to be surprises. I would expect test cases to be defined as part of the Refinement process. I would also expect a Development Team to be empowered to reject items in Sprint Planning if they are not sufficient.
3. In sprint bugs - problems found inside the sprint should be a conversation between the Development Team members and resolved immediately. If the problem will jepordise the Sprint Goal then a conversation with the PO might be in order.
4. Out of Sprint Bugs - if you find issues in the output of the Sprint then you should create a Bug and track it, then discuss and root cause it at the Sprint Retrospective.
5. externally identified issues - any work identified by a team, group, or individual from outside of the Development Team should have that work ordered and priorities by the Product Owner. Any new work coming into the Sprint is costing the Product Owner money and may not be as valuable to the business as something else.

Questions for your retro:

1. Why is there an us vs them feel between development and test?
2. Why is the QA team raising bugs for in sprint work when a conversation would be better?
3. Why is there a QA team?
4. Is our definition of done sufficient?
5. Why is QA adding work directly to the Sprint?

Answer 2

First there is no right way of testing in Scrum, there is only the way that works for the team. Scrum does not describe any practises when it comes to testing. If you think the way doesn't work discuss it during the retrospective.

To answer your questions from my perspective as an Agile tester:

1. Test in parallel is good, creating bug-reports isn't. As a tester I would create automated tests to cover these newfound requirements so that a developer can implement them. I would discuss the findings with the team and the product owner. Scope changes should go on the backlog. Defects in existing functionality as tasks on the Scrumboard, but I would prefer an automated test.

2. In Scrum you never assign to a developer, since it is a pull system, the team pulls from the still to complete work to fulfill the Sprint goal. Any developer can pick the defects up if they want. I would use a physical board and put a post-it with the issue on the board. Reporting a defect in a defect tracker seems a waste of time as I rather discuss the issue with the team and the product owner first.

3. Prevent QA<->DEV ping-pong, let testers pair-program with the developers and make sure re-work is perfect after the first time. This could be something to try if this happens a lot.

Scrum is a team approach, talk with the team, solve issues with the team. Stop single developer thinking.

Read up on swarming:

• https://softwareengineering.stackexchange.com/questions/147664/what-is-swarming
• https://www.infoq.com/news/2013/02/swarming-agile-teams-deliver