Tracking-Info
Blog

+49 - 511 - 270 416 0

info@aldebaran.de

Qualitätssicherung in der Softwareentwicklung bei aldebaran

Unser Qualitäts-Standard

Automatische Tests sind das Herz unserer Qualitätssicherung.

Jede Nacht laufen sie über die neueste Version der Software und decken eventuelle Probleme auf. Die wichtigsten von ihnen werden sogar mehrfach täglich ausgeführt, bei jeder Änderung des Codes durch einen Entwickler.

automatische Tests im Nachtbetrieb
Auch nachts aktiv: Unsere automatischen Tests!

Wir verwenden für unsere automatisierten Tests bei jedem Projekt die geeignete Mischung aus:

Warum das sinnvoll ist? Lesen Sie hier: „Warum es so viel fehlerhafte Software gibt“

Dies ergänzen wir durch weitere Qualitätssicherungsmaßnahmen

  1. Probleme, die mit der Systemumgebung zusammenhängen
  2. Missverständnisse bei der Definition von Funktionalitäten
  3. Optimierungsmöglichkeiten bei der Bedienung

Sie bestimmen, was Sie benötigen

Das Schreiben der automatischen Tests benötigt natürlich Zeit und verursacht zunächst Kosten.

Diese amortisieren sich in den meisten Fällen schnell, denn ohne Tests werden Änderungen der Software bald unverhältnismäßig teuer (oder wahlweise: die Qualität nimmt stark ab).

Es gibt auch Fälle, in denen man auf die automatischen Tests verzichten kann: Dies sind vor allem sehr kleine oder kurzlebige Projekte, z.B. Übergangslösungen.

Im Endeffekt bestimmen Sie, welche Qualitätssicherung Sie benötigen und welche Maßnahmen wir bei Ihrem Projekt einsetzen sollen.

Warum es so viel fehlerhafte Software gibt

Es ist nicht sonderlich schwierig, ein Stück Software zu schreiben, das nahezu fehlerfrei ist. Ein Problem entsteht oft erst, wenn die Software geändert werden soll.

Änderungen sind aber bei modernen Softwareprojekten der Normalfall, zumeist weil neue Anforderungen hinzukommen.

Wenn nun die Software angepasst wird, treten häufig an unerwarteter Stelle Nebeneffekte und Fehler auf. Also müsste man nach jeder kleinen Änderung die gesamte Anwendung manuell testen. Das ist aber so mühsam, undankbar und teuer, dass es in den meisten Fällen unterbleibt.

Es regiert das Prinzip Hoffnung: "Diese kleine Änderung wird schon nichts kaputt gemacht haben." Bei sehr kleinen und unkritischen Softwareprojekten kann dieses Prinzip sogar wirtschaftlich sein.

Es ist aber fatal bei

  • kritischen Projekte, bei denen Fehler schwere Folgen haben
  • großen und komplexen Projekte: Hier kann jede Reparatur eines Fehlers eine Kette von neuen Problemen auslösen, bis der Zustand der Software nicht mehr beherrschbar ist.

Zum Glück gibt es ein Instrument, um diesem Problem zu begegnen: Automatische Tests.

Hoffnung ist gut, Kontrolle ist besser: Automatische Tests

Das wertvollste Qualitäts-Instrument in der Softwareentwicklung sind automatische Regressionstests. Diese Tests werden einmal geschrieben und können dann beliebig oft die Software prüfen, z.B. jede Nacht oder sogar bei jeder kleinen Code-Änderung („Continious Integration“). Sie testen, ob die Anwendung noch genauso funktioniert wie es definiert wurde.

Wenn eine Änderung bestehende Funktionalitäten in Mitleidenschaft gezogen hat, wird das sofort sichtbar. Dann wird der Fehler von den Entwicklern sofort korrigiert, bis wieder alle Tests fehlerfrei durchlaufen.

Die Änderung hat bewirkt, dass ein Test fehlschlägt: der Entwickler weiß nun genau, welche Stelle er korrigieren muss.

Unit-Tests

Die verbreitetste Art automatischer Regressionstests sind Unit-Tests, die jeweils eine „Unit“ (ein einzelnes Programmmodul) testen.

Ein Beispiel: Für eine Funktion, die für eine Bestellmenge einen Rabatt berechnet, definiert man alle wichtigen Fälle:

  • die Bestellmenge ist so groß, dass es den maximalen Rabatt gibt
  • die Bestellmenge ist so klein, dass es keinen Rabatt gibt
  • die Bestellmenge ist 0
  • etc.

Für alle Fälle schreibt man einen Test, der prüft, ob die Funktion den richtigen Rabatt ausrechnet.

Beispiel Unit-Test

Integrationstests

Unit-Tests prüfen isolierte einzelne Komponenten. Abhängigkeiten von anderen Komponenten werden durch den Einsatz von Dummies für diese („Mocks“) ausgeblendet.

Aber oft kommt es vor, dass an sich fehlerfreie Einzelkomponenten im Zusammenspiel doch Probleme machen. Integrationstests testen daher das Zusammenwirken mehrerer Units oder Komponenten.

System- bzw. GUI-Tests

System-Tests schließlich prüfen das Gesamtsystem mit allen beteiligten Komponenten.

Im Falle von Anwendungen mit einer Benutzeroberfläche (Graphical User Interface oder auch "GUI") sind dies GUI-Tests. Sie testen die komplette Anwendung über ihre Benutzeroberfläche.

Diese Tests simulieren einen Benutzer, der die Software bedient, z.B. Buttons anklickt und Eingaben macht. Sie prüfen, ob nach einem Klick das Erwartete geschieht, z.B. sich ein bestimmtes Fenster öffnet und ein bestimmter Wert angezeigt wird.

Sie sind die einzige Sorte von Tests, die sicherstellen kann, dass das Gesamtsystem funktioniert.

Gui-Tests sind anspruchsvoll zu schreiben und zu warten. Nur die wenigsten Software-Häuser bieten diese Maßnahme an. Wir haben viele Jahre Erfahrung mit verschiedenen Gui-Test-Verfahren und -Tools wie Testcomplete und Selenium.

Der "Test first"-Ansatz

Ein besonders weitgehender Test-Ansatz ist "Test first" oder auch „Test Driven Development“ („TDD“).

Hier schreibt man zuerst die Tests und erst dann die eigentliche Funktionalität. D.h. man definiert zuerst das erwartete Ergebnis in allen Details, und kann dann genau überprüfen, ob dieses erreicht wird.

Test First ist nach unserer Erfahrung für bestimmte Projekttypen und Anwendungsfälle sehr gut geeignet, aber nicht für alle. Auch hier kommt es auf Ihre Anforderungen an, ob das Verfahren für Sie Nutzen bringt – das ermitteln wir für Ihr Projekt gemeinsam mit Ihnen.

Weiterer Nutzen automatisierter Tests

Die Tests gewährleisten, dass die Software so funktioniert, wie es definiert wurde – darüber hinaus leisten sie aber noch viel mehr:

Nach oben

Weiterführende Links: