Führung im Test: Durchführung eines Testprojekts

Der klassische Druck auf das Testen

Jeder, der Systeme getestet hat, hat verspätete Lieferung des zu testenden Systems erlebt. Auf nahezu jeder Ebene, von Komponenten bis zu ganzen Systemen, stoßen Entwickler auf Probleme und die Lieferung verzögert sich oder ist unvollständig. In den meisten Fällen, in denen ein Zeitraum für die Durchführung der Tests festgelegt wurde, bleibt die Frist bestehen und das Testen wird "zusammengedrückt". Teams werden so gezwungen, zwischen Qualität und Geschwindigkeit zu wählen. Für Tools, die das Beste aus beiden Welten bieten, werfen Sie einen Blick auf unsere Liste der besten Plattformen für Softwaretests.

JOIN THE COMMUNITY

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Sign up with LinkedIn

Or sign up with email:

X/Twitter

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Teil- und inkrementelle Lieferung

Obwohl das vollständige System nicht für Tests geliefert werden kann, kann eine Teilfunktionalität – also ein Teilsystem – ausgeliefert werden, mit dem Versprechen, dass spätere Releases die restliche Funktionalität enthalten werden. Zu jedem Zeitpunkt wird der Status der Features in einem Release wie folgt sein:

• Wie gefordert abgeschlossen: Diese Features sind testbar – zumindest isoliert betrachtet.
• Unvollständig: Features lassen Funktionalität weg und/oder sind bekanntlich fehlerhaft.
• Fehlend: Für spätere Releases aufgeschoben.

In Bezug auf die verfügbaren Features kann es möglich sein, diese isoliert zu testen. Allerdings könnten sie von Daten abhängig sein, die von anderen, noch nicht verfügbaren Features erzeugt werden. Das kann das Testen erschweren.

Features können zwar verfügbar sein, aber deren Ausgaben können von anderen, noch nicht verfügbaren Features nicht verifiziert werden, daher ist eine Untersuchung der Testdatenbank vor und nach dem Test erforderlich. Es ist nahezu sicher, dass Ihre End-to-End-Tests, die testbare Feature-Ketten erfordern, größtenteils blockiert sind.

In fast allen Belangen ist das Testen auf Systemebene mit Teilsystemen stark eingeschränkt.

Testverteidigung/Verteidigung der Teststrategie

Ihr Team muss dennoch Fortschritte machen, so hartnäckig es auch wird. Ist das System nicht verfügbar oder nur teilweise verfügbar, müssen Sie die Erwartungen managen und Ihren Plan verteidigen. 

Ihr Testplan – im Kleinen wie im Großen – hängt davon ab, dass das System verfügbar ist – das ist eine Annahme –, daher muss Ihr Plan angepasst werden. Sie dokumentieren vielleicht keine formalen Eintrittskriterien, aber die Botschaft ist dieselbe:

Eintrittskriterien sind Planungsannahmen – wenn diese Kriterien nicht erfüllt sind, sind Ihre Annahmen falsch und der Plan muss angepasst werden.

Ob Sie nun auf die Lieferung des Systems warten oder bereits auf ein Teilsystem zugreifen können – Ihnen werden sehr schnell die sinnvollen Aufgaben ausgehen. Dann steht Ihnen ein schwieriges Gespräch mit Ihrem Product Owner oder Projektmanager bevor. Wenn sich der Fertigstellungstermin nicht verschiebt, sind Sie gezwungen, weniger zu testen. Einige Funktionen werden weniger getestet oder ganz vom Test ausgeschlossen.

Der Manager glaubt vielleicht, dass die Zeit später aufgeholt werden kann – in der Praxis ist das jedoch so gut wie nie möglich.

Die durch späte oder teilweise Lieferungen verlorene Testzeit lässt sich nicht durch „mehr Einsatz“ zurückgewinnen.

