Artikel versenden

Testdefinition für automatisierte Softwaretests




 

// /

Ich bin in der Vergangenheit immer wieder auf ganz unterschiedliche Herausforderungen in der QS gestoßen, wenn es darum ging, die Entwicklung und Pflege von Softwaretests optimal zu gestalten, vor allem, wenn die Testdurchführung automatisiert werden sollte und somit eine enge Abstimmung zwischen Testdefinition und Programmierung nötig ist. Hier fehlt es häufig an klaren Vorgaben, einer klaren „Marschroute“, die das Management deshalb nicht in der benötigten Form liefern kann, da die Lösung vieler Probleme Spezialisten-Know-How in einem hohen Detailgrad verlangt.

Eine besondere Würze bekommt die Situation dann, wenn die Testdefinition durch einen Benutzervertreter (beim Kunden) geschieht, die Automatisierung aber, wie die Entwicklung der Software, beim Lieferanten erfolgt, ein Fall, in dem die „Befehlskette“ verkehrt wird, da der Lieferant auf einmal dem Kunden Anforderungen definiert (an Testdefinitionen, die Anforderungen für die Automatisierung erfüllen müssen).

Einführung

Zusammenfassend lassen sich viele Probleme auf folgende „Grundprinzipien“ zurückführen:

  • Das Software-System wird „von oben“ betrachtet, um nur ja nichts zu vergessen. Vor allem wenn die Anforderung nach einer möglichst hohen Testabdeckung (einem möglichst hohen Grad an Automatisierung der Testdurchführung) zu erfüllen ist, sieht man oft den Wald vor lauter Bäumen nicht und verrennt sich folglich dann doch in Details (oft denen, die die ersten Fragen und Probleme aufwerfen). Man schwankt ohne klaren Fokus zwischen unterschiedlichen Perspektiven und Detailebenen, eine Situation, die ein Kollege einmal mit dem schönen Vergleich beschrieb, es würde versucht, ein Pferd von der Seite aufzuzäumen.
  • Bei der Testdefinition ist nicht ohne weiteres klar, welche Teile der Tests auf welche Art automatisiert werden können. Je mehr Methoden hier zur Auswahl stehen (User- / Browser-Simulation, UNIT-Tests, Lasttests etc.), desto schwieriger ist es, diese technischen Mittel bei ihrer Testdefinition zu berücksichtigen und ihre Anforderungen zu erfüllen.
  • Die Wartbarkeit von Testdefinitionen wird nicht ausreichend geplant. Dies führt spätestens dann zu Schwierigkeiten, wenn sich Softwareteile ändern und die Frage beantwortet werden muss, welche Testfälle und Automatisierung davon betroffen sind.

Die daraus entstehenden Probleme sind vielfältig und führen sehr häufig zu Unmut, zur Verschwendung von Ressourcen und nicht zuletzt zu unterschiedlichen Vorstellungen davon, was die QS insgesamt genau leistet. Gravierend wird dies, wenn Fehler in Bereichen auftreten, die „angeblich“ automatisiert getestet werden, und die Frage: „Wie hoch ist denn unsere Testabdeckung genau?“ von drei Personen auf fünf verschiedene Arten beantwortet wird. Wenn man genauer hinsieht, ist eine Antwort manchmal auch nicht ganz trivial, wie ein Beispiel aus der Realität zeigt:

Beispiel

