Learning from Apps as a Tester

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.