„Wie mache ich es kaputt?“

Agile Testing


Selbstredend liegt es unserem Agile Tester Niklas fern, Dinge kaputt zu machen. Wer jedoch für maximale Belastung und Sicherheit verantwortlich ist, muss sich an die Schmerzgrenze wagen – bei der Software, und manchmal bei den Kollegen.

Warum wird man ausgerechnet Agile Tester?

Mein Interesse an der Softwareentwicklung ging schon immer über das Programmieren hinaus – auch wenn dies Hand-in-Hand geht, denn ohne Programmierkenntnisse ist Testing kaum möglich.

Welche Voraussetzungen muss man mitbringen?

Das Thema Testing ist sehr umfangreich. Es reicht nicht aus, eine Programmiersprache zu verstehen, sondern man muss die Logik und die Risiken erkennen. Für Tester ist es zudem ungemein wichtig, mit den Entwicklern eine gute Kommunikationsebene zu finden; man braucht Fingerspitzengefühl, um Kollegen auf Fehler hinzuweisen, sie aber nicht in ihrem Anspruch an Code zu kränken.

Was sind deine konkreten Aufgaben?

Nun, man ist grundsätzlich für das Testen von Software über den gesamten Lifecycle zuständig – wobei der Fokus auf Qualitätssicherung liegt. Zu meinen Aufgaben gehört es, das Qualitätsverständnis in den Teams zu schärfen, neue Tools einzuführen und letztendlich auch das Testing in sämtlichen Ausprägungen durchzuführen.

Welche Ausprägungen gibt es?

Das Etablieren von Code Reviews und Unit-Tests in den Entwicklerteams, das Durchführen der statischen Code-Analyse, Automatisierung von funktionalen Tests zum Testen von User Stories, exploratives bzw. manuelles Testen von End-to-End-Tests, UX- und Designtests über Prototypen, Lasttests (nicht-funktional) und Penetrationstests.

Das Thema scheint wirklich sehr umfangreich zu sein.

Man kann die Arten von Tests anhand einer Pyramide oder anhand eines Testquadranten erklären.

In der Betrachtung des Testquadranten werden 4 Arten von Tests definiert. Im ersten Quadranten wird getestet ob der Code in Ordnung ist. Im zweiten Quadranten werden funktionale Beispieltests und Story Tests abgebildet, also GUI und API-Tests. Hierbei geht man idealerweise nach dem Behaviour-Driven-Development Ansatz vor, wonach die Features über bestimmte Szenarien, die exemplarisch für die Interaktion des Users sind, definiert werden.

Wie sehen diese Szenarien aus?

Man beschreibt diese Szenarien über das Given-When-Then Prinzip. Demnach werden zunächst die Vorbedingungen festgelegt, die erfüllt werden müssen (GIVEN), um dann zu schauen, welche Aktionen durchgeführt werden (WHEN) um das erwartete Ergebnis zu erzielen (THEN).

Wer definiert die Voraussetzungen?

Die Szenarien werden vom Product Owner und dem Entwicklerteam im Planning Meeting oder auch Estimation Meeting definiert. In der Praxis hat sich vermehrt das 3-Amigos-Modell durchgesetzt, wonach mindestens ein Entwickler, ein Tester und ein Product Owner an der Definition beteiligt sein sollten, um die Sichtweisen „Was will ich eigentlich?“, „Wie schaffe ich das?“ und „Wie mache ich es kaputt?“ abzudecken.

Was hat es mit Testautomatisierung auf sich?

Für uns hat Testautomatisierung einen sehr hohen Stellenwert. Da wir mit mehreren Iterationen arbeiten und somit auch häufige Releases haben, müssen wir oft die immer gleichen Komponenten testen. Um dennoch eine schnelle Rückmeldung zu erhalten, sind wir daher auf die Automatisierung der häufiger benötigten Tests angewiesen. Als Testautomatisierungstool verwenden wir Cucumber, das wie bereits bei den GUI-Tests beschrieben nach dem BDD-Framework definiert wird. In diesem Tool werden die verschiedenen Szenarien, die getestet werden sollen, in natürlicher Sprache geschrieben und dann mit Funktionen über reguläre Ausdrücke verknüpft. Als Beispiel kann man sich das Szenario „When I log in“ vorstellen, für das dann in Cucumber die Java-Funktionen rausgesucht werden, die für das Szenario aufgerufen werden müssen.

Zurück zum Testquadranten: Welche Tests verbergen sich in Quadrant 3 und 4?

Der dritte Quadrant widmet sich den explorativen, also manuellen Tests, die die User-Akzeptanz betrachten. Im letzten Quadranten schaut man auf die Last- und Performance und Security Tests. Letzteres ist klar, unter Security Tests kann man sich ganz einfach den vorsätzlichen Versuch eine Software zu hacken vorstellen. Bei Last- und Performance Tests wird eine große Last an Nutzern in durch vorherige Analysen festgelegten Peaks simuliert.

In welchem Testing-Projekt bist du augenblicklich beschäftigt?

Zuletzt wurde ich in einem Projekt für die zentrale Plattform eines Kunden in China eingesetzt. Dabei sollten verschiedene Dienste unter Lastaspekten getestet werden. Konkret bedeutet das: Was passiert, wenn eine große Anzahl von Fahrzeigen mehrere Services gleichzeitig aufrufen? Da das Aufrufen bei der zentralen Plattform von den Autos unterschiedlich ausgeführt wird, gestaltet sich das Thema Lasttests in dem Kontext sehr komplex. Wir nutzen dafür Grinder, das den jeweiligen Test nicht nur einmal, sondern beispielsweise 100 Mal pro Sekunde aufruft, um festzustellen, ob der Service auch unter der bestimmten Last noch funktioniert. Für unseren Kunden spielt das Testing eine immer größere Rolle, da wir mit einer höchst sicherheitsrelevanten und kritischen Software arbeiten, die zudem eine hohe Nutzerzahl aufweist. Da ist maximale Qualität vonnöten.

Jobs

Weitere Themen