Software Quality without Testing - Part 3

In Part-1 of this three-part series, we learned about the importance of a quality mindset or better said, a quality-first mindset. Also, we looked into our building block to create long-lasting software quality and defined that each individual has the responsibility to form their own, as well as others’ mindset.

In Part-2 we delved deeper into the associated roles and responsibilities of each individual. We based this on the premise that software quality needs people who can communicate, take, and give feedback with a quality mindset without taking criticism personally.

Today, in the final part of the series, we will discuss the technical implementation of quality.

Implementation of a ‘quality first’ approach

How do we secure quality before we even start testing our code? The following aspects can help us achieve this:

1.   Environment

Modern software is complex. A developer develops code on a local machine; however, it is not efficient to integrate, build and deploy everything on a local machine. Therefore, we need an overall understanding about CI/CD (not necessary DevOps) about staging and containerization. Tools are a double-edged sword; if you learn them, they could make you more efficient, push your software’s quality to the next level and help you maintain the same. Conversely, if you use these tools with little or no knowledge, they will unnecessarily add a complexity to your system.

2.   Containerization

Not too long ago, a mediocre developer would answer QA in all seriousness that a bug is not there because "it works on my machine". Using tools like Docker to containerize the software ensures that everybody uses the exact same environment. The developer develops the software locally and runs it in a predefined container. The build job creates the exact same container, but with the new code base. Now the QA has the same code base as the developer (within the same container). Sounds perfect, but it will help only if people are willing to learn to use these tools. People tend to be lazy, so the excuse "it works on my machine" evolved into "it works in my container".

3.   Source Code Management

Since we work in teams, we need tools to collaborate with each other. Source Code Management tools like SVN, Mercurial or Git are some of the most popular tools by developers. The features in these tools, especially in Git, are huge. Also, for a successful collaboration, the team should implement a strategy to manage the source code. There are a couple of good best practice branching models (for example, trunk-based development and Git flow). The development team, while ensuring software quality, should discuss and decide together about the best approach for their workflow and incorporate the same in their process.

4.   Stage identification

Setting up an environment means that you have to display different stages of the software lifecycle. Stages will help the team to determine the state in which the software is, at any given time.

• Development stage

  This stage should be the playground for a developer. After integrating with the developer’s local system, the development stage should be used for the first trial of the new implemented feature. It does not make sense to perform UI testing or integration testing in this stage due to all kinds of non-stable features and configuration deployed.

• Test stage

  As the name suggests, this is the stage where a stable and testable software will be deployed. This stage has similarities to the productive system, but not on a full scale. Automated testing like system integration, UI, performance, and load testing will be executed on this stage. This stage can also be used for manual, explorative, regression and security testing.

• Pre-production stage

  In a perfect world, the pre-production stage is a clone from the production stage. New features are deployed here after they pass all the tests and are ready for production. Business units can now go ahead with acceptance testing and give the final nod to release the feature.

• Production stage

  In this stage, the code becomes the product, which hopefully, makes a lot of end users happy. Archiving this requires a multitude of monitoring systems to further determine the health of the environment as well as the product.

5.   Code Quality

Although we have many tools to ensure code quality, we need to consider other factors as well.

• Coding Guidelines

  Coding guidelines are mandatory; developers cannot write code the way they want to. Not adhering to guidelines makes the code unsearchable and unreadable, and adds complexity during maintenance or refactoring. It’s the common language we developer have and need to understand. Therefore, each coding language has a predefined set of coding guidelines culminating into software quality (which are also integrated into their respective linters as well as in static code analysis tools like SonarQube and Fortify).

• Clean Code

  Is your code clean? Are your methods and class as short as possible while still having maximum readability? Are your methods responsible for only one thing?

  Or do you have variables like String a = "" or methods with 400 lines of code where you have absolutely no clue what happens with an input and what the output of the method is?

  Writing code is your craftmanship; do not ever treat this lightly. Just as chefs always keep their knives sharp and clean, developers must stay sharp and clean while writing code.

  The book Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin is a must-read for every developer. Even more importantly, one should first understand and then use the knowledge shared in this book. Get involved in meetups and discussions about clean code practices. Your code should be reviewed and you must take the feedback constructively. A clean code and your mindset around it must constantly evolve. Consider this, as a rule of thumb: if you are looking at a piece of code you wrote six months ago, and you wouldn't change a thing, then you are probably stuck in your personal development, which keeps you from being an awesome developer.

Summary

In conclusion, I think developing software has a lot to offer and it’s not all about code and configuration alone. To generate a good product requires a quality mindset at multiple levels. To say that ‘testing is our quality’ is wrong, and too late to begin with. Each step in the software lifecycle must implement quality assurance in either a methodical or technical manner.