Tech Talks: In der Qualitätssicherung immer eine Nasenlänge voraus

In unserer Blog-Serie «Tech Talks» kommen talentierte Menschen zu Wort, die über ihre Erfahrungen und neueste Trends sprechen, um die Fachwelt zu vernetzen und die gesamte Branche voranzubringen.

Wer kann die Verantwortung für Softwarequalität übernehmen? Was macht gute QS-Ingenieure aus? Wie bringt man sich optimal in die Projekte ein? <p>In der sechsten Folge unserer Tech Talks berichtet Ana Milutinović über die wertvollen Erfahrungen, die sie als Qualitätssicherungsspezialistin bei Zühlke erworben hat.</p>

Was hat sich im Bereich der Qualitätssicherung am stärksten verändert?

In der Softwareentwicklung hat es eine Art Revolution in der Methodik gegeben, mit direktem Einfluss auf unsere Arbeit. Die Qualitätssicherung gehört jetzt zum Entwicklungsteam. Das ist großartig, weil die QS jetzt von Anfang an in das Projekt involviert ist, also auf dem Zeitstrahl früher angesiedelt. Wir nennen das „Shift Left Testing“.

Was die Arbeitsabläufe angeht, so kennen die Tester jetzt auch den Entwicklungsprozess. Das ist sehr wichtig, weil der Testzyklus ja Teil des Entwicklungszyklus ist. Es ist gut, dass das nicht mehr separat gehandhabt wird wie früher, weil es eben doch zusammengehört. Nicht so gut ist allerdings, dass Qualitätssicherung jetzt vielfach mit Automatisierung oder automatisierten Tests gleichgesetzt wird.

Wie stehst du zu automatisierten Tests?

Ich habe fünf Jahre lang an einem Projekt zur Automatisierung mitgearbeitet und dabei sehr viel gelernt: wie man programmiert, wie man die einschlägigen Tools verwendet und wie man Frameworks gestaltet, die einem die Arbeit erleichtern. Von den Test-Skills mal ganz abgesehen, man braucht natürlich QS-Skills, um QS-Tests schreiben zu können. Man muss eine Strategie haben, um zu entscheiden, was automatisiert werden soll und wie – es gibt ja Tausende von Möglichkeiten.

In seinem Buch "Perfect Software and Other Illusions About Testing", sagt Gerald M. Weinberg:

„Vom Verhalten her ist ein nicht funktionierender Rauchmelder die allermeiste Zeit nicht von einem funktionierenden zu unterscheiden. Die Aufforderung zum Erneuern der Batterie kommt leider am häufigsten in Form eines Brandes.“

Das bringt es auf den Punkt – automatisierte Tests müssen sein. Sie gehören meines Erachtens zum Instrumentarium der Qualitätssicherung. Schließlich sind sie nur dann sinnvoll, wenn ihre Daten eine gute Entscheidungsgrundlage für die Softwareentwicklung schaffen. Sie müssen also aussagekräftige Ergebnisse liefern, die man dann geschickt in das Produkt einfließen lässt.

Wie ist die hohe Qualität zu gewährleisten?

Qualitätssicherung ist ein Prozess und QS-Ingenieure müssen im Entwicklungsprozess immer wieder testen, um fundierte Entscheidungen zu ermöglichen – für die Auftraggeber, für die Entwickler oder andere Prozessbeteiligte. Man braucht auch viel Organisationstalent und Lernbereitschaft. Der ganze Testzyklus dient ja auch der Projektevaluierung. Hier ein Beispiel:

Ich bin mit dem QS-Management für ein Projekt beauftragt. Das heißt nicht, dass ich der Gruppe der Tester vorstehe. Vielmehr „manage“ ich einen Testprozess – obwohl ich das Wort nicht besonders mag.

Wir haben also ein neues Projekt. Das erste, was ich mache, ist ein Design für die Testbarkeit. Das ist ein gutes Beispiel, weil sich die Software-Entwicklung in Richtung Fertigprodukt entwickelt hat, fix und fertig konfiguriert und schnell einsetzbar.

