Artikel

6 Dinge, die ich bei der Arbeit mit QA gelernt habe

Martin Veith
Senior Software Developer
Veröffentlicht
12. Mai 2020

Am Anfang meiner Karriere als Web Developer spielte das Testen der fertigen Produkte oft nur eine kleine Rolle und ich konnte nie wirklich sagen, dass ich es besonders genossen habe — bis zu dem Tag, an dem ich das erste Mal mit hingebungsvollen QA-Experten zusammenarbeiten durfte und meine Ansichten anfingen, sich zu ändern.

Der Einfachheit halber werde ich den Begriff Tester verwenden, um mich auf die verschiedenen qualitätsorientierten Testerrollen zu beziehen.

1. Motivation & Aufregung

Es war der Beginn eines vielversprechenden Tages im Frühling vor einigen Jahren, ein Tag, den ich nicht so schnell vergessen würde, als ein neuer Kollege unserem Team beitrat. Und nicht nur irgendein Kollege — ein professioneller Tester!

Ich war mir nicht ganz sicher, auf was ich mich gefasst machen sollte. Meine Aufregung ging mit etwas Nervosität einher, so ähnlich wie sich Haustiere fühlen, wenn sie sich auf einmal zusammen mit anderen Haustieren in einer neuen, unerkundeten Umgebung zurechtfinden müssen.

Langsam, aber sicher trudelten die Nachfragen ein, meine Arbeit zu testen und Aufgaben, die ehemals mir zufielen, zu übernehmen. Das beinhaltete Feature- und Release-Planung, Austausch mit Kunden bei unvollständigen, unklaren oder unpassenden Spezifizierungen und natürlich Qualitätskontrolle.

Wie bereits erwähnt schien mir damals die Idee, Dinge immer und immer wieder zu testen, nicht gerade fesselnd. Trotzdem, im Laufe der Zeit entwickelte ich dann doch ein Interesse dafür, was der Job eines Testers alles involviert. Also entschied ich mich ohne weiteres dazu, in das Thema einzutauchen und Einblicke in den typischen Testertag zu sammeln.

Schließlich stellt sich die Frage: “Wer testet die Tester?

2. Wertschätzung

Mit meiner Arbeit an Projekten unterschiedlicher Größen und mit verschiedensten Kunden habe ich ein gutes Verständnis dafür erlangt, wie viel Zeit und Aufwand notwendig war, um die spezifischen Qualitätsstandards des Produkts von Anfang bis Ende zu erfüllen. Nichtsdestotrotz hat mir diese neue Zusammenarbeit mit Testern innerhalb kürzester Zeit vielfältige neue Testansätze, Prozesse und Techniken offenbart und mir wurde klar, dass ich nur an der Oberfläche gründlichen Testens gekratzt hatte.

Außerdem fing ich an, mich komfortabler, entspannter und selbstbewusster beim Schreiben von Code zu fühlen, denn die Tatsache, dass eine andere Denkart und ein anderes Paar Augen meine Arbeit überprüfte, gab mir ein Gefühl von Sicherheit.

Ein Tester ist die erste Verteidigungslinie eines Entwicklers.

Das alles sind Dinge, für die ich heute sehr dankbar bin, weswegen ich Tester und QA generell gerne als Verteidigungslinie der Entwickler bezeichne. Eine Versicherung sozusagen, falls etwas beim Release eines neuen Features schiefgeht.

Rollen und Verantwortungen haben sich mit mir mitgeändert. Wegen meiner vorherigen Erfahrung als “selbsternannter Tester” hat es etwas gedauert, bis ich das richtige Tempo in dieser neuen Dynamik gefunden habe. Ich überschritt manchmal nach wie vor Grenzen und testete meine Arbeit selbst, anstatt sie den stets hungrigen Testern neben mir anzuvertrauen.

Während ich mich darum bemühte, mich wieder auf die Kernaufgaben eines Software-Entwicklers zu fokussieren, half mir die Perspektive und die frische Denkweise unserer Tester, überhaupt ein besserer Entwickler zu werden. Ein gutes Beispiel dafür ist die Tatsache, dass ich gelernt habe, Code zu schreiben, der echten User-Szenarien Stand hält und nicht nur langwierige, künstliche Test Cases durchläuft.

Zudem hat das Etablieren direkter Kommunikationskanäle für schnelles und kontinuierliches Feedback dabei geholfen, diese neuen Workflows zu optimieren.

