Encouraging developers help testers
Hi,
My team has 3QAs who are doing manual GUI testing and 5 developers. The situation is QAs are always busy and cannot handle all the testing that comes from developers.
Whereas developers normally can finish their part before the end of sprint and go pull in tasks from backlog.
I believe it would be good if developers help QAs instead, it's the more like Scrum, team-based approach. But developers are not happy with this idea as they have attitude like "I came here to code on C++\Java. If I wanted to do testing I would be QA. What next do you want us to do, maybe cleaning as well? This Scrum is ridiculous."
What could I do to change the situation?
Although there are many reasons to include manual testing in the development process, it shouldn't be the bottleneck that you describe (even though this is a very common situation).
The mindset of developers needs to change. Their role is not to just write code, but solve problems and produce a high quality product. That means also helping to test the product to ensure that it is of sufficient quality. However, since they are developers, their skills may be more closely aligned with automated testing rather than manual testing. Are your developers writing automated unit, integration, system, and acceptance tests? Have they integrated these automated tests into a build pipeline so they can get rapid feedback on their changes? Writing good tests that find issues early in the development process can shorten the feedback loops.
If you don't have automated tests now, you can start adding them. At the highest levels, the manual test cases that the testers run may be good candidates for initial automation. The QA team can help the developers to prioritize what tests to automate - maybe they know of tests that are painful to set up and execute or maybe they know tests that have found regressions in the past. This can foster a spirit of collaboration between the developers and the testers.
Rather than pulling new items from the backlog, the developers should be making sure that new work has automated tests and work to fill in any gaps related to old work. Developing these tests may reveal issues, either functional or technical debt, in the product that may be worth solving in the Sprint, rather than starting new work.
However, if manual testing is necessary to get work to Done within a Sprint, a developer needs to understand that the team takes on the work and the team finishes it. Although the preference is to use the strengths of every individual, that may not always be possible and a developer may need to contribute to manual testing in order to make sure that work is done and that the Increment is fully integrated and potentially releasable.
If the automated testing done by developers goes well and there's an overall mindset change to improve quality, the manual testing should be much easier. In an ideal state, the manual testers would be focusing early on testability and interesting test cases (ideally that would be automated during the development process, to the extend possible) and late on exploratory testing or situations that may be difficult to effectively automate.
My team has 3QAs who are doing manual GUI testing and 5 developers. The situation is QAs are always busy and cannot handle all the testing that comes from developers.
As professionals, what are the team doing to ensure that these tests will soon be automated with coverage to a “Done” standard and with regression packs in place?
I know of a similar situation where the testers were told to grow their skillset by learning to do some basic coding (HTML and Javascript) and help the developers with repetitive, maintenance or cosmetic tasks. On the other hand, the developers were asked to help the testers out as needed.
Weekly lunch and learn sessions were scheduled to have the developers/testers learn from each other. During the week, some time was set aside for pair-programming for developer/tester pairs.
The team didn't self-organize which is why management had to make the decision for them.
Management came to the conclusion that going forward, only 360 degree candidates (those can can code, test and write stories) would be hired. And those who were resistant would be coached by their line managers to their new responsibilities. A few developers quit, the rest adapted and with new 360 degree candidates, the development culture changed for the better.
At the end of the day, what was best (long-term) for the business and for the customer took precedence.
Eager to know on how we can encourage developers on QA testing.
I agree that this is a mindset and that it would take some time but I would like to know on how you start encouraging them or at least get to try the efforts to do testing.
I had a different perspective in discussing this issue on our teams and they responded differently. I think not only the developer mindset, but also QA's mindset to reach out on how their devs can begin on doing qa testing.