Warum verzögert sich das Testen? Es gibt viele mögliche Ursachen, die sich jedoch meist in eines der folgenden Muster einordnen lassen:

• Umgebungen können nicht rechtzeitig konfiguriert werden. Die Verantwortlichen haben zu spät begonnen, waren zu beschäftigt oder nicht qualifiziert, eine sinnvolle Testumgebung zu schaffen. Das Verfügbare ist unvollständig, fehlerhaft konfiguriert oder lückenhaft.
• Die Lieferung verzögert sich, weil der Arbeitsaufwand unterschätzt wurde.
• Die Lieferung verzögert sich, weil die Software fehlerhaft, schwer zu testen und zu beheben ist.
• Die Lieferung verzögert sich, weil dem Entwicklungsteam die Fähigkeiten, Erfahrung oder Kompetenz im Geschäftsfeld oder mit den eingesetzten Technologien fehlen.
• Die Lieferung verzögert sich, weil die Entwicklung zu spät begonnen hat.
• Die Lieferung verzögert sich, weil sich die Anforderungen ständig ändern.

Von der obigen Liste ausgenommen sind höhere Gewalt und andere externe Faktoren außerhalb des Einflussbereichs des Projektteams. Wenn der Projektmanager darauf besteht, dass sich weder der Termin noch der Testumfang ändert, stehen Sie vor einer großen Herausforderung. In jedem der oben genannten Fälle sprechen die Ursachen für eine ausgedehntere Testphase – nicht für eine verkürzte.

Wird der Entwicklungsaufwand unterschätzt, gilt das vermutlich auch für den Testaufwand. Ist die Software fehlerhaft, dauert das Testen länger. Fehlen den Entwicklern Kompetenzen, ist das Ergebnis meist qualitativ schwach und der Testaufwand steigt. Haben Entwickler spät begonnen (warum?) und bleibt der Umfang unverändert, weshalb soll dann beim Testen gekürzt werden? Ändern sich die Anforderungen, ist Ihr Testplan vermutlich ohnehin falsch – an einem schlechten Plan festzuhalten, macht das Leben nur schwerer.

Wie viele der häufigen Gründe für Lieferverzögerungen sprechen dafür, weniger zu testen? Keiner. Verteidigen Sie Ihren Plan.

Erfolg und Misserfolg berichten

Den meisten Testern ist klar, dass effektives Testen Neugier, Ausdauer und ein Gespür für Probleme erfordert. Die Hauptmotivation besteht darin, Fehler zu provozieren und genügend Belege zu sammeln, damit diese auf Defekte zurückgeführt und anschließend behoben werden können. 

Auch wenn das Finden (und Beheben) von Fehlern der Produktqualität dient, fühlt es sich beim Melden von Fehlern oft so an, als würde man jemandem schlechte Nachrichten überbringen. Das kann ein Entwickler sein, der einen Fehler gemacht hat und diesen nun beseitigen muss. Oder Sie berichten Stakeholdern, dass eine kritische Funktion nicht korrekt arbeitet und sich das System verzögert.

Niemand gibt gerne schlechte Nachrichten weiter und es ist ganz natürlich, dass man zögert, andere – besonders enge Kollegen – vor den Kopf zu stoßen. Doch das Gefühl, ob eine Nachricht gut oder schlecht ist, sollte dem Überbringer keine Sorge bereiten. 

Fehler sind für jemanden immer schlechte Nachrichten, aber die Aufgabe des Testens ist nicht, darüber zu urteilen. Der Tester ist in mancher Hinsicht einem Journalisten ähnlich, der nach der Wahrheit sucht. Die Geschichte vom Elefantenkind bei Kipling enthält folgende Zeilen:

Ich habe sechs ehrliche Diener:
    (Sie lehrten mich alles, was ich weiß)
Ihre Namen sind Was und Wo und Wann
    Sowie Wie und Warum und Wer.

In ähnlicher Weise, wie ein Journalist eine Nachricht erzählt, berichten Sie die Erkenntnisse, die Sie beim Testen eines Systems gewonnen haben.

