DevOps-Lexikon: Automatisiertes Testen

Das Testen von Software ist für viele Menschen ein Buch mit sieben Siegeln, und agiles Testen und automatisiertes Testen erst recht. Ich bin da keine Ausnahme. Es ist ein Spezialistenthema! Gut, dass wir sie haben.

Trotzdem kann ich in diesem Post meine Erfahrungen mit einigen Testern mit Ihnen teilen.

Heute wird nach folgendem Schema getestet:

  • Die meisten Investitionen fliessen in manuelle und Integrationstests
  • Fehler finden sich spät in der Testreihe
  • Langsamer ausgeführte automatisierte Tests werden zuerst ausgeführt

Martin Fowler nennt dies die nicht-ideale Testpyramide. Hingegen die ideale Testpyramide arbeitet so:

  • Die meisten unserer Fehler werden so früh wie möglich gefunden
  • Schnellere Ausführung automatisierter Tests vor langsameren automatisierten Tests
  • Alle Fehler sollten mit der schnellsten Testkategorie möglichst gefunden werden
Automatisiertes Testen
vgl. Gene Kim u.a., Das DevOps Handbuch

Fehler so früh wie möglich durch automatisiertes Testen abfangen

Das Ziel unserer automatisierten Testsammlung ist es, Fehler so früh wie möglich zu finden. Aus diesem Grund führen wir schnellere automatisierte Tests (z. b. Komponententests) vor langsamer ausgeführten Tests (z. b. Akzeptanz- und Integrationstests) durch, die beide vor jedem manuellen Test ausgeführt werden.

Daraus ergibt sich, dass alle Fehler mit der schnellsten Testkategorie gefunden werden.

Daraus ergibt sich aber Weiteres: Wenn wir z.B. einen Fehler mit einem Akzeptanz- oder Integrationstest feststellen, sollten wir einen Komponententest erstellen, der den Fehler schneller, früher und billiger finden kann.

Sie sehen, automatisiertes Testen spart Zeit und steigert die Qualität Ihrer Software.

1 Comments

  1. Anonym

    Antworten

    Langsamer ausgeführte automatisierte Tests werden zuerst ausgeführt – langsamer trifft es imho weniger, viel mehr unspezifische Tests. Wenn durch die Bedienung der GUI etwas kracht, kann der Fehler im gesamten darunter liegenden Softwarekonstrukt liegen, etwa so, als ob das Auto nicht mehr anspricht. Werden zuerst die Units getestet, dann ist der Ursachenbereich im Fehlerfall bereits stark beschränkt (diese Unit, bzw. alles, auf was diese zugreift).

    Im Prinzip stellt die “Agile Testpyramide” nichts weiter dar, als die des V-Modells und ist damit gar nicht mal so “neu”.

Leave Comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.