Contrary to popular belief in software development, you cannot test quality in. Rather, achieving quality is akin to growing a healthy tree: its health can only be observed by looking at the tree as a whole. Is the tree supported by a solid trunk, does its roots go deep, does it have healthy branches and leaves? Also, a large part of quality is seemingly invisible just like the amazing water system inside a tree.
Before we continue, we’ll have to take a moment to define what quality in software development is. Can we define it? The dictionary says that quality is “the standard of something as measured against other things of a similar kind; the degree of excellence of something”. This is not directly helpful, because what is the standard? Can you easily measure your product to things of a similar kind? Can you measure quality against a standard? Should you? Let us take a look at a different option.
A popular definition of quality in testing is something entirely different than what the dictionary provides us with. Gerald Weinberg, author of Perfect Software, says: “Quality is value to some person (who matters)”. This definition is open for more than one interpretation and that is precisely the beauty of it. Every person is different and everybody perceives quality as a different thing. When you look at quality as something that should be nurtured, you will do different things as opposed to when you look at quality as something you can engineer (or even worse: assure!).
How do you look at quality in your IT organization? Do you believe it is the responsibility of testers to create good quality software? Do you believe in a more holistic approach? By reading this article, you will get more insight into why a holistic approach is favorable over a narrow approach.
When we go back to the tree metaphor, the nurturing of quality, we can identify a couple of levels where this happens. This is not the limit, of course, but they will give you a starting point for reflection. For each point, you can introspect on how your organization is doing.
At the roots and trunk of the tree is culture. When your (IT) organization is founded on a culture of trust, positivity and ownership, people can thrive. Building software is not a factory process, but more like research and development. We have ideas, that we then build in small increments and in production we see if our ideas fail or succeed to bring value. Of course, some parts of this development process can be like small factories (the test automation feedback loops, for example), but the process as a whole is not a factory. Software development is way more unpredictable than a factory process. Not machines, but people are still at the core. The more your people feel like they are a valuable asset to the company, the more they will be inclined to contribute to the quality of the product you are making.
Another way to invest in the culture of your company is to invest in your people. Make sure that they have time (and money) for education: courses, reading books, learning a new programming language, etc. Some types of important activities cannot happen ‘on the job’, but have to be facilitated. The result of more education and getting time for it is at the least happier people, but probably also new insights and skills that can benefit the quality of your product.
The culture trunk of the tree branches out into ‘people’. The type of people you hire is linked to quality you will achieve. This is a ‘chicken or the egg’ type of challenge, because what comes first: a good culture, or the people creating and building upon that culture? Getting the right people on board is easier when you have a good culture to promote, and vice versa.
If you want to work in an agile way, it is immensely helpful if you attract people with good communication skills, a can-do mentality and who also dare to speak up. This goes for each role, but for specific roles you also would like to have the best of the field, technically speaking. Of course, this is the dream of every company and in IT there’s a lot of competition to get the best people on board. However, don’t forget the people who are already on board. Listen to their needs and concerns. Involve them in your goals, provide them with education opportunities and let them know they are appreciated.
In short: Enable a culture in which everyone is stimulated and (modestly) challenged to get the most out of themselves.
The teams represent the branches and leaves of the tree. The leaves and branches rely on the strong roots and trunk of the tree. In the team, it all comes together: the culture, the type of people that are hired, the technical decisions that are made. This all influences how well the team(s) will perform.
For the teams themselves it can be hard to see the bigger picture, especially if they are part of a large organisation. That’s why the role of management cannot be overlooked. Management is like the invisible water system of the tree: very important, but invisible. That sounds harsh maybe, but the best management should largely be invisible. It’s invisible in the sense that the teams are facilitated very well by management and they don’t even realise it. This facilitation can come in many forms: making sure the teams are informed of business goals, goings-on of other teams and feel that they are being kept in the loop. Good facilitation can also be organising fun outings, organising cross team workshops to strengthen bonds between people and by having conversations with the teams about the progress and impediments.
Even when you view quality in a holistic way, you cannot overlook the importance of technical decisions. There are many decisions to make when it comes to the technical aspect of software development: which programming languages are you using to develop the software, which frameworks, which test tools, which Continuous Integration/Continuous Delivery tools, etc? All these decisions will have an effect on the complete process on more levels than you might think.
Let’s take a look at a few examples. Some companies have a list of tools and frameworks that teams are allowed to use. If teams want to use different tools they’ll have to ask permission, or they’re simply told that they can’t. Although, from a management perspective it might seem reasonable to prescribe a list of allowed tools, it can be pretty frustrating for development teams. What if the tools they are allowed to use cannot fulfill their needs? And besides, in this day and age the tool landscape is changing so quickly that it will also cost you a lot of time and effort to keep the list up to date. Moreover, if we go back the roots (culture), it would be so much better if teams can be trusted to make informed decisions on which tools they use.
What can you do as management to influence the technical choices and decisions of your teams? A couple of options: join their stand-up meetings regularly, ask questions, have conversations, make sure the teams know your vision and goal. Remember: the more the development teams feel involved in what is going on, the more they will feel motivated to help you reach the goal.
Another technical quality aspect that cannot be overlooked is test automation. A good base of tests that run in a short feedback loop will give you more confidence and can serve as a warning sign as well. Stimulate your teams to take this seriously and develop this during the creation of production code. Don’t see test automation as a “return on investment” type of activity, that is not a good reason to do it. Instead, It is one of the aids we use to alert ourselves for a some of the mistakes we make.
And that is also the bottom line: yes, the technical stuff is very important and gets lots of people excited, but in the end it is there to serve us. It is part of a bigger picture.
In the coming years it will be more and more important to look beyond testing as a means to achieve great quality in software products. Everybody needs to be involved to make a great product. Yes, testing is very important aspect, but when only testers care about the quality of the product you’ll have a hard time making something great.
This demands something from the people working in your organisation. No matter what role someone fulfills, be it tester or developer, everyone needs to think beyond their traditional role. Beyond the basic tasks for each role is now a shared task for everybody: connect with the others in the team and outside the team (communicate, work together, share knowledge). That is hard, but when you have an organisation where a lot of people are doing that, great things are bound to happen.
By taking an honest look at your own company, you might get some clues of what is lacking and can be improved in this journey. The way forward is to look at quality with a holistic approach. Improve your culture, improve your technical decisions, and let your teams shine.
Visit our Quality & Test Automation page to get more inspired by this topic.