Subscribe

Why we test software

Johan Steyn
By Johan Steyn, Senior manager, Nedbank.
Johannesburg, 30 Jan 2018

IT professionals are masters at putting the cart before the horse. They are caught up in a world of tools and technology and frameworks. They are so busy building the house they think their customers want to live in that they forget the eventual inhabitants of the house. They plan for bricks and plumbing and gutters, and they end up building a structure that is not suitable for those who look to the pros to provide a digital roof over their heads.

Managing software quality means when someone picks up their mobile phone and needs to buy something or transfer money or read the news, it works.

This is true especially for software testers and quality engineers, who test software for a reason. But they rarely stop and ask themselves what that reason is. For software testers, it is about delivering projects on time and within budget. It is often about doing enough to stay out of trouble with the project managers, scrum masters and execs they work with.

Quality is everything

IT professionals often speak about the minimal viable product (MVP). But, MVP means that together with the other teams, they have done just enough to devise a somewhat feasible product. They must place themselves in the shoes of those who will use their products. And this is not the responsibility of those line-of-business people conducting user acceptance testing. Quality is everyone's job.

Together with the product owners and the rest of the teams they work with (now called squads and guilds, and whatever other name that can be thought of to bastardise poor Spotify's ideas), IT pros must always think about the end-users of their work. Their customers are not ultimately their internal stakeholders: they are those people who pay the company for its products and services.

Software quality does not mean there is an acceptable number of defects. It does not mean the performance and load testing pass whatever levels are agreed on. It does not mean the regression testing is automated and the test artefacts are re-usable.

Managing software quality means when someone picks up their mobile phone and needs to buy something or transfer money or read the news, it works. Every time. All the time. Fast.

The pensioner who walks to the automated teller machine to draw money for the week's food relies on software testers to have sufficient uptime (they may not know what it's called, they just need to be able to eat tonight).

The single mom who needs a loan to pay for her child's school fees relies on software testers to protect her personal information, and to be ready to service her financial needs fast. Credit scores, customer profiling and on-boarding are not what she is worried about. She needs the cash so Jonny can attend school with a new uniform.

The main thing software testers need to keep in the front of their minds is their customer journeys. Companies must map their customer journeys from end to end. How will prospective or current customers make contact? What channels will they use? Is the workflow from the multiple channels mapped out and is the data collected in a combined fashion?

Do I need to contact Home Loans, Card, Vehicle Finance and the rest of the channels to change my personal information? And what happens to my information - remember, my personal data is mine and organisations need to be able to give an account at any time of how my data has been used and where it is stored.

So, dear quality management colleagues. Think customers. Think customer journeys. They are the reason software testers have jobs. And they are a fickle bunch: the age of brand loyalty and difficulty to move to another service provider is over. Poor quality software and customer journeys will make companies lose clients faster than they may ever be able to realise.

The opinions expressed here are the author's own. It does not necessarily reflect the views of any of the organisations he is currently or has previously been involved with.

Share