| || |
How to convince managers to put more resources into QA, when QA is not the bottleneck
In my large organization, QA is not the bottleneck to getting the release out, meaning we find bugs faster than the developers can fix them. Still, I feel that we are not testing nearly as thoroughly as we should, given the limited resources (people) that upper management will give us. I'm speaking mainly of manual testing her. How could we make the case, or even demonstrate to management, that more resources would help the company get the product out on schedule?
Sounds more like a process problem to me. Where you need more testing done earlier in the process. Are the developers doing any unit testing? Do you have any automated acceptance tests for a build?
I would say, try to approach it from the angle of QA being a part of developer/product manager productivity.
If there were more QA that were highly trained and very skillful, and QA were given better tools.. imagine the possibilities.
1) QA can off load some of the debugging. Instead of filing bugs saying, "such and such is broken". QA will have the time to put some thoughtful analysis behind it. "Such and such is broken, it impacts A, B, C and is a risk because it affects the customer in Z ways. I was able to do a trace log and found exceptions being thrown when I was 2 pages before the bug symptoms showed up." Imagine that. As a developer, I'd be super happy to see all that info right in front of me and can narrow down the problem module quickly before even having to reproduce the problem. As a project manager instead of seeing vague bugs, I have everything in front of me to prioritize and communicate accurately to the stake holders what is exactly going on.
2) I like the idea of always trying to sell automation as part of development. The idea of CI and Continuous delivery is just awesome. Imagine if you freed up the time to invest in your automated suites to where deployments straight from check in is feasible? Imagine now worrying about when your updates and worry about disruption because your process is just so awesome?
3) If QA is fully tasked and development is the bottleneck.. Is there something that developers are doing that can be reduced through better quality. For example, catching flaws earlier can save developers many weeks in that they can build on top of good code instead of bad code, that has flawed assumptions and creates a lot of re-factoring. Does it look like developers are doing lots of activities that are not contributing directly into new features? What if say a load test if done by QA early on during the feature's infancy would of saved developers 3 months in dev time on a future scale-ability project?
Last edited by dlai; 10-06-2014 at 01:01 PM.
Pretty much what David says, except I disagree with his second point - until your builds are stable, automation will simply reaffirm that the build has defects. Unless he means the QA team working closely with dev pre-release and creating automated build tests, in which case I agree :-)
The problem that you have is that QA is finding defects faster than dev can fix them. Management's first thought will be that more testers = more defects = shipping even later. You're only going to sell the "more QA" by positioning them as SDETs and not testers. David's first suggestion is excellent, but I would wonder why your testers are not already doing this. As a manager, why do I need to pay for more people to file awesome bug reports when I can simply direct the ones I have to upskill and do this anyway.
If I can ask a simple question, If you're already finding more bugs than the developers can handle, why do you think you need more testers? Maybe, in the management's eyes, you're already testing thoroughly enough given the quadrangle of cost vs quality vs budget vs risk.