We tend to think that others are responsible for making everything work as expected or as we would like it to be. There is a collective thought that “normal” is when everything is according to an established order and things just work because somebody else is watching over it all.
Trains arrive at time, airplanes depart at the specified hour and software works just as the team planned because there is someone (or a group of people) working hard to make everything work.
The problem arises when what we think of as “normal” or good is not applied. If software is buggy and does not work as expected or the solution provided to the client does not meet their expectation, the quality team is blamed (and sometimes is actually responsible) for not reporting enough bugs, finding errors, or simply communicating differences about what was really expected.
The idea that the Quality Assurance team can and will stop all bugs because they have sole responsibility in this area is a very common misconception that’s spread across lots of software development teams. Those who follow this type of thought are prone to having more bugs and differences with what the client is hoping for.
Changing the mindset
As the title of this blog suggests, quality is not something that should (or must) depend on a certain group of people within a team. Quality is something we should practice every day and in every aspect of our lives. You wouldn’t expect something that has started out on the wrong foot to have the best possible outcome just because someone is watching over quality, would you? This implies a change in the mindset about how we build WITH quality.
Speaking again about planes, a good quality process should not lay solely on the quality member’s shoulders. If a plane was not built following the most strict standards of security and caution measures, then by the time the verification process begins, the plane may not even fly or worse, it could cause an accident — and that is something none of us would like.
In the software industry, the same happens. We, as a collaborative and interdisciplinary team, should watch over and follow the most strict and practical quality assurance process so that the solutions we provide to our clients are not only what they have expected or even better, but also that they comply with a certain level of robustness, fidelity, integrity, and availability.
Bad coding, bad testing coverage, and testing techniques or poor strategies will produce the following:
- Software that lacks the quality which was requested
- High costs for solving problems
- Frustration
- Several other problems that could even result in losing a business opportunity
How can we improve the quality
To achieve the right level of quality, every team member must commit to applying quality processes to every daily task performed, from documentation to coding and testing. That is how we not only exceed our client’s expectations but also deliver software that differentiates from other solutions our competitors may provide.
When coding, testing, and documentation are performed with agreed quality, the software built will, in most cases, achieve a satisfactory acceptance from the client, providing the right solution for their needs and increasing their confidence about what the company, and especially the team, can provide to them. This could be translated to better relationships with the client, growing opportunities, and even a strategic role in accomplishing their goals.
There are several ways to achieve this level of commitment, but most importantly is to gain enough maturity as a team so every process during the entire development cycle contains directives on how we can assure the quality of the software. To mention a few, there are:
- Coding guidelines agreed upon by the entire team
- Unit testing level of coverage
- Feature documentation
- And most importantly: good communication within the team
Final thoughts
When I say that quality should start at home, it means that we should consciously do everything as if we were the ones benefiting from the process, as if it was built and created for us and as we would like it to be. The idea of what constitutes “quality” is very personal but it’s also subject to a group process that needs to be followed by every team member to make sure that solutions are the best we can create and deliver. When this process is a personal commitment by everyone in the team, planes will fly, trains will arrive on schedule and software will exceed our client’s dreams and expectations.