The software is bursting with functions, possibilities, settings, evaluations, analyses - crammed "space-savingly" onto one screen page. A kind of control center for what it is supposed to do according to the description - and even more. In addition, an inconsistent operating concept. Again and again updates with new functionalities, which were requested by one customer - and now have to be endured by all. Installation and maintenance is only possible by the manufacturer anyway. The manufacturer is happy about the maintenance contract and the additional income from training courses - because the software cannot be used without a one-week training course for the users. The problem that the software was supposed to solve or the process that was supposed to be optimized with it has become a minor matter.
There's no such thing? Yes there is - unfortunately far too often. And we testers are just as much to blame as the others in the development process. Even more! The tester is the authority that has to point out exactly such deficiencies. The task of a professional tester cannot be to only check requirements and rules for compliance. An automaton can do that at some point. The professional tester is the "user's advocate". The benefit for the user must always remain in focus. And this requires more than a set of functional requirements. For example, usability, which is usually treated stepmotherly, can at best be found as declarations of intent and empty phrases in the specifications. And it doesn't even have to be an overpowering usability test for that. One day together is enough: Prototype, client, tester, and a notepad to take notes. Such collaboration also helps with another oversight: understanding the user's problems and background. The tester must not even ask himself the question of meaning in the test and in the application. He must know what he is actually testing for, where the software is used, which business process it is supposed to support.
All this is hard work for the tester. In addition to creativity and the development of a sense for customer needs, he needs a great deal of frustration resistance. Pointing out major deficiencies and establishing "foresight" in the test will meet with blockades: "We don't need it", "We've always done it this way", "Take care of the test coverage, sales already knows what the customer wants", "What that costs again!". It's like the introduction of testing as a profession in its own right. Here, too, perseverance finally worked and increased quality is the result.
But unexpected backing is now appearing on the horizon: The customer is getting demanding! The current generation of web apps and mobile apps are often limited to the essentials and the solution to a problem. User interfaces are simple and clearly structured and operation is intuitive without training. All complexity disappears into the background. Installation and maintenance are almost automatic. And besides the "user experience", it is simply fun to use apps - which often cannot be said of classic business software. Of course, the complexity cannot be compared, but the user is just getting used to the experience, operation and focused use of apps - and is demanding this more and more from "classic" programs. This is not about turning legacy software into apps. That can only fail - you take all the problems with you into a new technology and have to compromise on top of that. Instead, the "spirit" of apps must be incorporated into traditional software development: software must focus on the needs of users, support them in their tasks, and be intuitive to use. You can easily write this sentence into your development guidelines. Only the implementation is difficult and a lot of work. As a tester, however, you are sitting at a powerful lever to let this spirit also flow into your own software. Everyone gets to decide for themselves: Piece by piece over the edge of the plate - or just keep testing against the requirements.