Test AutomationMethoden

Testautomatisierung im Projekt einsetzen

Wer Chaos automatisiert, erhält automatisiertes Chaos. Damit es nicht so weit kommt, gilt es, den Einsatz der Tools und Pipelines im Kontext der Projekte zu betrachten. Wie entstehen aus Anforderungen gute und automatisierte Testfälle?

Icon
Test-Driven Development

Test-Driven Development (TDD) ist eine Methode, die sich insbesondere für Komponententests eignet. Anstatt mit der Implementierung einer Lösung zu beginnen und diese anschließend zu testen, wird dieser Ansatz umgedreht.

Icon
Behaviour-Driven Development

Behaviour-Driven Development (BDD) ein agiler Softwareentwicklungsansatz, in dem es sich um die Kollaboration im Team und um die Anleitung der Entwicklungsarbeit durch ausführbare und leicht verständliche Spezifikationen dreht.

Ansprechpartner

Jan-Erik Senf
Senior Key Account ManagerJan-Erik Senf+49 351 44008 237+49 175 1692 153jesenf@proficom.de

Test-Driven Development

Test-Driven Development (TDD) ist eine Methode, die sich insbesondere für die Komponententests eignet. Anstatt mit der Implementierung einer Lösung zu beginnen und diese anschließend zu testen, wird dieser Ansatz umgedreht:

  1. Die gewünschte Funktionalität wird in Form von Tests definiert.
  2. Die Tests werden ausgeführt und schlagen fehl.
  3. Erst jetzt erfolgt die Implementierung der eigentlichen Funktionalität. Mit jeder Änderung werden die Tests erneut ausgeführt.
  4. Die Implementierung endet, sobald alle Tests erfolgreich absolviert sind.

Dieser Ansatz kann in der Realität sehr gut funktionieren, wenn die Entwickler bei der Implementierung der Tests Unterstützung durch testerfahrene Mitarbeiter bekommen. Andernfalls besteht das Risiko, dass nur „gute“ Testfälle erstellt werden und Randfälle nicht betrachtet wurden.

Sie benötigen Test-Know-How in Ihrem Projekt, um TDD einzuführen oder umzusetzen? Dann zögern Sie nicht und kontaktieren uns!

Behaviour-Driven Development

Im Kern ist Behaviour-Driven Development (BDD) ein agiler Softwareentwicklungsansatz, der aus dem Test-Driven-Development-Ansatz heraus entstanden ist, diesen jedoch um einen wichtigen Aspekt erweitert. Dabei dreht sich alles um die Kollaboration im Team und um die Anleitung der Entwicklungsarbeit durch ausführbare und leicht verständliche Spezifikationen.

Einfacher ausgedrückt, steht bei BDD am Anfang eines Entwicklungszyklus immer erst einmal die gemeinsame Analyse von Anforderungen im gesamten Team. Um ein kollektives Verständnis dafür aufzubauen, welches Feature als nächstes genau entwickelt werden soll, wird sich der Sammlung und Formulierung kurzer, fokussierter Szenarien aus Anwendersicht gewidmet. So werden nach und nach alle Kriterien einer Feature-Anforderung anhand verständlicher Anwendungsbeispiele beschrieben und dies in einem sogenannten "Feature File" in formalisierter Syntax festgehalten.

Das kann dann in einem vereinfachten Beispiel so aussehen:


Feature: Delete User Account
As a customer of the onlineshop
I want to be able to delete my user account
in order to have full control over my data

Background:
Given "Larissa" is a registered customer
And "Larissa" is logged in

Scenario: Account deletion successful
When "Larissa" requests an account deletion
And "Larissa" confirms the deletion
Then "Larissa" should be logged out automatically
And account data for "Larissa" should be deleted

Scenario: Account deletion canceled
When "Larissa" requests an account deletion
But "Larissa" does not confirm the deletion
Then "Larissa" should still be logged in
And account data for "Larissa" should still exist

Der Vorteil liegt hier darin, dass die Feature-Spezifikationen in einer nicht-technischen, natürlichen Sprache beschrieben sind, um nicht nur für Entwickler:innen verständlich zu sein, sondern für das gesamte Team und Stakeholder.

Schließlich wird Testcode für jeden Schritt geschrieben, um das Feature-File für die Ausführung vorzubereiten. Entwickler haben dann ein klar beschriebenes Dokument an der Hand, das sie während der Entwicklungsphase beliebig oft ausführen können, um zu prüfen, ob der entwickelte Applikationscode die Anforderungen erfüllt.

Testdaten und Projektumfeld

Neben der reinen Ausführung der Tests über Tools sind zwei Themenbereiche zu beachten:

  • Das Projektumfeld: Welche Qualitätsziele sind wie zu erreichen? Wie viel Zeit und Budget steht zur Verfügung? Nach welchem Entwicklungsmodell (Wasserfall, Scrum) wird vorgegangen? Sind die notwendigen Infrastrukturen vorhanden?
  • Testdaten: Ohne geeignete Testdaten ist die beste Testautomatisierungslösung oft nutzlos. Liegen die Daten zum passenden Zeitpunkt im richtigen Format vor? Müssen die Daten gegebenenfalls anonymisiert werden? Können die Testdaten durch die Automatisierung verändert werden?

So wäre es ärgerlich, wenn im Rahmen der Tests eines Webshops eine reale Bestellung in den Versand ausgelöst würde.

Sie haben Fragen?

Gern stehen wir Ihnen mit Know-how, konkreten Unterstützungsleistungen und zugehörigen Lizenz- und Supportangeboten zur Verfügung.

Background Image Mobile Version