Die Wahrheit – die Nachricht – kann gut oder schlecht sein, aber Ihre Verantwortung ist es, sowohl Probleme als auch Erfolge bestmöglich zu erkennen. Sie versuchen herauszufinden, was ein System tut und wie es das tut. 

Am Ende eines Projekts ist das Ziel, mit so wenigen verbleibenden Problemen wie möglich in die Produktion zu gehen. Sie möchten, dass alle Ihre Tests erfolgreich sind, doch der Weg zum Erfolg wird durch Testfehler erschwert, die untersucht und gelöst werden müssen. Taktisch geht es darum, Probleme schnell zu finden, Ihr eigentliches Ziel ist es jedoch, keine Probleme mehr berichten zu müssen. 

Um den Erfolg oder Misserfolg Ihres Testprojekts präzise zu berichten, sollten Sie fortschrittliche Testmanagement-Tools in Betracht ziehen, die umfassende Analysen bieten

Sie müssen wie ein investigativer Journalist agieren – mit kritischem und unabhängigem Geist nach der eigentlichen Geschichte suchen. Wie Kipling schrieb:

Wenn du Erfolg und Niederlage begegnest und beide Hochstapler gleich behandelst …

Dann bewahren Sie einen kühlen Kopf und leisten einen wertvollen Beitrag für Ihr Projekt und die Stakeholder.

Abdeckungserosion

Unabhängig davon, welche Abdeckungsziele zu Beginn der Tests festgelegt werden, gibt es mehrere Faktoren, die dazu führen, dass die tatsächlich erreichte Testabdeckung geringer ausfällt. Erosion ist hierfür der passende Begriff, da er den schrittweisen Rückgang des geplanten Testumfangs und die unausweichliche Erkenntnis widerspiegelt, dass nicht alle geplanten Tests in der verfügbaren Zeit durchgeführt werden können.

Testabdeckungserosion hat schon vor der Testausführung mehrere Ursachen:

• Erstens identifizieren Testpläne die zu adressierenden Risiken und die Herangehensweise zur Bewältigung dieser Risiken. Pläne beruhen meist auf einem Budget für das Testen – was immer ein Kompromiss ist.
• Schlechte, instabile oder unvollständige Systemanforderungen, Designs und Spezifikationen erschweren die Testspezifikation. Die Abdeckung des Systems wird durch fehlende Details eingeschränkt.
• Die späte Verfügbarkeit oder Unzulänglichkeit von Testumgebungen macht bestimmte geplante Tests unpraktisch oder nicht sinnvoll. Größere Integrationstests können oft nicht wie geplant durchgeführt werden, weil nicht alle Schnittstellen oder angebundenen Systeme zur Verfügung gestellt werden können.
• Leistungstests könnten beeinträchtigt sein, weil die Umgebungen nicht in entsprechender Größenordnung vorhanden sind oder die Produktion nicht widerspiegeln.
• Die späte Lieferung der zu testenden Software bedeutet, dass bei gleichbleibenden Deadlines der Testumfang reduziert werden muss.

Erosion der Testabdeckungsreichweite während der Testausführung hat ebenfalls mehrere Ursachen:

• Wenn die Qualität der zu testenden Software beim Eintritt einer Testphase schlecht ist, kann das Testen besonders frustrierend sein. Schon die grundlegendsten Tests könnten fehlschlagen und die gefundenen Fehler so gravierend sein, dass die Entwickler mehr Zeit zur Behebung benötigen als erwartet. Wird das Testen ausgesetzt, weil die Softwarequalität zu schlecht ist, geraten Sie in Verzug. Bleibt die Deadline unverändert, werden einige Tests aus dem Fokus genommen.
• Treten mehr Fehler auf als erwartet, verlängern sich die Korrektur- und Wiederholungsschleifen und es fehlt die Zeit, um alle Tests abzuschließen.
• Wenn schließlich die Zeit abläuft und entschieden wird, dass veröffentlicht wird, obwohl die Tests nicht vollständig abgeschlossen sind, wurden entweder einige Tests im Plan nicht erreicht oder verbleibende Fehler blockieren deren Fertigstellung. Wenn das Go-live-Datum bleibt, erleben Sie das klassische "Zusammenquetschen" des Testens, wie oben beschrieben.