Die komplexen Eingabe- und Auswahlmöglichkeiten einer erweiterten Suche wurden umfassend durch eine User- / Browsersimulation (Selenium) automatisiert getestet, woraufhin der damit beauftragte Mitarbeiter (wie sich herausstellte: vorschnell) vermerkt hat, die Tests dieser Softwarekomponente seien automatisiert. Als nun Fehler in den Suchergebnissen dieser erweiterten Suche auftauchten (die Aktualisierung des Suchindex funktionierte nicht zuverlässig) war der Kunde verständlicherweise verärgert, da er davon ausging, dass die korrekte Arbeitsweise der Suche durch Testautomatisierung gewährleistet ist (die erweiterte Suche war ja laut Entwicklernotiz „abgedeckt“, ein Fall, der in der Realität beinahe zu einem immensen Vertrauensverlust geführt hat!). Nach Rückfrage des zuständigen Projektmanagers kam das Feedback, dass man durch die Simulation eines Benutzers die Korrektheit der Ergebnisse unmöglich prüfen könne, dies sei „doch klar“, und die Aktennotiz „selbstverständlich“ mit gewissen Einschränkungen zu verstehen.

Nachdem anschließend für die entsprechenden Schnittstellen der Suchindizierung auch UNIT-Tests geschrieben wurden, schien man endgültig auf der sicheren Seite zu sein, bis einige Zeit später die Frage auftauchte, ob die geforderten drei Sekunden Response-Zeit denn nach den Bugfixes auch bei maximaler Systemnutzung noch eingehalten werden. Diese Qualitätsanforderung kann auch durch UNIT-Tests nicht ohne weiteres geprüft werden, da eine maximale Systemnutzung normalerweise nur durch (nicht vorhandene) Lasttests simuliert werden kann, was ja auch (irgendwie) „klar“ ist. Man hatte also weiterhin eine offene Flanke, trotz vermeintlich „doppelter“ Testabdeckung.

Fazit

Wie man sieht gibt es auf dem Weg zur effektiven Erstellung und Pflege von Testdefinitionen und ihrer Automatisierung einige Stolpersteine. Aus diesem Grund habe ich die unterschiedlichen Regeln und Richtlinien, die sich im Laufe der Zeit angesammelt haben, in einem „Leitfaden zur Testdefinition für automatisierte Softwaretests“ zusammengefasst, den ich in der folgenden Artikelserie vorstellen möchte. Er richtet sich an folgende „Rollen“ in einem Unternehmen:

  • QS-Mitarbeiter, die mit dem Schreiben von Testfällen vertraut sind,
  • Entwickler, die auf Basis dieser Testfälle automatisierte Softwaretests programmieren und
  • an ein interessiertes Management, das die Prozesse in der QS optimieren und die Schaffung validierbarer und wartbarer Ergebnisse unterstützen möchte.

Im Fokus: User- / Browsersimulation

Besondere Beachtung findet dabei die Testautomatisierung im Bereich User- / Browsersimulation (z.B. auf Basis von Selenium), da dieser Bereich aus folgenden Gründen im Kontext „Testdefinition“ besonders spannend ist:

  • Die Simulation eines echten Benutzers (seiner Mausklicks, Tastatureingaben etc.) stellt besonders hohe Anforderungen an die Testdefinition, da verständlicherweise alle Aktionen und erwarteten Ergebnisse möglichst präzise definiert sein sollten.
  • Erfahrungsgemäß können auch Nicht-Entwickler (Tester oder sonstige QS-Mitarbeiter) nach kurzer Einarbeitung automatisierte Softwaretests erstellen, was die Abhängigkeit von Entwicklerressourcen in dem Bereich stark reduziert. Die hierfür nötigen Voraussetzungen können auf Basis des „Leitfadens“ geschaffen werden.

Aus diesen Gründen wird im Folgenden auf die Erstellung und Verwaltung von Selenium-Testcases und –testsuites detaillierter eingegangen als z.B. auf UNIT-Tests, deren Programmierung in einem viel engeren Zusammenhang mit der Softwareentwicklung selbst steht und daher durch dort etablierte Prozesse mit gesteuert werden kann (Stichwort Test Driven Developement, eXtreme Programming etc.). Dies bedeutet natürlich nicht, dass der Leitfaden beim Einsatz von anderer Techniken zur User- / Browsersimulation nicht auch sinnvoll ist.

Quelle Foto: © fotomek – Fotolia.com

| Keine Kommentare

 
Top | Impressum | Datenschutz