In dieser Blogserie sprechen wir mit Testexperten aus verschiedenen Branchen. Auf Testersuite hören wir gerne die verschiedenen Ansichten über das Testen und darüber, wie ein Testexperte tickt.
In dieser Ausgabe von Let's Talk About Test sprechen wir mit dem Qualitätsexperten Rik Marselis. Principal Quality Consultant bei Sogeti, ehemaliger Präsident von TestNet und Gewinner des ISTQB® International Software Testing Excellence Award 2022.
" ...Es beginnt letztlich mit der Frage, welches Problem Sie lösen wollen..."
Zunächst die Standardfrage: Wer ist Rik Marselis?
Dann lassen Sie uns mit einer Standardantwort beginnen. Mein Name ist Rik und ich lebe mit meiner Frau in Amstelveen. Mein größtes Hobby ist die Fotografie und außerdem bin ich stolzer Großvater von drei Enkeln.
Ich arbeite bei Sogeti als Principal Quality Consultant. Meine Arbeit besteht aus drei Dingen. Erstens arbeite ich im Namen von Sogeti als Qualitätscoach und Berater für Kunden. Darüber hinaus entwickle ich Schulungskurse und biete Schulungen auf dem Gebiet der Qualitätstechnik und -prüfung an. Ich erstelle auch maßgeschneiderte Schulungskurse nach den Bedürfnissen der Kunden. Schließlich betreibe ich Forschung und Entwicklung auf dem Gebiet der Qualität und des Testens. Ich denke mir nicht so sehr neue Dinge aus, sondern bringe bestehende Dinge zusammen, um etwas völlig Neues zu schaffen. Darüber spreche ich in Büchern, Blogs und Podcasts.
Ich habe inzwischen an 25 Büchern mitgearbeitet, von denen sechs meinen Namen tragen. Mein kleinster Beitrag zu einem Buch besteht darin, ein Foto der Autoren für die Rückseite des Buches zu machen. Das Buch Qualität für DevOps-Teams ist meine jüngste und bisher größte Veröffentlichung.
Wie sind Sie zum Bereich Quality Engineering gekommen?
Das begann 1980, als ich zum Programmierer ausgebildet wurde. Man muss etwas machen, das die Anforderungen erfüllt, und ich habe gelernt, dass ein Programm nicht fertig ist, wenn es keinen Testsatz enthält. Heutzutage passiert das manchmal weniger. Ich treffe auf Entwickler, die denken, sie seien unfehlbar, aber das ist selten der Fall. Glücklicherweise gibt es auch viele Entwickler, die verstehen, dass Qualität wichtig ist und dass Tests notwendig sind.
Software ist heute viel komplexer als früher. Warum halten die Menschen sie dann für unfehlbar?
Heutzutage zerlegen wir die Softwareentwicklung in Teilziele. Das führt dazu, dass die Leute schnell denken: "Meine Arbeit ist fertig, und sie war nicht so schwierig, also muss sie gut sein". Das ist der Punkt, an dem es schief geht. Wenn Fehler gefunden werden, sagen die Leute schnell: "Das ist nicht meine Arbeit". Früher hat ein kleines Team ein ganzes System gebaut, und man konnte das Ganze überblicken. Heute macht man sich zu viele Gedanken und sieht die Komplexität nicht.
Spielt die Wirtschaft dabei auch eine Rolle?
Auch die Wirtschaft stellt oft unrealistische Anforderungen. Wenn ich im Supermarkt eine Tüte Chips kaufe, kann ich heute aus hundert Sorten wählen. Ja, dann weiß ich es auch nicht. Und wenn ich mich für eine Tüte Chips entscheide, ist die Wahrscheinlichkeit groß, dass sie beim nächsten Mal nicht mehr da ist. Die Vermarkter denken, dass die IT alles kann, und so bieten sie den Kunden hundert Sorten anstelle von drei. Das schafft Komplexität und damit Fehler.
Ich war einmal an einem IT-Projekt beteiligt, bei dem die Entwickler sicherstellen mussten, dass alte Versicherungspolicen in eine neue Anwendung aufgenommen werden konnten. Dieses Projekt würde eine Menge Geld kosten. Ich habe mir dann die Frage gestellt: Welches Problem lösen wir eigentlich? Man kann alles Mögliche machen, aber wer wartet auf sie? Am Ende stellte sich heraus, dass eine Handvoll Kunden immer noch eine solche alte Police hatten. Es stellte sich heraus, dass es viel billiger war, diesen Leuten ein großzügiges Angebot zu machen und die alte Police in eine neue umzuwandeln.
Manchmal hört man auch, dass jemand sagt: "Mein 15-jähriger Neffe schafft das an einem Nachmittag". Ja, nur weiß Ihr Neffe nichts über Sicherheit, Netzwerksysteme, Rechtsvorschriften, Qualitätsmerkmale usw. ....
Ich will damit sagen, dass die IT in der Tat viel bewirken kann, aber letztlich geht es um die Frage, welches Problem Sie lösen wollen!
"Ich stelle nur Fragen wie warum, wer und wie."
Was fasziniert Sie so sehr an dem Bereich der Qualitätstechnik?
Das liegt vor allem daran, dass man sich aus der Qualitätsperspektive viel mehr mit allen IT-Aspekten befassen muss als mit anderen. Beim Quality Engineering geht es um Produkt, Prozess und Menschen. Alle drei müssen in Ordnung sein, um das richtige Ergebnis zu erzielen.
Vom Quality Engineering aus ist man in alles involviert. Ein Witz, den ich manchmal mache, ist die Frage, was QA auf Englisch bedeutet. Jeder ruft dann Quality Assurance. Das ist zwar richtig, aber es bedeutet auch "Question Asker". Das ist die wichtigste Eigenschaft von Quality Engineering. Einfach Fragen stellen, wie zum Beispiel warum, wer und wie.
Wenn ich eine quasi dumme Frage stelle und jemand eine gute Antwort hat, weiß ich, dass die Person weiß, wovon sie spricht. Wenn ich eine Frage stelle und jemand beginnt zu hacken, weiß ich, dass jemand nicht weiß, wovon er spricht. Es ist auch eine Frage der Erfahrung, die es einem ermöglicht, die richtigen Antworten von den langweiligen zu unterscheiden. Wenn man älter wird, merkt man, dass man nicht alles wissen muss, um trotzdem einen guten Beitrag zum Ganzen zu leisten.
Was ist das ISTQB überhaupt?
ISTQB steht für International Software Testing Qualifications Board. Das Q steht nicht für Qualität, sondern für eine Qualifikation, die Sie erreicht haben. Das ISTQB zertifiziert also Menschen auf diesem Gebiet. Sie müssen Prüfungen ablegen und dafür Schulungen besuchen.
Sie haben kürzlich den ISTQB International Software Testing Excellence Award 2022 gewonnen. Was ist das für eine Auszeichnung?
Das erste, was ich immer sage, ist, dass ich ihn nicht gewonnen, sondern verliehen bekommen habe. Ich musste nichts Besonderes dafür tun, wie zum Beispiel laufen. Die Auszeichnung wird verliehen, weil man etwas in dem Bereich geleistet hat. Es ist nicht so, dass man denkt, ich tue einfach etwas, um ihn zu gewinnen.
Für das Jahr 2022 wurden acht Personen von den verschiedenen internationalen "Gremien" nominiert. Aufgrund der Bücher, die ich schreibe, meiner Vorträge auf Konferenzen und der Lehrpläne, an denen ich mitwirke, war man der Meinung, dass ich in diesem Jahr mit dem Preis ausgezeichnet werden könnte. Der Preis wurde im Mai angekündigt und wird im Oktober überreicht. Dies wird während der Generalversammlung in Marrakesch geschehen.
Was bedeutet diese Auszeichnung für Sie?
Vor allem ist es eine Anerkennung, auf die man stolz sein kann, und ein Ansporn, weiterzumachen. Ich habe nicht das Gefühl, dass ich etwas Besonderes tue, aber wenn es nicht viele Leute tun, dann ist es trotzdem etwas Besonderes. Dann ist es schön, Anerkennung zu bekommen. Eine Auszeichnung wie diese ermutigt mich, weiterzumachen. Außerdem wächst dadurch auch mein internationales Netzwerk, und das ist auch schön.
"Wussten Sie übrigens, dass der Grundstein für TMAP 1986 vom Repräsentantenhaus gelegt wurde?"
Können Sie ISTQB mit TMAP vergleichen?
Wir haben TMAP einst damit begonnen, praktisches Wissen über das Testen zu erfassen. Sie begannen, dieses Wissen für Schulungen und Zertifizierungen zu nutzen. Beim ISTQB war es genau andersherum, sie haben zuerst die Prüfungsanforderungen definiert und dann angefangen, Schulungen und Literatur dazu zu entwickeln. Sie sind keine Konkurrenten, sondern ergänzen sich gegenseitig, wobei TMAP entscheidender ist, weil weniger Leute über Ergänzungen und Änderungen mitentscheiden. Übrigens, es gibt eine gemeinsame Geschichte. Als das ISTQB gegründet wurde, gab es TMAP bereits seit etwa 10 Jahren. Einer der Autoren des ersten TMAP-Buches ist Erik van Veenendaal. Er war auch ein großer Förderer des ISTQB.
Wussten Sie übrigens, dass der Grundstein für TMAP im Jahr 1986 von der Abgeordnetenkammer gelegt wurde? Damals gab es ein Debakel mit den Steuerbehörden(!) und die Abgeordnetenkammer beschloss daraufhin, dass es ein Handbuch für die Prüfung geben sollte. Daraus entwickelte sich TMAP.
Sind die Niederlande bei den Tests so weit voraus?
Die Niederlande sind definitiv ein Vorreiter, wenn es um das Testen geht. Vor allem in den 90er und 00er Jahren. Ich habe einmal auf einer Veranstaltung in Dänemark gesprochen, wo ich etwas über die Zukunft des Testens sagen sollte. Man riet mir zu erzählen, was wir in den Niederlanden gemacht haben. Das war schließlich die Zukunft für das nicht-niederländische Publikum. Man sieht immer noch viele niederländische Redner auf internationalen Konferenzen. Wenn man bedenkt, wie klein unser Land ist, ist das immer noch etwas Besonderes.
Manchmal stoßen wir auf Organisationen, die dem Testen keine Priorität einräumen. Wie sehen Sie das?
Das erste, was ich immer frage, ist, wie oft Dinge in der Produktion schief gehen. Wenn nichts schief geht, dann ist das gerechtfertigt, weil Sie offensichtlich brillante Entwickler haben. Oft denken die Leute, dass es sich nicht lohnt zu testen. Fehler werden dann vertuscht, beschönigt oder akzeptiert. Wenn kein Geld für eine brillante IT vorhanden ist, dann passieren viele Dinge hölzern und man lebt damit. Man muss abwägen: Welche Qualität braucht man und wie viel Risiko ist man bereit einzugehen? Wir bringen das schon in Ordnung, wenn etwas schief geht, denken die Leute dann.
Es gibt auch Leute, die sich für Standardpakete entscheiden, wie zum Beispiel Salesforce oder SAP. Das sind aber keine Standardpakete, sondern Systeme, mit denen man den Prozess zusammenklicken kann. Das ist auch der Punkt, an dem es oft schief geht. Die Leute nehmen das einfach noch hin, weil sie nicht richtig darüber nachdenken. Das Unternehmen macht keinen Lärm darum und akzeptiert oft einen Workaround, und es gibt niemanden, der das eigentliche Problem löst.
Wenn diese Art von Organisationen im Vorfeld etwas mehr über Qualität nachdenken und Qualität in die Teams einbauen, führt dies zu besseren Ergebnissen der IT-Systeme und der Organisation. Dadurch hält sich der Testaufwand (und vor allem die Arbeit an der Problembehebung!!!) in Grenzen.
Was halten Sie von der Art und Weise, wie Unternehmen derzeit mit Softwaretests umgehen?
Darauf gibt es keine einfache Antwort. Ich sehe zwei Möglichkeiten. Die eine ist, dass Qualität wichtig ist und man den richtigen Ansatz wählt. Das läuft auf die Frage hinaus, wie viel Risiko man bereit ist, einzugehen. Das bestimmt den richtigen Ansatz.
Es gibt auch Organisationen, die Qualität und Risiko als Kosten betrachten. Wenn man sich auf die Kosten konzentriert, sinkt die Qualität. Wenn man sich auf die Qualität konzentriert, sinken die Kosten. Der Nachteil dabei ist, dass die Kosten nur mit der Zeit deutlich sinken. Man verdient sie sich später wieder zurück. Viele Unternehmen fangen zu spät an und schreien: "Testen ist so teuer". Sie meinen damit, dass die Fehlerbehebung teuer ist und nicht das Testen.
Tests zeigen Ihnen, was schief läuft, und das zu beheben kostet Geld. Das Testen selbst ist nicht so teuer. Die Kosten kommen vor dem Nutzen. Das Böhmsche Gesetz läuft parallel dazu. Oft will man zu Beginn eines Projekts Zeit sparen, indem man keine Prüfungen durchführt. Wenn dann im weiteren Verlauf Probleme auftauchen, ist es oft schon zu spät. Die Beseitigung dieser Probleme kostet dann viel Geld.
"Testersuite gibt den Menschen Struktur".
Was halten Sie von einem Testmanagement-Tool wie Testersuite?
Viele Menschen haben ein Interesse an Struktur. Testersuite gibt den Menschen Struktur. Oftmals sind die Menschen nicht in der Lage, selbst eine Struktur zu schaffen. Darin liegt ein großer Vorteil von Testersuite. Außerdem ist Testersuite niedrigschwellig, was dazu beiträgt, dass es akzeptiert und umgesetzt wird.
Welchen Rat geben Sie dem Team von Testersuite ?
Besteht darauf, das Tool nicht zu komplex zu machen. Immer mehr Menschen wollen Dinge hinzufügen, und das muss man eindämmen. Testersuite zeichnet sich dadurch aus, dass es überschaubar ist. Wenn man es zu komplex macht, untergräbt man einen der wichtigsten Erfolgsfaktoren.
Welchen Rat geben Sie dem Testmanager?
Ein guter Testmanager macht sich zunächst Gedanken darüber, wie und was er am Ende berichten soll. Sobald Sie wissen, was die Beteiligten wissen wollen, können Sie Ihre Aktivitäten entsprechend ausrichten. Ein Tipp: Machen Sie nie einen Abschlussbericht, sondern einen Fortschrittsbericht, wobei Ihr letzter Fortschrittsbericht auch Ihr Abschlussbericht ist.