Mit der Erosion der Testabdeckung umzugehen, gehört zu den Herausforderungen, mit denen Tester in jedem Projekt konfrontiert sind. Selten läuft alles glatt, und die Reduzierung der Testzeit (und damit der Abdeckung) ist normalerweise die einzige Möglichkeit, das Projekt im Zeitplan zu halten.

Es ist nicht falsch, die Menge der Tests zu reduzieren – falsch wäre nur, dies willkürlich zu tun. Daher muss bei der Auswahl der zu streichenden Tests die Auswirkung auf Ihre Testziele und zu adressierende Risiken überprüft werden. Möglicherweise führen Sie dazu unangenehme Gespräche mit Stakeholdern.

Wo die Auswirkungen erheblich sind, müssen Sie möglicherweise ein Treffen zwischen denen, die Kürzungen fordern (typischerweise das Projektmanagement), und denen, deren Interessen von den Einschnitten betroffen sein könnten (die Stakeholder), initiieren. Ihre Aufgabe ist es, den Status bezüglich abgeschlossenen Tests, den bekannten Stand des getesteten Systems, fehlgeschlagener und/oder blockierender Tests sowie dem verbleibenden Testaufwand aufzuzeigen.

Ihre Pläne und Modelle legen den ursprünglichen Testumfang dar und sind entscheidend, um Stakeholder und Management über Lücken und verbleibende Risiken zu informieren und die Entscheidung, weiter zu testen oder das Testen zu beenden, zu unterstützen.

Incident Management

Sobald das Projekt in die Phasen Systemtest und Abnahmetest übergeht, wird es weitgehend von den Incidents während der Testausführung bestimmt. Incidents lösen Aktivitäten im verbleibenden Teil des Projekts aus, und die Statistik solcher Vorfälle kann manchmal gute Einblicke in den Projektstatus liefern. Wenn Sie Incidents kategorisieren, sollten Sie direkt daran denken, wie diese Informationen später genutzt werden.

Ein Incident ist ein ungeplantes Ereignis während des Testens, das den erfolgreichen Abschluss des Testens, die Abnahmeentscheidung oder die Notwendigkeit anderer Maßnahmen beeinflussen kann.

Für diese ungeplanten Ereignisse verwenden wir den neutralen Begriff Incident. Diese Ereignisse werden jedoch oft auch mit anderen Begriffen bezeichnet – manche neutraler, manche weniger. 

Tests, die fehlschlagen, werden manchmal als Beobachtungen, Anomalien oder Issues bezeichnet – neutrale Begriffe ohne Festlegung auf eine Ursache. Aber manchmal werden auch Problembeschreibungen wie Bug, Defect oder Fault benutzt – was einen Fehler im System voraussetzt. Dies kann jedoch eine vorschnelle Schlussfolgerung sein und zu Fehleinschätzungen führen.

Wir empfehlen, die Begriffe Bug, Defect oder Fault für die Diagnoseergebnisse von Fehlern im Aufbau des zu testenden Systems zu reservieren, die in der Regel Nacharbeiten für das Entwicklerteam nach sich ziehen.

Incidents treten in zwei Formen auf:

1. Fehler des Systems: Das System verhält sich in einem Test nicht wie erwartet, d.h. es scheitert in irgendeiner Form oder erfüllt eine Anforderung offensichtlich nicht.
2. Unterbrechung oder Beeinträchtigung des Testens oder der Tests: Ein Ereignis, das die Fähigkeit der Tester beeinträchtigt, ihre Aufgaben zu erledigen – z. B. Ausfall oder Verlust der Testumgebung, von Daten, Schnittstellen oder unterstützenden, integrierten Systemen oder Diensten, oder ein anderer externer Einfluss.

