Wahrlich, eine hervorragende Frage. Hier werde ich einige Schritte aus meiner persönlichen Erfahrung erklären.

  1. Wir brauchen dafür eine gute Teamarbeit.
  2. Hier möchte ich nur den Begriff “Alle Testfälle/Suite ausführen” klären. Wir müssen die Testfälle in vier Quadranten wie unten beschrieben priorisieren.Using a Priority Quadrant
  3. Führt am besten viele explorative Tests anstelle eines vollständig skriptbasierten Ansatzes durch.
  4. Versucht, alle geschäftskritischen Abläufe zuerst abzudecken.
  5. Versucht, alle früheren Produktionsfehler zu testen und im aktuellen Regressionszyklus abzudecken.
  6. Gebt euch etwas Zeit für die richtige Planung, bevor ihr mit einem sequenziellen Ansatz beginnen. Welche Art von Modulen und Testfällen könnt ihr zuerst eliminieren, und entfernt diese zuerst, sodass ihr nun eine Liste aller wichtigen Aufgaben habt. Verwendet Serneut den Prioritätsquadranten [Schritt-2].
  7. Und zu guter Letzt. Wieder brauchen wir Schritt-1

Im Grunde haben ihr nie angemessen Zeit und Ressourcen, um alles zu testen. Eure Testfälle sind bereits eine Teilmenge dieses unendlichen “Alles”.

Was könnt also tun? Prioritäten setzen. Eine gängige Heuristik ist RCRCRC:

  • Neu: neue Funktionen
  • Kern: wesentliche Funktionen Ihres Produkts
  • Risiko: Risiko ist definiert als die Wahrscheinlichkeit des Auftretens (wie wahrscheinlich ist es, dass es passiert) multipliziert mit der Auswirkung (wie hoch ist der Schaden, in verlorenen Geldstunden oder irgendetwas Relevantem).
  • Konfigurationsempfindlich: dies repräsentiert sowohl die interne Konfiguration als auch die Umgebungseinstellungen, insbesondere den Gerätetyp oder das Betriebssystem.
  • Repariert: Kürzlich reparierte Fehler stehen für nicht getestete Bereiche
  • Chronisch: einige Bereiche sind als anfällig bekannt. Dies kann auf die Komplexität, das Niveau der Entwickler oder auf einen Bereich zurückzuführen sein, der zwischen den Verantwortlichkeiten liegt.

Nehmt eure Liste der Testfälle und stuft sie für jeden Punkt ein, sagen wir 1 – 5 (verwendet keine Null, da dies den nächsten Schritt beeinträchtigen würde), multipliziert dann die sechsstellige Zahl und sortiert nach dem Ergebnis. So erhaltet ihr eine erste Einschätzung, was zuerst getestet werden sollte und warum.

Weitere Punkte:

Priorisiert die Testfälle

In meinen früheren Projekten haben wir die Testfälle nach Prioritäten geordnet. Wir haben HP ALM verwendet und dort hatten wir auch einige Testfälle und es war unmöglich, sie alle auszuführen. Also haben wir die Testfälle einfach priorisiert, z.B. Kritisch, Sehr Hoch, Hoch, Mittel, Niedrig – so wie man es auch bei Fehlern machen würde. Alle erstellten Testfälle basierten auf der ebenfalls von uns erstellten Veröffentlichungsrichtlinie. Dies half uns, uns auf die wichtigsten Testfälle zu konzentrieren.

Bezieht andere in den Testumfang ein, z. B. Product Owner, und übertragen ihnen einige Testfälle.

Bezieht andere in das Testteam ein. Testen bedeutet nicht, dass ihr nur allein mit euren Testkollegen testet. Es bedeutet, dass ihr auch andere Teammitglieder einbeziehen könnt. In unserem Projekt haben wir daher auch den Product Owner in die Tests einbezogen. Und zwar nicht erst am Ende (z. B. wenn die Bereitstellung erfolgt ist und das UAT über die Fachabteilung und den Product Owner durchgeführt werden sollte). In Janet Gregorys Buch habe ich den Hinweis gefunden, dass UAT meist erst nach dem Deployment durchgeführt wird und dies nicht bedeutet, dass man es dem Endspiel überlassen sollte (Janet Gregory “More Agile Testing” Seite 202). Wenn man ein Produkt testet, kann man natürlich auch andere Stakeholder einbeziehen, um ein Produkt zu testen. In unserem Fall haben unsere Product Owner geholfen, einige Testfälle zu testen! Übrigens könnt ihr auch die UX-Abteilung bitten, euch zu unterstützen. Wir haben auch unsere UX-Abteilung gebeten, uns bei der Durchführung einiger Testfälle zu unterstützen, und wir haben auch von ihnen wertvolles Feedback erhalten.

Organisiert eine Art Mob-Testing und agiert als Testkoordinator, der euch Testfälle zuwirft!

Ihr könnt auch versuchen, eine Mob-Testing-Sitzung durchzuführen. Gebt ihnen einfach einige Testfälle (die leicht verständlich sind) und einige Anweisungen (und bereitet z.B. Testdaten vor) und lasst sie die Testfälle einfach ausführen! Wir haben dies getan, als wir einige Beteiligte aus anderen Abteilungen eingeladen haben, um uns zu unterstützen! Das hat funktioniert und der Input war sehr hilfreich für uns (weil wir auch Feedback für neue Änderungswünsche bekamen). Das Gute daran war, dass wir nur einen unserer Testanalysten dorthin schickten, der für vier bis fünf Zweiergruppen verantwortlich war. Irgendwie ist das wie ein Beschleuniger, um mit den Testfällen voranzukommen.

Bittet die Fachabteilung um Unterstützung

Wir haben auch die Fachabteilung um Unterstützung gebeten. Normalerweise wird die Fachabteilung nur tätig, wenn das UAT durchgeführt werden soll. Wir baten sie jedoch um Unterstützung und begründeten dies damit, dass die Hilfe wertvoll wäre, um ein (test-)stabiles Produkt zu liefern.

Verwendung eines Protokollierungstools für Sondierungstests

Wir haben auch den Zeitaufwand für die Erstellung von Testfällen reduziert, als wir uns für den Einsatz eines Capture-Replay-Tools entschieden haben. In unserem Fall war es tricentis/quasymphony. Während der Testdurchführung erstellt dieses Tool Testfälle und während dieser Zeit haben wir eine Art exploratives Testen durchgeführt. Das heißt, Ausführung und Erstellung von Testfällen. Dadurch wurde die Zeit für die Erstellung konkreter Testfälle etwas verkürzt.

Ihr seht, es gibt eine Menge Ideen. Aber die wichtigste ist, dass Testen ein Ansatz für das ganze Team ist! Ihr könnt also alle relevanten Beteiligten zur Unterstützung einladen – und unserer Erfahrung nach waren die meisten bereit, uns zu unterstützen.