Alles ein gutes Zeichen dafür, dass mein Experiment schon erste Früchte trug!

3. Beziehung

Eine gesunde und freundliche Beziehung aufrechtzuerhalten ist für den Erfolg eines Teams unerlässlich — vor allem zwischen Entwicklern und Testern. Es ist eine Sache, sich darauf verlassen zu können, dass Tester potenzielle Probleme im Code finden. Auf der anderen Seite möchte ich aber sicherstellen, dass der Tester seine Arbeit transparent und stressfrei verrichten kann, ohne ständig mit neuen, unvorhersehbaren Bugs kämpfen zu müssen.

Diese Beziehung könnte auch mit der Ying-Yang-Philosophie verglichen werden. Einerseits verfolgen beide Seiten ihre eigenen Ziele, andererseits ergänzen sie einander und arbeiten auf dasselbe Resultat zu — ein hochqualitatives Produkt.

Photo von Robert Zunikoff

Leider kann die Realität manchmal anders aussehen, wenn Entwickler und Tester in einen Interessenskonflikt geraten, sei es aufgrund von unklaren Verantwortungen, Missverständnissen, Frustrationen, Faulheit, Motivationsmangel, etc.

Dem Tester die Schuld dafür zu geben, dass Dinge nicht mehr richtig funktionieren, scheint oft einfacher, als seine eigenen Fehler zuzugeben. Stattdessen muss uns klar werden, dass Tester unsere Verbündeten sind, die mit uns zusammen für reibungslose Produktreleases kämpfen und keineswegs dafür da sind, unseren Traum vom bugfreien Code zunichte zu machen, sondern uns dort (eines Tages) hinzubringen.

Danke, dass ihr mich zu einem besseren Entwickler macht — einen Pull Request nach dem anderen!

Fehler sind unvermeidbar, jedoch können wir sie nutzen, um von ihnen zu lernen, anstatt unsere Augen vor der Wahrheit zu verschließen. Wenn ein Tester von einem Problem berichtet, sollten wir willig sein, zuzuhören und zu reflektieren, wie wir unsere Arbeit zukünftig verbessern können.

Natürlich ist das nicht immer einfach, jemandem dafür zu danken, dass er einem mitteilt, man habe sich nicht genügend angestrengt. Umso inspirierender ist es, zu sehen, wenn Leute das tatsächlich tun und anderen Anerkennung dafür zollen. Nehmt euch einfach etwas Zeit und sagt es laut — Tester werden es genauso wertschätzen wie Entwickler!

Wir müssen fair, transparent, einladend und stets konstruktiv sein, um von Fehlern zu lernen und sie als Gelegenheit zu sehen, Verantwortung zu übernehmen und es das nächste Mal besser zu machen.

4. Vertrauen

Entwickler und Tester spielen eine gleichermaßen wichtige Rolle dabei, funktionierende Applikationen pünktlich zu liefern — ein Ziel, welches ohne ein gewisses Maß an Vertrauen schwer zu erreichen ist.

Wenn Entwickler über ihre Zusammenarbeit mit QA so erzählen, als wären sie in einem Weltkrieg, dann läuft definitiv etwas falsch. Eine der möglichen Gründe dafür ist oftmals, dass es Tester sehr freut, Pandorabüchsen zu öffnen und den Ursprung aller Bugs zu suchen und finden.

Grundsätzlich ist nichts falsch daran, diesen Enthusiasmus zu zeigen und zu teilen. Diese Entdeckungen zu kommunizieren ist jedoch ein Drahtseilakt, der über den Erfolg eines Teams entscheiden kann. Auf Bugs sollte nur dafür hingewiesen werden, um den Entwicklungsfortschritt voranzutreiben und nicht deswegen, um einen Entwickler für seinen Fehler zur Schau zu stellen.

Tester sollten sich andererseits darauf verlassen können, dass Code nicht halbherzig geschrieben wurde, weil jemand “sowieso einen Blick darauf wirft, bevor es live geht”. Sobald um Tests gebeten wird, sollte die notwendige Information bereits vorhanden sein, um eben jene effizient durchzuführen. Ich habe mich selbst beispielsweise mehrmals dabei erwischt, wie ich Tester durch obskure Flows habe irren lassen, ohne dass ich die Rahmenbedingungen erklärt habe — das darf nicht sein.