Fehler des Systems

Diese Vorfälle sind oft von unmittelbarster Bedeutung, weil sie das Vertrauen in die Qualität des Systems untergraben. 

Unterbrechungen und beeinträchtigte Tests

Einige Organisationen betrachten diese Vorfälle überhaupt nicht als Vorfälle – Unterbrechungen gehören zum rauen Alltag von Projekten, die ihrem Abschluss entgegengehen. Beeinträchtigte Tests, bei denen die Umgebung oder das Testsetup falsch ist, werden möglicherweise dem Testteam angelastet (für das Setup oder zumindest dafür, dass das Setup vor dem Testen nicht überprüft wurde).

In beiden Fällen wird der Fortschritt der Tests beeinträchtigt, und wenn Sie den Prozess managen, sind Sie dafür verantwortlich, Verzögerungen zu erklären. Aus diesem Grund sollten Sie entweder diese Ereignisse als Vorfälle erfassen oder das Team darum bitten, ein Testprotokoll zu führen und Ausfälle der Umgebung, Konfigurationsprobleme oder das Fehlen geeigneter Softwareversionen für die Tests zu dokumentieren. Tun Sie das nicht, wird es schwer, Verzögerungen glaubhaft zu begründen – und das kann negativ auf Sie und Ihr Team zurückfallen.

Vorfälle dokumentieren oder nicht?

Mit dem Aufkommen agiler und kontinuierlicher Entwicklungsansätze wird die traditionelle Sichtweise des Störfallmanagements in Frage gestellt. In klassischen Projekten werden Vorfälle als potenzielle Arbeitspakete für Entwickler behandelt, die je nach Schweregrad und/oder Dringlichkeit genehmigt werden. 

Hierfür gibt es einen formellen, oft bürokratischen Prozess, bei dem Vorfälle geprüft, priorisiert und vom Entwicklungs- (oder einem anderen) Team bearbeitet werden. Es kommen dabei häufig ausgefeilte Incident-Management-Tools zum Einsatz.

In kleineren, agilen Teams ist die Beziehung zwischen Testern und Entwicklern enger. Das Team als Ganzes trifft sich vielleicht täglich, um größere Vorfälle zu besprechen, aber meistens werden Fehler informell entdeckt, analysiert, behoben und erneut getestet, ohne dass ein Vorfall dokumentiert oder andere Teammitglieder, Geschäfts- oder IT-Ansprechpartner einbezogen werden müssen. Schwerwiegendere Fehler werden besprochen und fließen in die Arbeit an einer User Story ein oder werden in spezielle Bugfix-Iterationen oder Sprints gebündelt.

Wir haben in einem früheren Artikel den Zweck und die Notwendigkeit von Dokumentation diskutiert. Diese Überlegungen sind auch auf Vorfälle anwendbar. Das Team muss entscheiden, ob ein Vorfallstool und zugehöriger Prozess erforderlich sind, ob es hilfreich für das Team ist und/oder ob dies von externen Personen verlangt wird.

Größere Teams verlassen sich aus drei Gründen auf Prozesse und Tools zum Management von Vorfällen: 

1. Damit Vorfälle nicht in Vergessenheit geraten
2. Damit schwerwiegende Probleme von Stakeholdern und Projektleitung überprüft werden 
3. Um Metriken zu erfassen, die während und nach dem Projekt nützlich sein können.

Dringlichkeit und Schweregrad trennen

Unabhängig davon, welchen Prozess Sie für das Störfallmanagement wählen, empfehlen wir, allen Vorfällen sowohl eine Prioritäts- als auch eine Schweregrad-Klassifizierung zuzuweisen.

