As someone who has worked in the area of quality/test engineering for some time, this question has popped up time and again. I have also been involved in several discussions among peers about this question but I have never quite gotten a satisfactory answer, at least not for myself.
Some time back, while reading the book “How Google Tests Software”, I came across the line
Quality != Testing
This really made me balk and ask myself “so what then is Quality, in particular Software Quality?”.
This must come as a surprise to the uninitiated but for those of us in the so called Quality and Test specialization in software engineering, we spend most our time and energy honing the art of testing. Functional testing, performance testing, unit testing etc, how do we test this feature, how do we test that component, how do we “break” the software? Those are the questions and challenges that plague our profession.
So what then is Quality?
I pondered this for a quite a while and then one day it hit me: Quality is and has always been synonymous with the luxury industry.
Take for an example how a Hermes Birkin bag compares to a Coach (now if you’re male, single and straight, you had better learn to distinguish the two fast). One costs a tens to hundreds of thousand dollars and the other a few hundred.
Why is that? A bag is a bag is a bag right? Nope. Each Birkin bag is hand-sewn, buffed, painted, and polished by expert artisans. Note: expert artisans. Artisans who are passionate about their craft.
At the end of the day quality comes down to craftsmanship. We pay for the craftsmanship, not the object.
Software quality, it follows, comes down to software craftsmanship –
1. how systems are designed
2. how systems are built
3. how systems are tested
4. how systems are deployed
Craftsmanship is about pride in the product one is building and it is about knowing and practicing the various aspects of this process.
In “Clean code, A handbook of Agile software craftsmanship”, Robert Martin describes software craftsmanship as both knowledge of the principles, patterns, practices and heuristics that a craftsman knows; augmented with the hard work of applying that knowledge in the daily grind of churning out production ready code. It is hard work and it takes discipline.
Quality hence is everyone’s responsibility. From the design of the UI so that users find it aesthetically pleasing to use, architecting for performance, modularity and testability, deploying in a seamless fashion that minimizes the impact to users, writing code that is efficient yet maintainable; and testing – putting the system through its paces and figuring out what could possibly cause the software to break, or what functionality was missed.
So if quality is everyone’s responsibility, what then is the role of the quality or test engineer?
I would say that it is to encourage software craftsmanship.
This goes beyond testing, although that is the bread and butter of our profession.
Why bother? Wouldn’t it be much easier to just test and report bugs? Yes, but then the true value of finding those bugs is lost. The true value is in asking why those bugs came about in the first place and trying to put in place measures so that it doesn’t surface again. In short – encouraging software craftsmanship.
However, in order to know what good code looks like, you need to have either built code, seen bad code, seen really good code – and mostly all of the above.
Coming back to the Birkin bag analogy: an expert is able to tell a real Birkin bag from a fake. It is down to the fittings, how the leather is prepared, how well the stitching is done. I know intimately about this because I have an uncle who is certified to repair Louis Vuitton products.
In the same way, you can tell if software is designed and built well. But like art, you would have had to have seen/worked with well designed code/systems to know how they look like.
Only when you have seen quality can you build quality.
The Mobile Potpourri 