Nichtsdestoweniger glaube ich, dass ein vernünftiges Maß an gegenseitigem Vertrauen uns das Selbstbewusstsein und die Geschwindigkeit gibt, um schneller zusammen voranzuschreiten. Diese kleinen Dinge sind es, denen wir stets Augenmerk schenken sollten.

Während Vertrauen vorteilhaft sein kann, sollte auf Kontrolle auch nicht vollständig verzichtet werden. Es wird Situationen geben, in denen man an der Arbeit des anderen zweifelt und wo man sichergehen möchte, dass etwas richtig gemacht wurde und dementsprechend aushelfen möchte. Wie bereits erwähnt, Entwickler und Tester arbeiten meines Erachtens nach auf eine sehr ergänzende Art und Weise und manchmal überlappen sich ihre Kompetenzgebiete, um ein Ziel zu erreichen.

5. Zuverlässigkeit

Es lässt sich schon sagen, dass man ausgehend von meiner bisherigen Vorstellung typischer Testaktivitäten glauben könnte, dass diese nicht viel mehr als ein Tropfen auf dem heißen Stein sind. Tatsächlich passiert aber viel mehr hinter den Kulissen, darunter die Tatsache, dass Tester sukzessive ein Gespür für alle Ausgefallenheiten des Produkts entwickeln, die nicht viele in einem Projekt sehen oder kennen.

Habt ihr zum Beispiel jemals damit kämpfen müssen, dass eine Spezifikation keinen Sinn gemacht hat? Dass User Flows inkonsistent waren? Dass ein Feature, das fehlerhaft schien, so beabsichtigt war? Hier kommen Tester zum Einsatz!

Dank der Aufmerksamkeit, die Tester den Details des Produkts, dem Team oder so gut wie jedem anderen Thema widmen, haben sich oft großartige und sehr informative Gespräche ergeben, wann immer ich sie um Hilfe gebeten habe.

Jemanden mit dieser Versiertheit bei sich zu haben ist viel wert und gibt mir mehr Gewissheit beim Navigieren durch ein Produkt, vor allem, wenn Wissen in einem breiteren Kontext vonnöten ist. Ob es sich um Features, User Experience oder generell qualitätsbezogene Dinge handelt, das ganze Team kann von QA profitieren.

6. Teilen von Wissen

Eine reibungslose Zusammenarbeit zwischen beiden Seiten aufrechtzuerhalten heißt idealerweise auch, die Rolle und den Einfluss auf das Produkt des jeweils anderen zu verstehen. Egal, ob wir über Fehler, Defekte, Ausfälle sprechen, es ist wichtig, sich darüber im Klaren zu sein, wie die tägliche Routine eines Testers aussieht, was Testprozesse involvieren und wie wir uns bei Usability Tests, Code Reviews und Testautomatisierung einbringen können.

In Parkside haben Entwickler und Tester (unter anderem) die Möglichkeit, wöchentlich in Communities of Practice zusammenzusitzen, ihre Erfahrungen und Techniken zu teilen und über andere hilfreiche Themen zu sprechen.

Allein schon die Basics zu wissen verleiht einem die Flexibilität und die Fähigkeit dafür, out-of-the-box zu denken und Edge Cases von Anfang an zu erwägen. In eine gemeinsame Knowledge Base zu investieren ist also ein essentieller Bestandteil dynamischer und multidisziplinärer Teams.

Zusammenfassend…

hat mir das Arbeiten mit Testern aus aller Herren Länder sehr dabei geholfen, meinen Horizont in vielerlei Hinsicht zu erweitern und meine Soft & Hard Skills als Software-Entwickler weiterzuentwickeln. Zudem ist mein Interesse an der Thematik stetig gewachsen und das möchte ich nicht mehr missen.

Glücklicherweise bin ich nun immer von Testern umgeben, die mir das Gefühl geben, dass sie meinen Rücken decken und je früher Entwickler sich dieser Synergie bewusst werden, desto besser werden die Resultate. Gegenseitige Wertschätzung für die jeweiligen Leistungen zu zeigen ist genauso wichtig, wie mit Dingen, die nicht gut gelaufen sind, ehrlich, vorurteilsfrei und realistisch umzugehen. Letztendlich sitzen wir alle im selben Boot mit einwandfreier und bugfreier Software als gemeinsames Ziel. We’re better together!

Ähnliche Artikel
Artikel
Cognitive Load: Ein Einblick in einen wichtigen UX-Bestandteil
Artikel
DesignOps: Unseren Designprozesses überdenken
Artikel
Home Office – Best Practices, Tipps & Tricks