blame is on QA ?
I am working in a small company where developers are not very efficient and management is also poor. They give less time for testing and when there is complaint from customer all blame goes to QA. I want to know is this a common scenario ? It is both developer's and QA's responsibility to give quality product.
Does the company invite QA into the development stage of the products?
Do they give training on the internals of the project
Do they work with you on each stage of the project to let you test the individual components?
Do they provide test hooks to see inside the applications?
I would make up a list of demands of what they should be doing to work with you.
Then when the customer finds an issue and the company complains just fire back with your demands.
Quality is the job of everyone in the organization. QA can never directly cause bad(or good) quality, after all they don't write the code. They merely provide information about the quality of a build. And with limited resources the amount of that information is reduced.
Last edited by NoUse4aName; 04-29-2015 at 06:08 AM.
Everyone who's in an unempowered position hates their management. It's easy to blame them, and in a way it's their fault. But it is what it is, and you need to focus on the actions you can do. And it's easy to not take responsibility, as it's a developers who are writing the bad code right?
Here's an idea. Publish a weekly stat sheet for the entire Engineering organization.
Found Bugs vs Escaped Defects vs Lines of code changed (you can gather the first 2 through your bug tracking, and the 3rd from their source control)
Then make it a game for QA to always keep the Found Bugs higher than the escaped defect. This will shame devs if they're at fault, and shame management if they are not acting on those numbers.
You get the following scenarios..
Higher found defect than escaped bugs - QA is doing it's job, but not given enough time. Shame on management.
Higher escaped bugs than found - QA is not doing their job well, then you have to improve. Shame on QA (Make sure you keep improving this ratio, and also factor in severity)
Higher total bug count per kilo-lines of code (called KLOC in the industry) - Then devs are not efficient, they're wasting hours writing bad code. Shame on Devs. Typical ratio is about 5 bugs per every 1000 lines for an efficient developer. About 50 bugs per every 1000 lines for more Jr developers.
Last edited by dlai; 04-28-2015 at 09:53 PM.
NoUse4aName and dlai,
Both good information and ideas.
Just so long as we understand that time could still play a role in the last two scenarios as well as the first.
Originally Posted by dlai
"The single biggest problem in communication is the illusion that it has taken place."
-George Bernard Shaw, Irish playwright and Nobel Prize winner, 1856-1950
Thanks for sharing..Good info and help many people in finding it.
I am currently in a similar scenario, with more time being allocated to the developers to complete their work. One thing that I have done is to be clear about the amount of time which will be required for testing.
Quality should be instilled by everyone working on the project, but it seems to be as testers/QA are seen as the gate keeper, the blame lies on our heads.
I found what works best is try to get everything systematized. For example, if all your test cases are in a test management system, with approximate estimates. Management can easily see how long testing will take based on the set of affected features and plan accordingly.
QA should be blamed if it signed-off on something it didn't test properly.
If you didn't sign-off, then it's clearly not your fault.
Never say Yes, when you should say No.
If you say No, then back up your answer with science. e.g. Here are the tests we should run before release and here's why they need to be run.
As others have said, be rigorous and systematic(i.e. scientific) in your approach and that will give you confidence to fend off any nonsense that people may throw at you.