BDD ist eine Technik zur Fokussierung der Softwarebeschreibung auf das Verhalten der Softwarekomponenten. Anforderungen werden durch eine Gegeben-Wenn-Dann-Form beschrieben. Testfälle lassen sich auf die gleiche Art und Weise beschreiben. Als Testfall beschriebene Anforderungen reduzieren das Risiko, dass die Erwartungshaltung des Fachbereichs durch die Umsetzer missverstanden wird. Der Arbeitsaufwand wird vorverlagert, spart jedoch mehr Ressourcen hinten raus. Spät entdeckte Design-Fehler kosten viel Zeit und Geld.
Falls eine Testautomatisierung angestrebt wird, kann die Entwicklung der Anforderungen auf Schrittebene (Gegeben-Wenn-Dann) erfolgen. Die einzelnen Schritte bilden einen Baukasten zum schnellen Erstellen von neuer Software oder Tests.
Wenn wir die Anforderungsaufnahme für das Softwareprojekt durchführen, stellen wir sicher, dass die Anforderungen direkt als Testfälle beschrieben werden.

Testen ist in der Regel mit großem manuellem Aufwand verbunden. In der klassischen Projekt-Herangehensweise werden ganze Teams oder Abteilungen für das Testen von Neuerungen, Fehlerbehebungen oder lediglich zur Kontrolle, ob bereits laufende Software noch funktioniert, abgestellt. Der Aufwand kann durch Automatisierung reduziert werden.
Eine Einrichtung von Deployment-Pipelines, mit aus automatisierten Testfällen bestehenden Quality Gates, beschleunigt den Release Zyklus und steigert die Qualität.
Nicht für alle Prozesse lohnt sich eine Automatisierung. Zum Beispiel dann nicht, wenn die Erstellung der Automatisierung länger dauern würde, als die dadurch eingesparte Zeit. Oder aber, der zu automatisierende Testfall sehr selten verwendet wird. Die Testautomatisierung kann je nach Fall ein eigenes Softwareprojekt bedeuten. Deswegen muss die sogenannte „Testautomatisierungspyramide“ gewahrt werden:

• Zum größten Teil gilt es Unit-Tests zu implementieren.
• Kleinst-Bestandteile der gegebenen Software zur Prüfung einzelner Methoden und Schnittstellen – unter anderem durch Verwendung von Mocks.
• Komponententests sollten dann verwendet werden, wenn die Interaktion zwischen Systemen durch Unit-Tests allein schwer testbar ist.
• Am wenigsten und nur in Ausnahmefällen sollten automatische Tests auf Basis von Benutzermasken (UX/UI) zur Nachstellung von Fachbereichstests erfolgen. Die Erstellung ist aufwändig und teuer.

Neben dem eigentlichen Software-Test können „Smoke-Tests“ auch für die Prüfung der Testumgebungsfunktionalität verwendet werden.
Wir analysieren ob und an welcher Stelle, mit welchen Technologien sich eine Automatisierung lohnt. Zusätzlich beraten wir durch welche Tools automatisiert werden könnte und managen die Implementierung.

Testen, manuell oder automatisiert, basiert in vielen Fällen auf Daten. Datenkonstellationen bilden Sachverhalte ab, die Gegenstand der jeweiligen Tests sind. Einmal verwendet, gilt eine Konstellation oft als verbraucht. Manche Konstellationen sind seltener als andere.
Je nach Architektur der Testumgebungen sowie der Art der Instandhaltung dieser, kann es somit passieren, dass es für geschäftskritische Prozesse keine passende Datenkonstellation mehr gibt.
Diese Problematik wird dadurch verschärft, dass unterschiedliche Organisationseinheiten oder Projekte sich die Daten teilen müssen.
Deswegen bedarf es ein effizientes Testdatenmanagement und eine technische Abhilfe:

• Organisatorisch lassen sich kleinere Konflikte vermeiden und die Verwendung von kritischen Datenkonstellationen taktisch planen.
• Darüber hinaus können Daten bei bekannter Spezifikation und einer dafür geeigneten Anpassung der Systeme synthetisch hergestellt werden. Dies ist für die Testautomatisierung besonders hilfreich.
• Falls eine synthetische Herstellung der Daten keine Option ist, kann eine „Zeitmaschine“ implementiert werden. So wird eine Momentaufnahme einer Konstellation zwischengespeichert und nach dem Test wieder verfügbar gemacht.
• Für ein selbstorganisierendes Testdatenmanagement empfiehlt sich die Einführung der Möglichkeit Konstellationen zu sperren. Mit einem passenden Rechte- und Rollen-Konzept wird Konfliktpotential entschärft.

Neben dem eigentlichen Management gilt es aus rechtlichen Gründen (DSGVO Artikel 25, Absatz 1) Daten sparsam einzusetzen. Um diesem entgegenzukommen, sollten nicht in der Produktion verwendete Daten (Testdaten) anonymisiert werden. Bei all diesen Thematiken unterstützen wir Sie gerne mit unseren Best Practices: von der Ist-Analyse bis zum reibungslosen Testdatenmanagement.

Die klassische Testumgebungsarchitektur sieht eine stufenweise Entwicklung, Verbindung, Verprobung und Veröffentlichung von Anwendungen vor. Da jede Umgebung eine Abstraktion der Produktionsumgebung ist und gewisse Abstriche hat, gilt es einen Überblick über die enthaltenen Systeme und Services zu behalten. Eine reibungslose Funktionalität von Testumgebungen ist ausschlaggebend für das planmäßige Vorankommen in Testphasen von Projekten und somit auch entscheidend vor größeren Releases. Durch eine zentrale Instanz lässt sich ein Monitoring aufsetzen, welches den Status der Umgebungskomponenten aufzeigt. Hierdurch lassen sich bei nicht Verfügbarkeit Test- und Entwicklerressourcen schonen. Dies insbesondere dadurch, dass gefundene Softwarefehler, die eventuell auf Nichtverfügbarkeit basieren, nicht analysiert werden müssen. Neben dem Monitoring bedarf es einer Koordination von einzuplanenden Maßnahmen, wie z.B. Last- und Performance-Tests oder aufwendigen Datenverarbeitungen / Batches / Cron Jobs. In agilem Kontext des Continuous Integration und Continuous Delivery (CI/CD) gilt es passende Releasepfade (Pipelines) und somit Quality Gates zu definieren.

Neben den projektbedingten Testmanagement-Aktivitäten kann es von Vorteil sein, wenn es eine zentrale Testmanagement-Organisationseinheit gibt, die ein reibungsloses Testgeschehen gewährleistet. Der Aufbau solch einer Organisationseinheit bedarf einer passenden Integration in die Unternehmenslandschaft und somit Verknüpfung mit anderen Abteilungen, Teams und den geplanten sowie laufenden Projekten. Es gilt Standards für das Unternehmen festzulegen: Prozesse, Technologien, Regeln und mögliche Kommunikationspfade. Die Beschaffenheit der Testmanagement-Abteilung / des Teams kann von der Administration der Rahmenbedingungen, über das Testumgebungsmanagement bis hin zu einer aktiven Management-Unterstützung der Projekte reichen.