Does QA suck? Then… what about users?
In 4 reasons it sucks to be in QA, Frank Kelly describes 4 causes that make QA… well, suck.
I initially felt surprised, almost happy: There are people out there that have a QA group on their company!
Leaving jokes aside, I will draw your attention to only a couple of things. Take a read of the full article if you want more.
- QA has responsibility, but not power. They are the ones to say when a product is ready. At least, they should, but I don’t see the average firm announcing a delay just because QA found a few stupid issues.
- QA gets no credit for their work. Basically, they bear bad news. And if they don’t, then the developers have made a really good job and they receive the credit.
So…. if the developers don’t like QA and the managers don’t follow QA advice… what happens? It is the user who finds the bugs in your software.
The solution to this, proposed by Frank, is to
have developers and QA sit side-by-side and work together closely throughout the entirety of the software lifecycle.
QA, after all, are playing the role of your end-users…. just in-house. They are much better than your prospective users at getting back to the developers. They won’t say “This is not working!“, they will explain, provide useful information and be available for contact.Without QA, Frank’s advice turns to “have the developers and users sit side-by-side“. But wait… that is pretty close to Agile methodologies’ evangelism.
I would certainly like that. Break the barrier between product development and product testing. On some cases, you could even break the barrier with the users. Involve them in the development cycle. Betas and prerelease versions might be ok.
Think of this… if QA is not respected by the developers/managers, then the same disrespect will be applied to users. Both QA and users find bugs, don’t they?