Interview with Wolfgang Platz 

What challenges do you think software testing will face in the future?

The hunger for software

From my point of view, it is as follows. The dominant factor is the hunger for software, and it is massive. There are forecasts from IDC that say that 40 percent of all code will be written in the next year alone. So you can see how extreme this hunger for software is. In comparison, the increase in additional resources in software development from universities worldwide is about 20 percent. Per Ano, we're at 35 or 40 percent more software we want, but there's only 25 percent more developers. That begs the question, how is this going to work? There is a prediction from Microsoft that the future of software development will be less true development and more and more parameterization and configuration at an abstract level and the phenomenon of the citizen developer will occur. If you look at Google today, you also see no-code and low-code development and massive growth, which leads to immense additional momentum. What's interesting is what's being done in that low no-code. Today, the applications developed there are very simple. The moment you want to have a real system, you can't avoid development. With the real systems, we see that the enterprise applications are all trying to address this huge need for customization by building massive configuration layers that allow no- and low-code development to be put on top of their kernel. Many companies are making great strides in this area and are trying to simplify on a massive scale. They have their own program for this, which is supposed to support low-no-code development on their base platform. Not least because this is the key to offering SaaS, which is a must with the strong individual development. On the one hand, we have the enterprise systems that are trying harder and harder to push the coding threshold up. So you can do more and more with no-code and low-code. In addition, we have the low-no-code platforms that exist now, which are suitable in the capabilities for solving simple things without coding.

Low and no code

From my point of view, two things are going to happen that are mainly related to back-office operations. In the past, this was done with Excel, now this is put together with low and no code and all these are very simple processes. Today, the complexity barrier of these in-house developments is below the test-need. Of course, a tester says that everything has to be tested. But we know that simple things are not tested. However, we will see two things. On the one hand, the complexity will increase and on the other hand, the individual solution approaches will combine. Suddenly there is a complexity that needs testing. At that moment, there are the Citizen-Developers and the Citizen-Testers. At this moment we are dealing with a great need for no-code ornamation that will follow no-code development. A no-code developer will not just do a coding for his car mission. So with a certain time delay, this great momentum of Citizen-Development that we will see in the next years will spill over to the test discipline. Therefore, from a tooling perspective, there will be two worlds. There will still be the coding world that exists today with the various frameworks and people dabbling in Selenium and Appium, for example. Beyond that, there will be a larger more abstracted business definition world where people will do software testing without having to go into the code. That's my view in terms of skills development.

Pendulum movements in software testing

In terms of organization, we will see a pendulum movement. In our customer base, we see a pendulum movement. Ten years ago, everybody wanted to have a TCoE (Test Center of Excellence). For the last five years at the latest, that's gone. With a time lag, people have realized that TCoE is not going to be anything and this large pool of manual testers acting on an order-by-order basis is irrelevant. There were all kinds of problems and the response from many customers was that you had to break up TCoE. Then there was the idea of taking everything into development and a dedicated software test would be unnecessary. But then the question arose as to what the real principle was here. In a large organization, this only works for the first three or five teams. It was then adopted by Agile Development, which had great results. It was scaled and suddenly came the rude awakening as the productivity expectations were nowhere near the productivity gains. How was this possible? When you scale, two things happen. You find out that higher levels of testing are needed after all. It's like integration, system integration, and maybe even user acceptance, which is needed after all. It's not just about an isolated application, it's about an entire system network. The question is who's going to do it. The agile teams all think only to the limit of their agile spectrum, and now that is in no way an accusation, because they are set up that way. So we come to the Hegelian thesis-antithesis-synthesis movement, which sees in the middle that there is something we know as digital or Linked-TCoE. One still puts on a very lean body, which partially prescribes or recommends standards in testing approach, testing methodology as well as automation. However, it has real governance in the presentation of results. However, it is still a central body that works very closely with the teams. That's a recommendation we've made, and it's working well for customers. Even for the higher levels of testing in their own agile-led test teams, it brings together the lower level artifacts and aggregates them so that we have a higher level test. That would be the organizational form that I see. What would be wrong would be the approach of putting everything into the Agile teams, hoping it will be solved there. The fact is, that doesn't work. Developers are Progressive Animals, not Regressive Animals, which is why they don't like to do unit testing. Push forward. Make things new. All this is expressed in interesting numbers. We have done a survey of Swiss banks where you can see that at release one, i.e. new tests, they create code coverage that gradually decreases. The reason for this is that no one does maintenance. So the coverage that you get through unit tests fizzles out over time. This means that you de facto have to do something that seems inefficient, because you catch the tests at a higher integration level. But you have the huge advantage that you no longer have developers doing this. Now you can embed people who see software testing as a task, not an evil. They can maintain and sustain those tests. Microservice architecture helps a lot here because you always have API wrapping around the service. That allows you to set up a business logic test at an API level, which works much better in maintenance. Those contract tests, in our experience, people do. At that level, they're willing to write that and maintain that.

One-Test Definition

