A few days ago I was asked to present some basics about software quality assurance to a group of employees at Agilio. Above all the methodologies and fancy techniques that come with quality assurance, I wanted to give them a sense of what the mission is. Why should they be bothered with all that?
To understand what software quality really is about, we must look at the bigger picture.

The Context of Business

The universe, like the world, your town, and your personality are infinitely complex entities. All these are instruments that a business has to work with and around to create value for the clients and stakeholders. It’s an understatement to say that the business model is a huge simplification of the intricacies that influence the real world, the stock market, the app market, the supermarket or even your local convenience store.
The so-called business model usually springs from no more than a set of assumptions about how the world (not just the clients) will react to an offer. Over time the model is iteratively refined. Based on trial and error, the assumptions are refined into facts and relatively predictable outcomes.
A mature business has a lot of documentation with precise rules whereas a startup has next to none, seeking to build it from scratch.

The Context of Software Engineering

Given a business model in the form of emails, documents, phone conversations, and napkin sketches, the mighty requirements engineering team get to work. Following close behind are the software architecture rock stars who turn any long list of requirements into UML diagrams. All that is just to translate the already overly simplified business model into something the average programmer can read so that he can write code that translates that into a usable application.

I don’t know about you, but I grew up in the 90’s and listened to cassettes back then. When my friends and I got a hold of a cool tape, we copied it for ourselves, then my other friends copied it from me, then some other kids copied it from them, and by the time three tapes were subsequently recorded from copies, the sound was less than accurate. Sure, it helped if you had an expensive stereo in the same way it helps if your project is developed by a team of professionals instead of noobs, but there are bound to be things lost along the way…

Maturity of Beneficiaries

I couldn’t resist not to point this out. Whenever taking on a software project, it is important to understand your client’s business model and its definition. Like Steve Blank says in his book “The Startup Owner’s Manual: The Step-By-Step Guide for Building a Great Company“, a startup is not a smaller version of a big company! Among organizational and economic implications, this also has a huge impact on the volatility of requirements. Like noted above, a startup is continuously looking to refine its business model. Any new revelation in business will have an echo in the software project. That is not to imply requirements never change for corporate projects, but it’s safe to say that not as often nor as profoundly.

So, depending on who the client is, you might need to embrace change, even within the sprint, or rest assured that everything is implemented once and only once, based on the initial documentation.

What is the Purpose of Software Projects?

All that talk about models and startups and companies is cool, but what about the purpose of our software development projects?
Well, a good software product is above all, useful. If the end product meets most of the business requirements and delivers value to the stakeholders, it’s successful. If however, the difference between what the business needs and what the product does is so big that the stakeholders cannot get any value out of it, that would be a failed project. By the way, the value does not always mean monetary gains. Some projects may be successful even though they will never cover their implementation costs. You can’t put a price on health and safety for example.

George E. P. Box stated: “all models are wrong, but some are useful“. As we’ve seen, models aren’t perfect. The best we can do is make ours useful. As software engineers, we cannot and should not validate the business model itself, as that should be the beneficiary’s concern. If a product fails due to business inadequacies, you as the development team are not to blame. However, you are responsible to minimize the difference between what was asked for and what was implemented.

What Accounts for Model Inaccuracies?

So, if our goal is to maximize software’s accuracy in terms of business model implementation, we must know where inaccuracies hide. The short answer is: everywhere. From the requirements specifications to the lowest level in the code.

Let’s start with requirements and documentation. This is a tricky subject due to the fact that clients usually assume requirements engineers know a lot more about their business and field than they really do, so some important information never reaches the team although it is implied. Failure to document full requirements is the first source of inaccuracy.
Let’s not stray far from this idea, as available documentation will often be misinterpreted. So, requirement misinterpretation is the next source of inaccuracy.

Secondly, let’s look at management. Most project managers use the project management triangle, which is often criticized for not taking into account quality. You see… the scope component implies quality, but quality, performance, and security are non-functional requirements. It’s too easy to overlook non-functional requirements when facing tight schedules and cost constraints. The first aspects to be set aside will, surely, be these ones. They won’t be apparent during the demo, thus the client will not complain about something he is not aware of. Beware of compromising non-functional requirements!

Next, we should be looking at the code itself. We have already talked about scope changes previously so we are aware that software needs to mutate and adapt to new realities the business faces. This introduces a rather strange effect on the system in the form of regression bugs. Things that worked fine yesterday, no longer work today because of a seemingly unrelated change. This happens when the functionality was not tested via automated tests (or test scripts). You might point out that tests were knowingly omitted due to costs and schedule constraints like noted above, but I will only partly reject that because more often than not, the client (or even management) is not aware of this omission. The developers are responsible for implementing tests or publicly logging technical debt when implementing tests is not possible.

Keeping with the code, we could expand the regression bug idea to all bugs. Any bug, regardless of category is, in fact, a model implementation inaccuracy.

Don’t forget: your goal is to implement useful projects!