Software quality is a team objective

When describing software quality, one of my favourite analogies is that of building a new house.

You have your project managers who gather the requirements, lay a foundation for a new structure to be built upon. The development team then go ahead and build the floors, walls, add plumbing and everything else that is needed. And all the while, testers are inspecting the work that is being done, running their tests. And ensuring those newly developed features are in line with what is in the original plan.

While of course, the reason for testers is to give a project a greater chance of success. Developing a product with the idea of a quality result from inception benefits everyone.

Quality is a team objective, and the best place to start planning for it is right at the start.

How developers can help

Developers can really pave the way for quality solutions. Or equally, they can veer off course and rely on the testing team to correct their navigation.

Quality products need quality tools, quality mindsets, and quality practises.

QA and testing teams aren’t the gatekeepers of quality software. There are many elements of software that can be considered as quality attributes which we don’t have control over. From the documentation that is produced, the code that is written, or attributes like maintainability and readability.

Below I have listed a few of the ways in which developers can contribute to the process of developing high-quality software solutions.

It fills the requirements and works

This one probably goes without saying. Like describing the best kind of water is the stuff that is wet.

But building a product based around a set of user requirements. Especially ones that may have been captured badly, or translated with mistakes. Can lead to some notable deviations from the intended purpose.

Software testers should be going through a process of validating the product against the user needs, as well as verifying that the end product meets the specifications (read the differences between the two here).

But in order for the whole development team to take control of software quality. Ensuring that the right product is being built is one of the key things to be aware of. Not that it is just being built in the right way.

It can be tested

The act of adding ids to webpage elements that are consistent throughout development. Will make your testing team so happy and gain you a new best friend.

In the example of a webpage or GUI application in which test automation can be called upon to speed up processes and take away long manual checks. Having a page without IDs to reference, or distinctly named elements to target. Is a bit like when you give someone directions. But you aren’t sure where their destination is either.

But with Agile development methodologies, more and more testing is being done at the API layer.

The reasons for this are numerous, they are faster to run. Allow for quicker feedback on the code you just developed. And are more reliable than testing with Selenium, or another GUI based tool.

If you want to get some hands-on practice with API testing. Checkout Docket, which I developed specifically to provide testers with a tool to practise API testing.

So as a developer. Maybe you could help out the testing team by exposing an API to allow them to run tests against.

It has unit tests

Defects that are identified early on in the development process are those that are less expensive to correct.

Unit testing is one of the first testing activities during code creation that ensure what you are developing, works. It makes testing easy, automated and having a unit test written, is one of the best ways to convince others that your code works.

“If you don’t like unit testing your product, most likely your customers won’t like to test it either.”


It’s easily maintainable

Just because you wrote it. Doesn’t mean that you will always be the one to change it, add new functionality, or remove parts that are no longer needed.

If your code requires complex rewrites to allow for a simple modification to the core logic. Or has parts of the program that only make sense to you. It’s probably not something that you expect others to deal with in your absence.

As Martin Fowler once said:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Martin Fowler

You hopefully have a code review or walk through as part of your development process already. Use this time to ensure others are able to understand the code you have written.

If there are questions. Maybe you could simplify what you have written, making it faster and more efficient. Or create additional documentation for future reference.

At the end of your development project. You may have a house that has been tested and deemed to be a quality product.

There are four walls, a floor, the plumbing works etc. And there are no known defects.

But what is quality? That it fills the user’s needs, is fast, or something else?

If projects are developed with a mindset focused on a quality result from the start. Then quality has a better chance of taking root and influencing the end product.

Attributes like maintainability, code readability, and the others mentioned. Are just one way the developers can help promote the goal of quality.

Posted by Kevin Tuck

Kevin Tuck is an ISTQB qualified software tester with nearly a decade of professional experience. Well versed in creating versatile and effective testing strategies. He offers a variety of collaborative software testing services. From managing your testing strategy, creating valuable automation assets, or serving as an additional resource.

Leave a Reply