Leveraging QA to improve IT Governance

In a nutshell
Quality Assurance (QA) faces a range of organizational challenges that limit its effectiveness. This impacts more than just QA and overall software quality, but erodes IT Governance, putting organizations at heightened risk. By tuning roles and responsibilities, QA can become a critical contributor to effective IT Governance.

The challenges
Left to fend for itself without sufficient active management support, QA faces the following challenges to its effectiveness:

• Involved too late to be effective
  QA is often involved only after software is tossed over the fence from Development. Without early involvement during Requirements, QA is playing catch-up to understand the requirements. Lastly the opportunity for QA to shape Requirements to eliminate ambiguity and ensure testability is squandered.
  
• Late before we start
  Organizations tend to resist date slippage long after the target date no longer is realistic. When Development is late, all too frequently the time allocated to QA is “compressed”, leaving insufficient time for testing.
  
• Overruled by Development
  Development tends to have larger and more influential staff than QA, and is often vocal in their attempts to steamroll QA.
  
• Version confusion
  Weak Software Configuration Management (SCM) can erode confidence in the system being tested. Is it the right version? Can it be rebuilt? Is it going to behave identically in Production?

Approaches to solutions
When in the process QA is involved and how much time QA is granted can be rectified in two general ways; via refined software lifecycle methodology that specifies both when QA gets involved and SLAs on reasonable, consistent and measurable time periods allocated for standard tests.

Empowering QA comes down to Decision Rights as part of IT Governance. It can start by simply granting QA a blanket veto over project deployments. No exceptions. The first time QA is overridden and code deployed is the moment when QA is emasculated, demoralized and ineffective.

The best way to gain confidence that the software deployed is the software tested, and the software can be rebuilt from source code is to revisit SCM. The answer is not another tool, but in changing roles and responsibilities to empower QA to manage SCM. My controversial recommendation is to move the Build process and SCM repository to QA. If QA is able to do the build from source, then there is an independent confirmation that the software can be rebuilt by someone other than one developer and his private machine; do you really want to entrust your project’s source code and build exclusively to a sandal-wearing night-owl clattering on his keyboard and guzzling Jolt Cola who seems a tad too attached to wearing the same clothing daily? It also removes Development one more level away from production deployments. In other words, if QA can do a build and deployment to the QA environment, Development is freed from documenting and supporting Production deployments. There is a cost to this; additional environments, software licenses, training, and documentation. But you will gain additional control and improved governance. It’s your system, manage it….