• Die Priorität wird aus Testsicht zugewiesen und beeinflusst, wann ein Vorfall behoben werden soll. Der Tester sollte entscheiden, ob ein Vorfall hoch- oder niedrigpriorisiert ist (bzw. einen dazwischenliegenden Grad, sofern möglich). Die Priorität zeigt die Dringlichkeit dieses Fehlers für die Tester an und basiert auf den Auswirkungen, die der Testfehler auf die weiteren Tests hat.
• Der Schweregrad wird aus Nutzersicht vergeben und zeigt die Akzeptierbarkeit oder Unakzeptierbarkeit eines (meist) Fehlers an. Die Endanwender oder deren Management sollten den Schweregrad festlegen oder die anfängliche Bewertung der Tester gegebenenfalls überschreiben. Der Schweregrad spiegelt die Auswirkungen dieses Fehlers auf das Unternehmen wider, falls dieser Fehler vor der Auslieferung nicht behoben wird. Normalerweise macht ein schwerwiegender Fehler das System unakzeptabel. Ist ein Fehler von geringer Schwere, so gilt er als zu trivial, um ihn vor dem Go-live zu beheben, kann jedoch in einer späteren Version korrigiert werden.

Wenn ein Vorfall die Tests stoppt und sich die Tests auf dem kritischen Pfad befinden, stoppt das gesamte Projekt.

Ein hochpriorisierter Vorfall stoppt alle Tests und in der Regel das gesamte Projekt.

Wichtig bei Vorfall-Klassifizierungsschemata ist, dass nicht jeder dringende Vorfall schwerwiegend ist und nicht jeder schwerwiegende Vorfall dringend.

Das Endspiel managen

Wir bezeichnen die letzten Phasen unseres Testprozesses als „Endspiel“, weil die Steuerung der Testaktivitäten in diesen letzten, möglicherweise hektischen und stressigen Tagen eine andere Disziplin erfordert als die vorhergehende, scheinbar viel entspanntere Phase der Testplanung.

Denken Sie daran: Ziel des Testens ist es, Stakeholdern Informationen zu liefern, die sie zu einer Entscheidung befähigen – Akzeptieren, Beheben, Ablehnen, das Projekt erweitern oder es komplett aufgeben. 

Wenn Sie ein gemeinsames Verständnis der für das Testen genutzten Modelle haben, ist es einfacher zu erklären, was „funktioniert“ (im Sinne des Modells), wo Dinge nicht funktionieren und welche Risiken diese Ausfälle bergen. Es ist Sache der Stakeholder, diese Informationen für ihre Entscheidungen heranzuziehen – unterstützt durch Sie.

Einer der Vorteile eines risikobasierten Testansatzes ist, dass wir – sollte das Testen in einem späten Projektstadium eingeschränkt werden – das verbleibende Risiko heranziehen können, um weitere Tests zu argumentieren oder zusätzliche Tests durchzusetzen. 

Wenn das Management darauf besteht, das Testen zu kürzen, sollten Tester einfach die Risiken aufzeigen, die dabei „eingegangen“ werden. Das ist deutlich einfacher, wenn frühzeitig eine Risikobewertung durchgeführt wurde, die die Testaktivitäten steuert und während des gesamten Projekts überwacht wird. Wenn das Management kontinuierlich über die verbleibenden Risiken informiert ist, ist es weniger wahrscheinlich, dass das Testen überhaupt gekürzt wird.

Das war’s, viel Erfolg bei euren Tests!

Abonnieren Sie den The QA Lead Newsletter, um benachrichtigt zu werden, wenn neue Teile der Serie erscheinen. Diese Beiträge sind Auszüge aus Pauls Leadership in Test Kurs, den wir sehr empfehlen, um noch tiefer in dieses und andere Themen einzusteigen. Wenn Sie teilnehmen möchten, nutzen Sie unseren exklusiven Gutscheincode QALEADOFFER und sparen Sie $60 auf den gesamten Kurspreis!