Beware the QA bullies
A few days later, I was sitting in the Lead Programmer’s office when the head QA guy came in. He said, “So, this battle builder thing. It’s random, right?” I said, “Well, it’s not totally random. It’s based on a lot of complex rules, but I do use a lot of random numbers in the calculations so that, yeah, it’s never the same twice.” The QA guy said, “Yeah. That’s the problem. We can’t test that.” There was a long pause as I blinked at the QA guy, and the lead programmer put his head on his desk. I frowned at the QA guy, “Wait, what do you mean?” “Well, there’s no way for us to recreate a bug if we find one. I mean, if we determine that a bug exists, we can’t do the same thing again to make it happen, and prove that the bug exists.” The lead’s shoulders were shaking, though with laughter or sobs, I couldn’t be sure. He raised his head and said, “Brand, he’s right. QA won’t sign off on the game as is. We need to take the Battle Builder out.”
Before you protest that the post is about game programming, allow me to set some context. I think you'll understand both what this has to do with government and why I wanted to scream. Gunship was a simulation/game of the Apache helicopter that was created by Microprose circa 1986. Two subsequent releases were done between 1986 and 1999.
The blog's author does not state which version he was working on, but in any of the versions, the battlebuilder he created was groundbreaking for the genre at the time. Having played those games, I would have loved the feature he created. It would have added tremendously to the game's fun and replayability and surely would have resulted in even better reviews and sales. That's my first scream.
The reason for my second scream was the fact that Quality Assurance (QA) was allowed to nix such a major feature (with a pretty lame excuse) and that the lead programmer allowed it to happen. These two things get my gander up pretty quickly as I have worked with large government organizations that have their QA departments wield considerably too much power – costing the organizations time and money in the realm of application development.
Whenever I see a QA department that has an adversarial relationship with development, one that derives some sort of sick pleasure in kicking work back or halting production, I know I am looking at a unit whose management has lost sight of the purpose of QA.
The purpose of a quality assurance system is to ensure that all products developed/manufactured and supplied meet the organization's specifications in full. In the world of software development it means a unit who is working to make sure that any application developed meets the organization's application standards and that the subsequent code is as error free as possible.
Additionally, QA should work to help the software development team to identify problems as early as possible in the development process. (See ISO 9126 for a full listing of software quality standards.) It is no secret that catching problems earlier in the process is much more cost effective than catching them late in production.
What QA is not supposed to be about is hindrance and suppression of innovation and creativeness. QA is not about design nor are they the design experts. While they can offer valuable feedback regarding functionality and ease of use, that is not their primary role nor should they have the power to "fail" a product because they don't "like" a particular feature. You laugh, yet I have had software fail QA because the head of QA did not like the screen design; yet the customer not only approved the design, they suggested it.It's grossly negligent for management to allow such situations to occur. Software development by its nature is a process that starts behind schedule and over budget. Most software development is in response to a need – one that is usually causing the organization some level of pain. Therefore, the desire for the software solution is high and the time for it to be delivered was "yesterday." Regardless of how much money is budgeted for the project, it always seems "too much" to the client and not enough for the developer. If QA has so much power as to add considerable delay and expense to a project for subjective reasons, that is not only bad management but poor customer service.
In the blog that inspired me to write this piece, the QA department's response should have been, "We haven't encountered something like this. Help us devise some tests that we can use to make sure this piece is operating as intended." Similarly, the lead programmer should have had the backbone to say, "This is an important feature that clearly adds value to our product. Let's work together to find a way to test it."
Please don't mistake my ranting as a knock on QA. It is extremely important and, if applied correctly, is a critical part of the software development process. However, like anything else, if not performed and managed properly, it can prove detrimental to the organization. Have you examined the role of QA in your software development process lately? What kind of relationship does QA have with your application developers? Are you aware of how much time and effort you might be losing due to the relationship? Now might be the time to check things out.