Was macht eigentlich… ein:e Mitarbeiter:in in der Qualitätssicherung bei Netfonds

Hallo Constanze, Corinna und Dirk, schön dass ihr es einrichten konntet. Ich habe gehört, ihr arbeitet bei Netfonds in der Qualitätssicherung (QS). Ein zweifelsohne sehr spannendes Thema, würdet ihr mir hierzu einige Fragen erlauben?

Constanze: Sehr gern, schieß los!

Wie kommt man denn zur Qualitätssicherung?

Corinna: Man kann auf ganz unterschiedlichen Wegen in die Qualitätssicherung kommen und verschiedene Interessenschwerpunkte haben. Ursprünglich komme ich aus der Webentwicklung, habe aber zunehmend das Interesse am Testen entwickelt und bin dann bei Netfonds komplett in diese Rolle gewechselt.
Meine Kollegen sind z. B. nach dem Elektrotechnik-Studium direkt ins Testing eingestiegen oder vom Datenbankentwickler ins Testing gewechselt.

Was gefällt euch daran, in der QS zu sein?

Dirk: In der QS zu sein bedeutet ja, einen erheblichen Teil zur Qualitätssicherung beizutragen.
Mich stellt es einfach sehr zufrieden, zu wissen, dass dadurch mehr Vertrauen in unsere Software geschaffen wird. Mir macht es außerdem Spaß, mich wirklich intensiv mit unserer Software finfire auseinanderzusetzen und zu erforschen, wie sich die verschiedenen Komponenten verhalten und miteinander zusammenarbeiten. 
Das Betrachten unserer Software aus dem Sichtfeld der QS erlaubt es mir zudem, aktiv positive Impulse in die Entwicklung mit einfließen zu lassen und damit kontinuierlich unser Produkt für unsere Benutzer zu verbessern.

Wie seid ihr im Team organisiert?

Constanze: Bei Netfonds arbeiten wir in Scrum-Teams. Als QS ist man unabdingbarer Teil eines dieser Teams und steht somit ständig in diplomatischer Kommunikation mit allen Teammitgliedern. Wir besprechen mit dem PO (Product Owner) Stories und Akzeptanzkriterien, mit dem UI/UX Kollegen tauschen wir uns über die Oberfläche der Anwendung und die Usability für den Endbenutzer aus, mit den Frontend- und Backendentwicklern über die gebauten Features und Verbesserungen und mit dem Scrum Master wie wir besser und effektiver im Team zusammenarbeiten können.
Natürlich koordinieren wir uns auch mit der QS aus den anderen Teams über die Abläufe und Standards.

Unter dem Testen stelle ich mir vor, dass dafür den ganzen Tag irgendwie rumgeklickt wird. Stimmt das?

Ein kleines Zahlenbeispiel hierfür: 
Bei Tests sind 70% automatisierte und 30% explorative Tests anzustreben. Dennoch werden über 60% der Fehler durch das explorative und nur knapp 40% durch das automatisierte Testen gefunden.

Arbeiten in der Qualitätssicherung bedeutet also mehr als nur Testen?

Constanze: Testen bedeutet, eine ganzheitliche Sicht auf die Qualität zu haben. Als QS ist man bei jedem Schritt des Scrum-Prozesses mit dabei. Dies beginnt mit der Berücksichtigung bestimmter Testfälle bereits beim Planning, geht über das begleitende Testen während der Entwicklung und endet mit den Abnahmen fertiger Stories und Bugfixes. 
Wir wirken zudem an der Verbesserung des Scrum-Prozesses mit, indem wir z.B. unsere DoD (Definition of Done) ausarbeiten.
Die Besonderheit bei Netfonds ist auch, dass jeder anhand seiner Interessen in bestimmten Bereichen mitwirken kann, z. B. an sicherheitsrelevanten Themen, DevOps, Administration oder Prozessverbesserungen.

Sind eure Teams nicht davon genervt, wenn ihr immer versucht, die Features kaputt zu spielen?

Dirk: Danke für diese Frage. Das Ziel ist natürlich nicht, etwas kaputt zu machen, sondern das Endprodukt zu optimieren. Klar gibt es manchmal auch Unmut bei gefundenen Fehlern, aber insgesamt ist jeder gefixte Fehler ein Fehler, den der Anwender nicht sieht.
Am Ende des Tages ist aber nicht nur die QS, sondern das gesamte Team für die Qualität verantwortlich und die Entwickler freuen sich über hilfreiche Tests.

Was passiert, wenn ein Fehler gefunden wurde?

Corinna: Wenn Fehler bei der Abnahme eines neuen Features auffallen, werden diese kommuniziert und in der Regel direkt von den Entwicklern behoben. Gelegentlich werden beim Abnahmetest auch weitere notwendige Feature-Änderungen oder Erweiterungen deutlich, die dann in neue Tickets gegossen werden. Werden Fehler unabhängig von Abnahmen gefunden, legen wir neue Bug Tickets an, die vom jeweiligen Team priorisiert und entsprechend eingeplant werden.

So, letzte Frage: Ihr testet den Code der Entwickler – wer testet oder überprüft euch?

Constanze: Da wir ja im Scrum-Team entwickeln, teilen sich PO, UX und QS gleichermaßen die Abnahmen der Stories, sodass immer mehrere Augenpaare drauf geschaut und manuell getestet haben. Unsere automatisierten Tests durchlaufen den gleichen Code-Review-Prozess wie der Produktivcode der Entwickler; das heißt auch als QS erstellen wir Code mit den gleichen Qualitäts-Grundsätzen.

Wenn von den Kunden zu einem Feature aber viel negatives Feedback zurückkommt – sei es ein fachliches Problem, ein unverständliches Interface oder ein Fehler in der Programmierung – wissen wir, dass wir bei diesem Teil der Software genauer hinschauen müssen. Ein Grundsatz des Testens besagt: “Wo eine hohe Fehlerdichte ermittelt wurde, ist die Software sehr komplex und beinhaltet häufig noch weitere Fehler.”

Außerdem kann ich immer auf die Unterstützung und Hilfe meiner QS Kollegen zählen. QS ist ein kontinuierlicher Prozess, der mit gewonnener Erfahrung immer weiter verbessert wird und bei dem man sich stets persönlich weiterentwickeln kann. Wenn ich mir heute Tests von früher anschaue, wird mir diese Entwicklung besonders deutlich.

Oha! Vielen Dank für diesen erfrischenden Einblick, das war sehr aufschlussreich und hat mir Appetit auf das Testen bei Netfonds gemacht. Wo kann ich mich bewerben?

Dirk: Komm einfach auf unsere Seite für Stellenangebote. Da findest du bestimmt etwas, das dir gefällt.

Über die Co-Autoren

Bild: Canva