The software is packed with features, options, settings, reports and analyses, all squeezed onto a single screen “to save space”. A kind of control center for everything the description promises, and then some. On top of that, an inconsistent way of operating it. Update after update with new features that one customer asked for and everyone else now has to live with. Installation and maintenance? Only the vendor can do that anyway. The vendor is happy about the maintenance contract and the extra income from training, because without a week of user training nobody can work with the software. The problem the software was meant to solve, or the process it was meant to improve, has become an afterthought.
Sounds far-fetched? Unfortunately, it happens far too often. And we testers share the blame with everyone else in the development process. Even more so, in fact, because the tester is the one who has to call out exactly these problems. A professional tester’s job cannot be limited to checking whether requirements and rules are met. Sooner or later a machine will do that. The professional tester is the “user’s advocate”, and the benefit to the user must always stay in focus. That takes more than a set of functional requirements. It includes usability, which is usually treated as an afterthought and at best shows up in specifications as a statement of intent or an empty phrase.
A Usability Test Can Take Just One Day
It doesn’t even have to be a full-blown usability test. One day together is enough: a prototype, the customer, a tester and a notepad. Working like this also fixes another gap, namely understanding the users’ problems and context. During testing, a tester should never be left wondering what the application is for. They need to know what they are actually testing for, where the software will be used and which business process it is supposed to support.
Seeing the Bigger Picture Takes Persistence
All of this is hard work for the tester. Besides creativity and a developing feel for what customers need, it takes a high tolerance for frustration. Pointing out bigger problems and bringing a wider view into testing will run into resistance: “We don’t need that.” “We’ve always done it this way.” “Worry about test coverage, sales knows what the customer wants.” “Do you know what that’s going to cost?” It will feel like the days when testing was first established as a profession in its own right. Back then, persistence paid off in the end, and higher quality was the result.
What Testers Can Learn From Apps
But unexpected backup is now appearing on the horizon: customers are getting demanding. Today’s web applications and mobile apps often stick to the essentials and to solving one problem. Their interfaces are simple and clearly structured, and people can use them intuitively without any training. All the complexity stays in the background. Installation and maintenance run almost automatically. And apart from the “user experience”, apps are simply fun to use, which is rarely true of classic business software.
Of course the complexity is not comparable. But users are getting used to the experience, the ease of use and the focused benefit of apps, and they increasingly expect the same from “classic” programs. This is not about turning legacy software into apps. That can only fail: you carry every existing problem into a new technology and have to make compromises on top. What needs to happen instead is that the “spirit” of apps finds its way into traditional software development. Software has to focus on what users need, support them in their tasks and be intuitive to use.
That sentence is easy to write into your development guidelines. The hard part, and the real work, is putting it into practice. As a tester, though, you hold a powerful lever for bringing that spirit into your own software. Everyone can decide for themselves: step outside the box, one piece at a time, or just keep testing against the requirements.
Frequently Asked Questions
Is it enough for testers to simply verify compliance with requirements and rules?
No. At some point, a machine could take over the task of merely checking requirements and rules. The professional tester sees themselves as an advocate for the user: they keep the user’s benefit in focus and point out shortcomings that no requirements document specifies. This also includes usability, which often appears in specifications only as a statement of intent.
How can you recognize business software that has lost sight of its actual purpose?
Typical characteristics include a plethora of functions, settings, and reports crammed onto a single screen to save space, coupled with an inconsistent user interface design. Updates introduce features that a single customer wanted and that everyone else has to put up with. Installation and maintenance can only be performed by the manufacturer, and the software is unusable without a week-long training session.
How can usability be assessed if a large-scale usability test isn’t possible?
A single day together is often enough: a prototype, the client, testers, and a notepad. This minimal effort is no substitute for a full-scale usability test, but it uncovers usability issues while also providing insight into the users’ context and challenges. Both of these are missing when testers work solely with specifications.
Why should a tester understand the business process behind the software?
Because otherwise, they cannot answer the question of purpose that inevitably arises during testing. They must know what they are testing for, where the software is used, and which business process it is intended to support. Without this knowledge, they check rules without being able to assess whether the result actually helps the user.
What resistance can testers expect when they point out fundamental shortcomings?
Resistance from their own environment: “We don’t need that,” “We’ve always done it this way,” “Focus on test coverage, sales already knows what the customer wants,” “Just look at how much this is going to cost again!” In addition to creativity and an instinct for customer needs, testers therefore need to be resilient in the face of frustration. Even establishing testing as a profession in its own right was only achieved through persistence.
Does converting legacy business software into an app solve its problems?
No. Anyone who simply turns legacy software into apps carries all the problems over into the new technology and must also make compromises. Instead, it makes more sense to bring the spirit of apps into traditional development: focusing on addressing user needs, supporting them in their tasks, and ensuring intuitive usability. It’s easy to say, but putting it into practice is the hard part.
Why are user expectations for traditional enterprise software rising?
Because users have grown accustomed to a different experience. In 2013, web applications and mobile apps were often limited to the essentials and solving a specific problem: clear interfaces, operation without training, complexity handled behind the scenes, and installation and maintenance that were virtually automatic. Users increasingly demanded this focused utility from traditional programs as well, even though their complexity is not comparable.