Ich habe noch ein drittes Thema, worüber ich mit dir sprechen wollte und das mich persönlich interessiert. Das Thema nennt sich One-Test-Definition. Was meine ich damit? Wir alle unterscheiden zwischen funktionalen und nonfunktionalen Tests. Bei den Nonfunktionalen möchte ich die zwei herausgreifen, die am meisten Effort über die Zeit mit sich bringen, nämlich Performance und Security. Es gibt folgende These. Eine Anwendung existiert oder hat das Recht auf Existenz, weil sie eine bestimmte Funktionalität bietet, die sonst keine Anwendung hat. Das ist so, weil sie irgendein Problem in einer Art löst, wie es keine andere Anwendung tut. Wozu brauche ich es überhaupt, wenn es eine andere gibt, die exakt das macht? Ich postuliere, dass jemand, der ein Business schreibt, keine redundante Funktionalität baut. Warum sollte man das tun? Wenn man es tut, dann nur da man nicht weiß, dass es das woanders schon gibt. Wenn ich allerdings eine neue Funktionalität baue, bedeutet das, dass ich immer wieder neue Testfälle bauen werde, die es so noch nicht gegeben hat, da die Funktionalität auch neu ist. Das bedeutet, dass das funktionale Testfall-Portfolio immer bis zu einem gewissen Grad individuell ist. Wenn du zwei vollkommen gleiche Testfall-Portfolios verwenden könntest, dann waren die Applikationen gleich. Wozu macht man das also? Finding Nummer eins ist, dass funktionale Test-Portfolios immer applikationsspezifisch sind. Ich reite so drauf rum, da nonfunktionale nicht unbedingt applikationsspezifisch sind. Wenn du dir heute Security-Tests ansiehst, dann willst du nicht, dass jemand Security Intrusions oder Angriffe machen kann. Diese Angriffe sind dabei alle hochgradig generisch und du möchtest sie bei keiner Applikation sehen. Es ist egal, ob es ein Web-Check-In oder eine Banking App ist. Du möchtest, dass diese Applikation sicher ist. Das Gro an Sicherheit kann generisch beschrieben werden. Ganz ähnlich verhält es sich mit Performance. Bei Performance wissen wir, dass 1,3 Sekunden die Länge ist. Länger wollen wir nicht auf eine Website warten. Wir wissen, es gibt jetzt eine applikationsspezifische Parametrierung, in welcher Concurrency die Use Cases durchlaufen werden müssen. 10.000 Leute sitzen gleichzeitig auf dem einen und 5.000 gleichzeitig auf dem anderen Use Case. Das ist aber nicht spezifisch für die Funktionalität der Anwendung. Das ist ein Parameter, das nur von der Environment festgesetzt wird, wenn ich 10.000 Mitarbeiter habe. Davon wird aber der Use Case nicht beeinflusst. Was bedeutet das? Wir stellen uns bei diesen Gedanken die Frage, warum wir die funktionale Navigation durch die Anwendung nicht als Basis nehmen können und mit diesen generischen Requirements anreichern können, um daraus einen Security- oder Performance-Test zu entwickeln. Die Schwierigkeit für einen Security-Test ist nicht die Definition der Requirements, sondern durch die Anwendung hindurch zu navigieren und in diesem Zusammenhang zu versuchen, die bösen Intrusions zu machen. Das ist eine Aufgabenstellung, die der funktionale Test schon gelöst hat. Bei der Performance ist die Anforderung auch nicht, den Use Case zu haben, wie ihn der User erlebt hat. Ich möchte nur sicherstellen, dass er 10.000-mal gleichzeitig funktioniert. Ich muss also andere Daten hineingeben und Environment-Daten entsprechend positionieren. Die funktionale Navigation durch die Anwendung ermöglicht aber, dass im Hintergrund die Last erzeugt wird, die wir schon gemacht haben. Warum kann ich also nicht eine funktionale Definition für den nonfunktionalen Bereich wiederverwenden und sie dort anreichern um den generisch Code? Und das nenne ich One-Test-Definition Wir haben das bei Tricentis jetzt verwendet und für den ersten Schritt Performance umgesetzt. Du nimmst das funktionale Test-Portfolio, im Hintergrund den Communication-Track dazu, dann reicherst du das mit verschiedensten Datenkonstellationen an, sodass du 10.000 User gleichzeitig drauf bringst. Der Flow ist aber der von der funktionalen Anwendung. Das Update und die Maintenance funktionieren von der funktionalen Anwendung per Knopfdruck. Initial musst du den funktionalen Fluss noch um die Spezifika dieser Testart, die generisch sind, anreichern. Wenn du das gemacht hast, kann das Update und die Maintenance immer auf Knopfdruck erfolgen. Damit bekommst du etwas Neues und in dem Augenblick, wo dein funktionaler Test auf grün geht, hast du zwei Dinge erreicht. Die Anwendung ist erstens halbwegs stabil, sonst würde sie den Smoke-Test nicht überleben. Zweitens ist das Funktionalitätsskript gewartet. Auf dieser gewarteten Situation kann ich jetzt aufsetzen und schieße das Update hinauf auf den Performance- und Security-Test. Das lasse ich sofort laufen und habe zumindest einen Smoke-Performance- und einen Smoke-Security-Test. Der kann jetzt auch von Leuten gemacht werden, die keine Experten sein brauchen, solange alles grün ist. Wenn es auf rot geht, brauchst du jemanden, der reinschaut. Das geht sowohl auf der Security-, wie auf der Performance-Ebene. Du kannst aber das Gro der Arbeit auf eine andere Ebene heben und eine Kontinuität in der Qualitätssicherung auch aus der nonfunktionalen Perspektive erreichen. Das ist die Idee von One-Test-Definition.

What do you think testers and test managers need to learn and do in 2022 to be ready for upcoming changes?

In the future, you have to understand how DevOps works much more than you do today. As a test manager, you also absolutely have to understand how Docker and Kubernetes basically work. How are these fundamentally deployed? That wasn't necessary in the past. There, tests were rather singular events, which is no longer the case today.

Otherwise, I still see a frightening lack of knowledge among all test managers as far as methodology is concerned. The mistakes of 20 years ago are still being made. The main thing is to automate completely. No one asks what additional coverage is generated by such a test. People still don't understand the importance of the transition from an intuitive testing approach to a methodical testing approach. It is important to know when we do what. When do we need to do a test data design, a test case design? I recommend this basic testing methodology to everyone.