Isabel ist seit 2018 als Java-Entwicklerin Teil unseres OVSoftware-Teams. In einem unserer Kundenprojekte hatte sie darüber hinaus die Chance, einmal “die Seite” zu wechseln. Über das Projekt, ihre Arbeit und ihre Erfahrungen im Bereich Software-Testing hat sie uns im nachfolgenden Interview ein wenig berichtet.
ISABEL, WELCHE ART VON SOFTWARE HAST DU
IN DIESEM PROJEKT GETESTET?
Bei den Tests ging es um die API-Schnittstellen, also die Programmierschnittstellen. In diesem Projekt verknüpften sie das Backend eines Bankensystems mit anderen Anwendungen.
Für API-Schnittstellen gibt es keinen klassischen Entwicklertest. Es erfolgt unmittelbar der Integrationstest. Für die automatisierten Tests habe ich hier vornehmlich JUnit eingesetzt. Teilweise wurden Tests auch manuell mit Hilfe eines RestClients (SoapUI) ausgeführt. Der anschließende Abnahmetest wird meist in den Fachabteilungen selbst durchgeführt. Das war auch hier vorwiegend der Fall.
Dokumentiert habe ich die Testfälle und Bugs zunächst im Qualitycenter, das im weiteren Projektverlauf von Aqua abgelöst wurde. Das Vorgehensmodell in der Entwicklung des Produkts war inkrementell.
WÄREN (THEORETISCH) FÜR DIE TESTS AUCH ANDERE TOOLS EINSETZBAR GEWESEN?
WENN JA, WAS MACHT DEN UNTERSCHIED AUS?
Anstelle von SoapUI wäre der Einsatz anderer RestClients ebenfalls möglich gewesen. Einige Browser bieten hierfür auch Addons an. Ich habe mich allerdings für SoapUI entschieden, weil man dort schönere Möglichkeiten hat, die Testfälle zu speichern. Für die Dokumentation der Testfälle existieren viele verschiedene Tools. So bietet Jira zum Beispiel ein PlugIn an. Aber es gibt auch noch zahlreiche weitere wie Klaros-Testmanagement oder TestLink.
Welches Tool am Ende genutzt wird, hängt davon ab, welche Anwendungsbereiche abgedeckt werden sollen. Möchte man eine Verlinkung zwischen Bugs, Testfällen und Anforderungen haben, dann sind Tools wie Aqua und Jira sehr zu empfehlen. Braucht man diese nicht, ist auch eine Dokumentation in Excel möglich. Davon rate ich allerdings eher ab. Gerade wenn Testfälle und Bug-/Anforderungstickets als Kommunikationsmittel genutzt werden, verliert man mit Excel schnell den Überblick.
Innerhalb des Projekts wurde das Backend von unterschiedlichen Abteilungen an unterschiedlichen Standorten gepflegt. Das war schon eine gewisse Herausforderung, insbesondere was die Kommunikation anging. Es war halt nicht möglich, mal eben ins Nachbarbüro zu gehen, wenn ein Bug gefunden wurde oder die Fehlerbehebung lange dauerte.
Oftmals ist es sehr hilfreich, so etwas in einem persönlichen Gespräch mit dem Entwickler zu klären. Aufgrund der Verteilung auf die verschiedenen Standorte und Abteilungen musste aber vieles über Telefon/Mail und das Ticketsystem abgewickelt werden.
Desweiteren wurden ein Menge Software-Tests zum Thema Fachlichkeit ausgeführt. Dabei geht es nicht um die Funktionsfähigkeit einer Software. Es wird vielmehr geprüft, ob die richtigen Daten ausgegeben werden. Dafür mussten häufig längere Wartezeiten in Kauf genommen werden, u. a. auch, weil andere Bereiche eine höhere Priorität hatten als die API.
Besonders gut finde ich, wenn das eingesetzte Werkzeug in der Lage ist, Anforderungen, Bugs und Testfälle miteinander zu verknüpfen. So hat man einen Überblick über das ganze Produkt und darüber, wie gut es getestet wurde.
Außerdem sollte man mit dem Tool dokumentieren können, wann ein Testfall durchgelaufen ist, wie das erwartete und wie das tatsächliche Ergebnis war. Auswertungsmöglichkeiten sind ebenfalls wichtig, am besten in Form von Grafiken. So kann man direkt erkennen, ob die Anzahl fehlgeschlagener Testfälle mit der Zeit abnimmt.
Grundsätzlich gilt: Je früher man testet, desto günstiger ist die Behebung der Bugs. Darüber hinaus ist es wichtig, dass die Anforderungen, die der Entwickler erhält, eindeutig sind. Ein ganz einfaches Beispiel: In der Anforderung wurde festgelegt, dass die Anwender der Software ab einem Alter von 30 Jahren einen Bonus erhalten. Das kann bedeuten > 30 Jahre oder >= 30 Jahre. Wenn der Entwickler vom 1. ausgeht, der Kunde oder Projektverantwortliche aber vom 2. , dann kommt es zu einem Bug, der dann behoben werden muss.
Eine sorgfältige Dokumentation von Testfällen, Bugs und Anforderungen ist natürlich ebenfalls sehr wichtig, um alles nachvollziehen zu können. Und alle Beteiligten sollten sich darüber im Klaren sein, dass es keine 100%-igen Software-Tests gibt. Man kann nie alles wissen – und manchmal machen Endnutzer unerwartete Dinge. Daher sollte man es als Entwickler nie persönlich nehmen, wenn produktiv Bugs auffallen. (Es sollten dennoch nicht zu viele sein 😉 )
Und nicht zuletzt möchte ich an dieser Stelle auch für gegenseitiges Verständnis werben. Normalerweise sind Entwickler keine Tester im klassischen Sinne. Und Tester sind keine Entwickler. So kann es vorkommen, dass sich ein Entwickler angegriffen fühlt, wenn man als Tester mit dem gefühlt “100. Bug” um die Ecke kommt. Hier ist es ganz wichtig, klar zu machen, dass sich eine Bugmeldung nicht gegen jemanden als Person richtet. Sie dient dazu, die Qualität des Produkt zu sichern oder zu verbessern. Im Gegenzug sollte man als Tester auch etwas tolerant sein und nicht direkt eine persönliche Beschwerde einreichen, wenn auf Entwicklerseite etwas gereizt reagiert wird.
Was ich damit sagen will: Es ist ganz wichtig, miteinander zu sprechen. Die Kommunikation ist wirklich das A und O. Und regelmäßige Meetings, in denen der aktuelle Stand besprochen wird, helfen enorm dabei, zu einem “Wir sitzen alle in einem Boot“ – Gefühl zu gelangen und das Team zusammenwachsen zu lassen.
VIELEN DANK, ISABEL! DAS WAREN SEHR SPANNENDE EINDRÜCKE!
SOFTWARE-TESTING BEI OVSOFTWARE
Sichern Sie die Qualität Ihrer Software. Wir bieten umfassende Testing-Lösungen aus einer Hand.