Software QA Has Business Value. Treat it Like That.

For many years, the software QA and software development groups were just that, groups. The development engineers were charged with keeping their focus on converting marketing’s product feature lists into working code and integrating that code into working systems that fulfilled the system’s specified functionality.

Software quality was charged with verifying that what the engineers did, created what marketing wanted. They took product design documents and intended user instructions and measured the integrated system code against them to see that what was specified was what happened, without unwanted side effects. Quality was also where the anticipated product user came back into the picture as testing cosmetic interface layout and intuitive control operation were among its duties.

For the duration of the reign of the waterfall development methodology, the absolute separation of quality from engineering was considered sacrosanct. A very common phrase was to ‘throw the code over the wall’ from engineering to quality or back, a subtle but pointed indicator of the desired separation between them. Now, enter Agile/Continuous Integration/Dev/Ops. Now ‘quality is everyone’s job’ replaces ‘throwing it over the wall’ and decades of corporate organizational tradition are expected to change radically.

A major hindrance to this is that quality has always been the red-headed stepchild of software development organizations. Given the recent changes in product development methodology, this situation bears closer examination.

The Software Quality as an Expense Mindset

Ironically, software development started out testing its own product. When systems were necessarily simple because they had to run on very limited capability hardware, programmers tested their own code as they wrote it. This made sense because an entire system would have only a handful of modules and they would all be part of the same body of code. The person who made it, knew how it was supposed to work and had the insight for what it should do.
As computing machinery grew exponentially in power and software grew exponentially in complexity, the testing and verification processes outgrew the scope of the programming staff’s project schedule allocations. In particular, as development moved toward the assembly line with Agile prescribing fast incremental changes that had to be supported by multiple teams of developers, quality began to return to its roots… it became everybody’s job again. Unfortunately, the tribal attitude toward quality didn’t support this.

At the height of the waterfall methodology, when software releases took a year or more, the goal of a creative individual who was interested in software was to create it. There is a truly unfortunate saying that “those who can, do and those who can’t, teach.” This attitude translated into software development as “those who can, program and those who can’t, test.” Software development engineering has traditionally looked down on mere ‘testers.’
This was not helped by the accounting department. Software development costs fall into the investment category on the company’s balance sheet. Quality expenses are just that, expenses, and they are viewed as an unfortunate but, somewhat, necessary cost of doing business. Investments create financial returns, expenses are losses.

The Rise of the Quality Engineer

The requirements of modern software product development demand change. Directly integrating quality with development in small working teams, software test automation and massively complex systems with millions of lines of code and hundreds of modules are all driving toward rebalancing the respect for what quality does. One of the strongest indicators of this is the rise of the term ‘Quality Engineer.’

To support code development from module testing through user acceptance testing requires a ‘tester’ community who understands the system code as well or even better than the developers. These worthies must be able to see how all the modules function, communicate with each other, and interact in order to make sure that the rapid incremental releases don’t begin to suffer from cascading failures. A software quality engineer cannot be less capable than a development engineer.

Software QA Has Business Value

Quality must be in the development trenches making sure that all the code works all the time. This involves a detailed engineering level understanding of the systems and the support of an array of complex quality tools, code analysis and test automation frameworks to name just two. Investments must be made in high-end quality personnel and the tools they need to do their jobs.

All it takes is one escaped product glitch that draws an avalanche of negative user reviews splattered across the Internet to make a huge investment in quality look trivial.

Contact Us