What is Quality Assurance?

Wikipedia defines quality assurance as follows: Quality assurance (QA) is a way of preventing mistakes or defects in manufactured products and avoiding problems when delivering solutions or services to customers.

[..] Quality assurance comprises administrative and procedural activities implemented in a quality system so that requirements and goals for a product, service or activity will be fulfilled.¹

What is Whole Chain Quality Assurance?

In software development there are four phases where quality control can be exercised — but in different ways, and with different targets.

1. Before coding: selecting the best programmers for the task.
2. During coding: selecting the best methodologies, giving programmers the best tools, and defining programmers' area of operation.
3. Code integration: performing analysis and tests on the code.
4. Deployment: acting on user and technical feedback.

Whole Chain Quality Assurance is a look into the weak points of software delivery. These "weak points" are like hinges where the development can go either way in a sharp contrast. If they are not observed, or even recognized, pure luck dominates the outcome of software development.

1st Quality Control Point: Before Coding

This, the first quality control point, is so obvious and yet often overlooked. Everybody always agrees that "great developers make great code"! This is taken as granted. And for almost all practical needs it is indeed true.

Starting a new development or continuing old development with less than great developers is a recipe for disaster. Equally important are two things that need to be said aloud: 1) not every great developer is great in the task he is put to, and 2) not every great developer is great in the team he is put to.

Hiring principles go beyond the scope of this article, so I will not talk any more of this quality control point.

2nd Quality Control Point: During Coding

Now, the problem with great developers is that they are sometimes (but definately not even near to always) also great individualists. They work fast, efficiently, produce code that works robustly but can be difficult to read or to maintain, or its structure or interfaces to outside world are not well planned.

And if only great developers suffered from this, but no! Also good developers, mediocre developers and beginning developers do the same thing. It is not their fault. Without guidance a developer is left to his wits — and he works out the best solution he can, which probably isn't what the long term maintainable best solution would be.

Two things determine the quality: borders and tools. Tools are simple. Everyone uses tools to make things.

Tools and Repository, The End of All Software Development

Version controlled repository is the endpoint of every software developer's daily work. So choose well. Pick a version control system that takes the least amount of its users time.

A software developer commits to VCS. This part of the work cannot be anything else but 100% sanctioned by the producer, whether a company or institution. But everything leading up to that point can be released to the discretion of the developer. The operating system, the hardware, the IDE, the place of work, the hours; producer only cares of the produce, so why force one particular model of work. With one exception: the security — if the source code does require additional discretion!

Borders

What is meant by borders are those methods that regulate the daily development work. We do too much coding when developing! Much of our daily coding work could be automated by code generators.

A great deal of code is just "boiler plate" or simple data structures. Developers waste time by creating object hierarchies in code when these should be created with the help of UML tools or similar programs which use GUI to describe systems. These GUIs would then be converted to actual code and more code would be added to fill the blanks.

This principle could be used in

• Database table and inter dependency modelling.
• System class, domain object and data structure design.
• REST interface design.

For the last case (REST interfaces), there exist modelling languages, like RAML and OpenAPI, which help design a structurally intact and consistent interface, down to the input and output data structures, whether they be JSON, YAML, XML or something else.

An added benefit to using modelling languages and tools that convert design into graphics, is that even non-programmers can take part in designing during code reviews. Similarly, documentation should be built into the code, or as close to it as possible. In the same repository definately, so it will be reviewed together with the code.

3rd Quality Control Point: Code Integration

Again, as with Borders, automating is crucial. All code base, or, if not all, then definately the committed files, will have to pass probing before the developer is allowed to create a merge request, the required action for merging (integrating) his code into the code base.

This "probing" should consist of two parts, if not three:

1. Static analysis.
2. Automatic tests, both on the unit level and system level.
3. Usability tests, performed by an actual user (if feasable).

Static program analysis is the analysis of software that is performed without actually executing programs (analysis performed on executing programs is known as dynamic analysis). In most cases the analysis is performed on some version of the source code, and in the other cases, on some form of the object (compiled) code.

Analysis software can look for different kinds of problems, anything from serious security breaches (SQL injection, tainted data, hardcoded secrets, e.g. passwords and keys) and bad programming (memory leaks) to minor readability problems or ineffiencient algorithms. There exists plenty of analysis software, both open source and commercial. Some of it even very expensive. Of course, most software is not so critical; even relying only on open source analysis tools takes the development a long way to the side of caution.

We must also not overlook the educational factor of this analysis. Every correction is a lesson learned and will improve developer quality in future.

One more bit of static analysis needs to be mentioned separately because it can in fact be considered part of automatic testing: the code coverage. A code coverage report shows those parts of the code which are not covered by unit tests.

Automatic testing is equally important because it often reveals the problems in those remote parts of the code base which might not have been tested by the developer, if for nothing else, then because running the whole test suite takes too much time. Too often developers only test the module which they are building, and thus might be oblivious to the accidental changes made to parts interfacing other modules.

Usability tests go beyong the scope of this article. It can be difficult, and often unnecessary, to include manual testing at this phase of the development.

4th Quality Control Point: Deployment

Deployment, the last chance for Quality Assurance! Some companies see this stage as out of their reach — and beyond their responsibility. If customer has accepted the changes in their UAT (User Acceptance Test), then the responsibility has shifted away from the developers.

Instead, deployment should be considered the ultimate chance to get feedback from the real users of the software — and in a real environment.

There are many ways to get feedback, again both automatic and manual. Logs and efficiency meters; checking both the software and the hardware it runs on. Status messages can be collected with the help of monitoring tools like New Relic (commercial) to show things like how much of the system was utilized and how great the load was. They can also monitor the health of the system.

Logs need to be collected and handled with care because they might (and probably will) contain sensitive business data.

If it's a web service, why not put the displayed parts in an open repository, or create some other way (like online feedback form on every page) for users to give you feedback when they encounter a typo, a grammatical error, or a GUI glitch.

Whole Chain Quality Assurance

Whole Chain Quality Assurance is not a methodology. It is an outlook to software development as a process. It encourages releasing the developers to as much freedom as possible, but at the same time encourages to great diligence and responsibility by demanding great quality at every stage.

The stages 2 and 3 are the most visible for developers, but they need to be aware of the stages 1 and 4 as well. It is vital that no developer (coder or otherwise) sees him or herself as merely a meaningless cogwheel in a big system, but rather as a link in the total development chain — which begins before his role and ends after it.

References: