QA Veto

QA has an unconditional veto in our workplace. If it does not work, it does not ship. But we work in public safety, so delaying a new feature a week is less of a problem than potentially messing up your criminal record.

I read the Tales from the Trenches archive over the course of a weekend, and one recurring theme there is the non- or misuse or QA. There is not much benefit to doing QA if you are not going to act upon the resulting information. (Bonus points to the companies that fired testers when they found serious problems.) When we incredulously ask, “Did anyone test this?!” the answer is often: “yes, and we reported the problems, and they shipped anyway.” And then they sob.

Reading through Tales from the Trenches, you can decide who has the worse job: testers whose work is ignored or testers who are denied work but must sit in featureless boxes if they want their paychecks (presumably “and no goofing off on company time”).

: Zubon

7 thoughts on “QA Veto”

  1. Tales from the trenches are such a great read, the range of emotions you experience going through them is incredible and a testament to the terrible conditions we put our industry workers through. No idea how to fix this though as resources and time are always very finite and I don’t know whether people would take a price hike on games if the did get played more/better hours.

    My recent favourite would have to be the tester whose computer broke and was omitted anything else to do and so spent next to 8 hours a day for weeks staring at a wall. I would have gone cukoo from that

  2. Well, even non-psychotic companies will ship things with bugs. QA is there to find them all, but the way business works for non-life-critical applications is that you get your list of bugs, you figure out how serious they all are, and then you focus on the important ones. Cosmetic issues, rare issues, even common-but-has-a-workaround issues can all be knowingly released. It’s even worse with games, because ship dates are public and the matter of much angst from your customers.

    I guess I’m just saying that there’s a frequent attitude of ‘omg how did you release this with bugs you must suck’, and it’s insanely naive and misguided.

  3. Back in the 1980’s I worked in manufacturing and there was a revolution in companies attitudes towards QA. People realised that quality done right actually saves money rather than costs money because it is much much less costly to stop problems early than to let faulty goods get out the door. Principles such as Just in Time manufacturing and Total Quality Management were initially adopted in Japan but they spread world wide and have pretty much become the norm. People forget (or are perhaps too young to know) that back in the 1970’s and earlier consumer products had much higher failure rates that today.

    Anyway I am surprised that a similar attitude does not seem to have been adopted yet in the software industry. Is this because the software industry is just not mature enough?

    1. I could be that appliances tend to plug into a uniform electric grid, whereas software is run on potentially infinite configurations of hardware and other software.

    2. Possibly the cost difference isn’t the same with software – I’ve heard it’s more economical to let software break and then patch it (and you have the internet as an instantaneous distribution network), rather than test extensively beforehand. I can’t vouch for the validity of that though, not sure where I heard it.

      Failing which, planned obsolescence has its place in gaming too. Release an expansion or a sequel and let the older version be replaced by a newer, better version that the customer will buy as new?

Comments are closed.