Beim „Design for Testability“ kümmere ich mich um die Voraussetzungen, die das Testen erleichtern. Wir entscheiden, nach welchen Prinzipien wir Mock-ups oder Fake Objects erstellen. Außerdem befassen wir uns mit automatischer Protokollierung (Logging) und Auszügen von Speicherinhalten (Dumps), weil ein gutes Logging-Konzept für die Fehlerdiagnose wichtig ist. Bei großen Systemen gehen ja oft bestimmte Modultests durch, während Systemtests manchmal scheitern.

Was wir außerdem machen, ist flexible Konfiguration. Hier geht es darum, die einfachste Bereitstellungsmöglichkeit in der Testumgebung zu ermitteln. Darüber denkt heutzutage kaum noch jemand nach, weil man einfach zur CI/CD-Pipeline geht und da eine Paketlösung findet. Aber es gibt immer Elemente, die für das Projekt besser geeignet sind und anders gestaltet werden können.

Die Qualitätssicherung kann auch in späteren Phasen der Entwicklung ansetzen. So war das bei einem anderen Projekt, an dem ich beteiligt war. Es war bereits in einer Phase, in der mehrere Partner einzelne Komponenten schon entwickelt und getestet hatten. Meine Aufgabe bestand darin, den Test auf Systemebene zu entwickeln und auszuführen. Beim Systemtest ging es um die Integration der Komponenten, und der Testprozess wurde entsprechend angelegt. Dazu gehörte auch die Koordination der Stakeholder und die Zusammenarbeit der Teams, d. h. es gab ein eigenes Defect-Management-System, eine spezielle Testumgebung usw.

Hieran sieht man, wie vielfältig die Kompetenzen von QS-Ingenieuren sind. Man ist für die Gestaltung und die Durchführung des Prozesses verantwortlich; man koordiniert aber auch die anderen Beteiligten, während man die Tests schreibt. Das verlangt auch eine gewisse Erfahrung.

Was das Fachwissen angeht: je mehr Wissen und praktische Erfahrung man mit den Grundsätzen, Konzepten und Systemen von Softwarecode hat, desto besser. Dies ist eine solide Grundlage, auf der man aufbauen kann, wenn man selbst programmiert, und man beschäftigt sich ja auch sehr viel mit dem Code anderer Leute.

Die Qualitätssicherung hört mit der Freigabe des Produkts auch nicht auf. Früher haben wir am Projektende „Post-mortem“-Analysen gemacht; heutzutage führen wir Retrospektiven durch, und wenn es sinnvoll ist, verschieben wir Tests zeitlich nach hinten (Shift-Right-Testing). Das finde ich sehr spannend, denn so bleibt man auch nach der Freigabe noch in Kontakt mit dem Projekt. Man entwickelt Monitoringsysteme, die Fehler melden. Ich finde es gut, wenn Tester auch nach der Freigabe am Projekt dranbleiben, weil sie die Qualität und eventuelle Fehler in Echtzeit nachverfolgen können. So sammeln sie wichtige Erkenntnisse über die Qualität der eigenen Arbeit und Erfahrung für zukünftige Projekte.

Findet die Qualitätssicherung angemessene Anerkennung?

Das hängt vom Unternehmen ab. Manche haben eine Qualitätssicherungskultur und sind es gewohnt, mit Testern und QS-Personal zusammenzuarbeiten. In so einem Umfeld, wo die Aufgaben klar definiert und allen bekannt sind, läuft das in der Regel reibungslos.

In Unternehmen, die noch keine Erfahrung mit Qualitätssicherung haben, ist das etwas schwieriger. Man kann das nicht konkret festmachen, aber oft tut man sich erst ein bisschen schwerer, den Qualitätssicherungsprozess zu verstehen und als sinnvoll zu akzeptieren. Am Ende klappt das aber; es dauert nur ein bisschen. In solchen Situationen sind gute Kommunikationsfähigkeiten das Wichtigste, was Sie als Qualitätssicherungsexperte mitbringen müssen.

