Learning from apps as a tester 

 October 1, 2013

The software is bursting with functions, options, 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 can only be done 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 one-week training of 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.

Doesn't happen? 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 must point out precisely such deficiencies. The task of a professional tester cannot be just to 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, e.g. usability, which is usually treated stepmotherly, and which at best can be found as a declaration of intent and a 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. 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 during the test and in the application. He must know what he is actually testing for, where the software will be used, and what 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 applications 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 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 just getting used to the experience, operation and focused use of apps - and are demanding this more and more from "classic" programs. The point is not to turn 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 have a powerful lever to incorporate this spirit into your own software. Everybody may decide for himself: Piece by piece over the edge of the plate - or simply continue to test against the requirements.