The software is bursting with functions, options, settings, evaluations and analyses - crammed onto one screen to save space. A kind of control center for what it is supposed to do according to the description - and even more. Plus an inconsistent operating concept. Constant updates with new functionalities that were requested by one customer - and now have to be endured by everyone. Installation and maintenance can only be carried out by the manufacturer anyway. The manufacturer is happy about the maintenance contract and the additional income from training - because the software cannot be used without a week of user training. The problem that the software was supposed to solve or the process that it was supposed to optimize has become a minor matter.
Doesn’t exist? Yes - unfortunately far too often. And we testers are just as much to blame as the others in the development process. Even more so! The tester is the person who has to point out such shortcomings. The job of a professional tester cannot just be to check requirements and rules for compliance. A machine can do that too at some point. The professional tester is the “user’s advocate”. The focus must always remain on the benefits for the user. And this involves more than a set of functional requirements, e.g. usability, which is usually neglected and is at best found as a declaration of intent and empty phrase in the specifications. And it doesn’t even have to be an overpowering usability test. One day together is enough: Prototype, customer, tester and a notepad to take notes. This kind of collaboration also helps with another omission: understanding the problems and backgrounds of the users. The tester must not even ask himself the question of purpose during the test and in the application. They need to know what they are actually testing for, where the software is used and which business process it is supposed to support.
All of this is hard work for the tester. In addition to creativity and developing an instinct for customer needs, they also need a great deal of resistance to frustration. Pointing out major shortcomings and establishing “foresight” in the test will be met with blockades: “We don’t need it”, “We’ve always done it this way”, “Take care of the test coverage, the sales department already knows what the customer wants”, “What that costs again!”. It’s like when testing was introduced as a profession in its own right. Here, too, persistence ultimately worked and increased quality is the result.
But unexpected support is now appearing on the horizon: The customer is becoming demanding! The current generation of web applications and mobile apps are often limited to the essentials and the solution to a problem. The user interfaces are simple and clearly structured and can be operated intuitively without training. All the complexity disappears into the background. Installation and maintenance run almost automatically. And in addition to the “user experience”, it is simply fun to use apps - something that often cannot be said of classic business software. Of course, the complexity cannot be compared, but users are getting used to the experience, operation and focused use of apps - and are increasingly demanding this from “classic” programs. It’s not about turning traditional software into apps. That can only fail - you take all the problems with you into a new technology and also have to make compromises. Instead, the “spirit” of apps must be incorporated into traditional software development: software must focus on addressing the needs of users, support them in their tasks and be intuitive to use. This sentence can easily be written into your development guidelines. It is the implementation that is difficult and requires a lot of work. As a tester, however, you have a powerful lever to incorporate this spirit into your own software. Everyone can decide for themselves: Step over the edge piece by piece - or simply continue to test 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.