Viele glauben noch, dass Tester und Entwickler immer entgegengesetzte Positionen vertreten. Ich sehe das aber nicht so. Ich habe immer schon Hand in Hand mit den Entwicklern gearbeitet und dabei viel gelernt. Wenn man mit einer offenen Einstellung an die Sache herangeht, gibt es keine Probleme.

Lernt man ausserhalb des eigenen Büros schneller?

Das war nicht immer so, aber heutzutage gibt es für die Qualitätssicherung genauso viele Online-Ressourcen wie für Entwickler. Am meisten lerne ich aber bei der konkreten Arbeit an Projekten. Hierher beziehe ich mein Know-how, erwerbe neue Fähigkeiten, lerne neue Ansätze kennen und gewinne Einblick in die Trends der Branche. Ich bin deshalb immer in der Entwicklung. Dort sitze ich mit dem Team zusammen und arbeite mit am Projekt.

Auch von IT-Communities lerne ich sehr viel. Ein Umfeld, in dem gut ausgebildete Menschen ihre Erfahrungen und ihr Wissen frei austauschen können, bringt einen wirklich weiter, finde ich. Ich war selbst mehrere Jahre lang in einer solchen Community aktiv. Dort ging es um agile Softwareentwicklung.

Ich habe auch schon an Entwicklerkonferenzen teilgenommen, um im Fach möglichst gut auf dem Laufenden zu bleiben. So weiß ich im Software-Entwicklungsprozess immer, worum es geht. Die Teilnahme an Fachkonferenzen für Softwaretester ist ein Muss. Leider gibt es noch immer keine Konferenz, wo die Anwender verschiedener Technologien zusammenkommen, vor allem Qualitätssicherung und Entwicklung. In den vergangenen Jahren hat es Bemühungen in diese Richtung gegeben, aber noch ist man in der Diskussionsphase.

2014 war ich Vortragende auf einer Konferenz, und mein Thema war das Testen in agilen Entwicklungsprojekten. Das Konzept war noch ganz neu, und ich konnte nur ein einziges Buch zum Thema finden. Weil ich auf der Suche nach guten Lösungen für die Zukunft war, schrieb ich einen Artikel über unsere Arbeit im Unternehmen und unsere Erfahrung mit den Projekten. Ich habe auch eine Weiterbildungskonferenz in Bukarest besucht und hatte danach Gelegenheit, mit Kolleginnen und Kollegen aus der ganzen Welt Erfahrungen auszutauschen. So entstehen hilfreiche Netzwerke. Deshalb nehme ich Einladungen zu solchen Zusammenkünften auch immer gern an.

Wie wird man vom Neuling zum Experten?

Ich rate dazu, sich auf jede erdenkliche Weise weiterzubilden: Bücher, Internet und Online-Seminare. Man muss aber aufpassen, dass man nicht reinen Marketing-Trends nacheifert. Der erste Schritt sollte das Projekt bzw. das Team sein, in dem man gerade arbeitet. Das kann nämlich wirklich weiterhelfen. Für das eigene Vorankommen empfehle ich folgende Strategie:

• Frag Dich, was Du zum Vorteil des Projekts beitragen kannst. So bewegst Du Dich in Richtung Teamdenken und Arbeitsoptimierung.
• Geh schrittweise vor. Vertrau zunächst einmal auf die Hilfe erfahrener Mitarbeiter im Team. Lerne bei jedem Projekt dazu. Lass Dir genug Zeit, auch wenn es in dieser Branche immer um schnelle Ergebnisse geht.
• Wenn Du eine Konferenz besuchst, hör aufmerksam zu, was andere zu sagen haben. Finde heraus, was für Dich von Interesse ist, damit Du Dich in diese Richtung weiterbilden kannst.
• Versuche aber nicht, alles auf einmal anzuwenden. Die berufliche Weiterentwicklung ist eine sehr individuelle Angelegenheit: Triff Deine Entscheidungen bewusst.