Rewards and Frustrations of SQA
Posted on October 8, 2014
By Vladimir Shterenberg
Software quality assurance (SQA) and testing can be as rewarding as it can be frustrating. Every organization has different ideas on what quality means and what level of quality is needed for their products. You would think the highest quality possible would be the universal answer, but when it comes down to making higher profits or getting the product to market sooner or simply spending less – often the decision is to cut down on quality. This is particularly evident in non-life critical applications and in organizations where the profit does not directly depend on the quality of the software product their IT department develops. A good example would be an insurance company developing a new user interface for their brokers. If worst comes to worst brokers can write policies by hand and the company will still be making money.
Giving up quality will likely not come as a direct order to release an inferior product, but rather in the form of resource allocation shifting away from the quality assurance department. There will be less training, less budget for tools and not nearly enough staff. It is also typical to set QA personnel compensations too low which doesn’t help hiring and retaining of good professionals.
As the quality champion you will be preparing business cases to win over the executives and change this status quo. They will nod in agreement that the team needs more time, better equipment, training and cooperation, but after looking at the price tag – the only thing you can rely on getting – is promises and more promises. Your pitch about the astronomical cost of fixing defects after the software is out, damaged company reputation and exodus of unhappy customers will likely to be ignored by the brave risk takers.
This approach has put companies out of business and yet it is often used across many industries on all continents. To be fair, there are situations when this approach is perfectly justified. Low risk, or internal projects with limited or no risk of damage may get away with little or virtually no quality assurance. This works especially well for products with easy and quick deployment such as web sites. Many companies rely on the customers to find and report defects or use automated reporting. Then they quickly address the most important issues and deploy a fix.
Unfortunately this approach is overused. How many times have you been frustrated with commercial software that did not work as expected, caused loss of time, money or impeded your progress? I am sure the answer will be – too many times. The problem will likely increase with the constantly growing number of products and processes controlled by software.
Recently I had a discussion with an executive at a local software company who told me that for their development team of nearly 40 developers they only had 3 software testers and considered increasing this number by two to a total of only five SQA staff. Despite the ongoing discussion within software community about what is a good developer to tester ratio, this number of almost 8:1 is by all means way too high, especially if there isn’t heavy automated testing in place. Additionally, their defect management and other SQA processes needed improvement. I was little surprised that the companies development manager complained that the latest release did not go particularly well. As a quality assurance professional it would be difficult to work for an organization with this kind of attitude towards quality.
When I started working in the medical device industry, I noticed a big difference in the attitude toward quality and the quality assurance trade. Management are more likely listen to your concerns and try to help you out. Your improvement suggestions will be taken seriously and staffing will be more reasonable. You will feel empowered even though it is hard to be “the Protector of the Realm”.
This attitude is natural for any industry dealing with safety and can be found in most companies developing products for healthcare, transportation, and other safety critical applications. But concern for safety is not the only thing driving this attitude. These industries are often strictly regulated. Government guidelines exist and companies are being audited on following the standards set by a regulator.
In the medical device industry the US Food and Drug Administration (FDA) is the main regulator when it comes to products sold on the US market. Other countries have similar agencies overseeing health products locally.
When I first read the “General Principles of Software Validation; Final Guidance for Industry and FDA Staff” released by FDA back in 2002, I thought: “Wow, this is really good stuff! Most of it totally applies to any company that respects users of their product.” This is a document every QA professional should read and have it handy.
It should be noted that FDA documents are only guidelines. It requires significant effort to develop detailed procedures and supporting documentation specific to your organization and product. Consistently following your own procedures requires even more effort and discipline.
In my opinion, quality is the last thing you want to save on. If your product is regulated, dealing with human safety or mission critical functionality – compromising quality is not an option. Regardless of criticality, any organization will benefit from improving the quality of their products by using robust designs, preventing and catching defects and fixing them prior to release.
The truth is that implementing quality is expensive and challenging. It takes hard work, determination, and creativity. However, with dedication to quality you will see the fruit of your hard work. When the product is released and makes a difference in the lives of those using it you will know that it was all worth it.
From the career perspective this is all matter of personal preference – a relaxed environment where not a lot of what you do can have an impact of any kind or higher stress work in a life critical domain.
Will you be ok feeling insignificant or have ambition and want to be taken seriously?
Blog | Engineering | Regulatory | Software