Führung im Test: Durchführung eines Testprojekts

Der klassische Zeitdruck beim Testen

Jeder, der Systeme getestet hat, kennt verspätete Lieferungen des zu testenden Systems. Auf nahezu allen Ebenen, von Komponenten bis zu ganzen Systemen, stoßen Entwickler auf Probleme – die Lieferung verzögert sich oder ist unvollständig. In den meisten Fällen, in denen eine festgelegte Zeitspanne fürs Testen vorgesehen ist, verschiebt sich die Deadline jedoch nicht und das Testen wird eingeengt. Teams sind so gezwungen, zwischen Qualität und Geschwindigkeit zu wählen. Wenn Sie Tools suchen, die das Beste aus beiden Welten bieten, sehen Sie sich unsere Liste der besten Software-Testplattformen an.

WERDE TEIL DER COMMUNITY

Bereichern Sie Ihren Posteingang mit mehr Führungserkenntnissen aus der Tech-Welt für bessere Software und Systeme.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Name*

First name Last name

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Business email*

Create Password*

This field is hidden when viewing the form

LinkedIn profile

This field is hidden when viewing the form

Company's AI adoption maturity

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

Teil- und schrittweise Lieferung

Obwohl das gesamte System nicht für Tests bereitgestellt werden kann, kann ein Teil der Funktionalität – ein Teilsystem – geliefert werden, mit dem Versprechen, dass spätere Releases die verbleibende Funktionalität enthalten. Zu jedem Zeitpunkt gilt für die Features in einem Release der folgende Status:

• Fertiggestellt wie gefordert: Diese Funktionen sind testbar – zumindest isoliert betrachtet.
• Unvollständig: Funktionen fehlen teilweise oder sind als fehlerhaft bekannt.
• Nicht vorhanden: Auf spätere Releases verschoben.

In Bezug auf die verfügbaren Features kann es möglich sein, diese isoliert zu testen. Allerdings könnten diese von Daten abhängen, die durch noch nicht verfügbare Features erzeugt werden, was das Testen erschwert.

Funktionen könnten verfügbar sein, aber deren Ergebnisse lassen sich nicht durch andere, noch fehlende Features verifizieren. Daher ist eine Überprüfung der Testdatenbank vor und nach den Tests erforderlich. Es ist fast sicher, dass Ihre End-to-End-Tests, die ganze Verkettungen von Features benötigen, größtenteils blockiert sind.

In praktisch jeder Hinsicht ist das systemübergreifende Testen von Teilsystemen stark eingeschränkt.

Testen verteidigen

Ihr Team muss dennoch vorankommen, und sei es noch so mühselig. Wenn das System nicht oder nur teilweise zur Verfügung steht, müssen Sie Erwartungen steuern und Ihren Plan verteidigen. 

Ihr Testplan, ob im Kleinen oder im Großen, hängt davon ab, dass das System verfügbar ist – das ist eine Annahme – also muss Ihr Plan angepasst werden. Vielleicht dokumentieren Sie keine formalen Einstiegskriterien, aber die Botschaft bleibt die gleiche:

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

Ob Sie nun auf die Bereitstellung des Systems warten oder Zugang zu einem Teilsystem haben – Ihnen werden sehr schnell die sinnvollen Aufgaben ausgehen. Dann steht Ihnen ein schwieriges Gespräch mit Ihrem Product Owner oder Projektmanager bevor. Wenn der Fertigstellungstermin nicht verschoben wird, sind Sie gezwungen, weniger zu testen. Manche Funktionen werden weniger getestet oder komplett aus dem Testumfang herausgenommen.

Der Manager glaubt möglicherweise, dass Sie die verlorene Zeit später wieder aufholen können, aber das ist in der Praxis so gut wie nie machbar.

Die Testzeit, die durch verspätete oder unvollständige Lieferungen verloren geht, kann nicht durch „härteres Arbeiten“ wieder aufgeholt werden.

Warum verzögert sich das Testen? Es gibt viele mögliche Ursachen, aber sie folgen meist einem dieser Muster:

• Testumgebungen können nicht rechtzeitig konfiguriert werden. Die Leute haben zu spät angefangen, waren zu beschäftigt oder nicht qualifiziert, eine brauchbare Testumgebung zu erstellen. Was zur Verfügung steht, ist nur teilweise vorhanden, falsch konfiguriert oder unvollständig.
• Die Lieferung verzögert sich, weil der Arbeitsaufwand unterschätzt wurde.
• Die Lieferung verzögert sich, weil die Software fehlerhaft, schwierig zu testen und zu beheben ist.
• Die Lieferung verzögert sich, weil dem Entwicklungsteam die nötigen Fähigkeiten, Erfahrungen oder Kompetenzen im Geschäftsbereich oder in den verwendeten Technologien fehlen.
• Die Lieferung verzögert sich, weil die Entwicklung zu spät begonnen hat.
• Die Lieferung verzögert sich, weil die Anforderungen sich ständig ändern.

Von der obigen Liste ausgenommen sind höhere Gewalt und andere externe Faktoren, die außerhalb der Kontrolle des Projektteams liegen. Wenn der Projektleiter darauf besteht, dass der Termin für das Testen nicht geändert wird und auch der Testumfang fixiert bleibt, stehen Sie vor einer großen Herausforderung. In allen oben genannten Fällen sprechen die Ursachen für eine verspätete Lieferung dafür, mehr statt weniger zu testen.

Wenn der Entwicklungsaufwand unterschätzt wurde, dann wahrscheinlich auch der Testaufwand. Wenn die Software fehlerhaft ist, braucht das Testen länger. Wenn den Entwicklern Fähigkeiten fehlen, wird die Software vermutlich schwach und schwerer zu testen sein. Wenn Entwickler zu spät begonnen haben (warum?), aber der Umfang gleich bleibt, warum sollte dann beim Testen gespart werden? Wenn sich Anforderungen ändern, ist Ihr Plan vermutlich ohnehin falsch – mit einem schlechten Plan weiterzuarbeiten, macht das Leben nur schwerer.

Wie viele der häufigen Ursachen für verspätete Lieferung deuten darauf hin, dass weniger getestet werden sollte? Keine davon. Verteidigen Sie Ihren Plan.

Erfolg und Misserfolg berichten

Die meisten Tester wissen, dass effektives Testen Neugierde, Ausdauer und einen Riecher für Probleme erfordert. Die wichtigste Motivation ist, Fehler zu provozieren und genügend Beweise zu sammeln, damit diese Fehler auf Mängel zurückgeführt und anschließend behoben werden können. 

Auch wenn das Finden (und Beheben) von Fehlern gut für die Produktqualität ist, fühlt es sich beim Kommunizieren von Fehlern oft so an, als würde man jemandem schlechte Nachrichten überbringen. Das kann zum Beispiel ein Entwickler sein, der irgendwo einen Fehler gemacht hat und diesen nun beheben muss, oder Sie berichten Stakeholdern, dass eine kritische Funktionalität nicht korrekt funktioniert und sich die Auslieferung verzögert.

Niemand gibt gerne schlechte Nachrichten weiter und es ist ganz natürlich, davor zurückzuschrecken, andere – insbesondere enge Kollegen – zu verärgern. Aber ob Ihre Nachricht als gut oder schlecht empfunden wird, sollte Sie als Überbringer nicht belasten. 

Fehler sind für irgendjemanden immer schlechte Nachrichten, aber die Aufgabe des Testens ist es nicht, das zu bewerten. In gewisser Weise ähnelt der Tester einem Journalisten, der nach der Wahrheit sucht. Die Geschichte "Das Elefantenkind" von Kipling enthält folgende Zeilen:

Ich habe sechs ehrliche Diener:
    (Sie lehrten mich alles, was ich weiß)
Sie heißen Was und Wo und Wann
    Und Wie und Warum und Wer.

Wie ein Journalist eine Nachrichtenstory erzählt, berichten auch Sie darüber, was Sie beim Testen eines Systems herausgefunden haben.

Die Wahrheit – die Nachricht – kann positiv oder negativ sein, aber Ihre Verantwortung ist es einfach, sowohl Probleme als auch Erfolge bestmöglich zu entdecken. Sie versuchen herauszufinden, was ein System tut und wie es dies umsetzt. 

Am Ende eines Projekts besteht das Ziel darin, möglichst wenige ungelöste Probleme in die Produktion zu übergeben. Sie möchten, dass alle Ihre Tests erfolgreich verlaufen, doch der Weg dahin ist oft durch fehlgeschlagene Tests erschwert, die untersucht und behoben werden müssen. Ihr taktisches Ziel ist es, Probleme schnell zu finden, doch das eigentliche Ziel ist es, keine Probleme mehr zu berichten zu haben. 

Um den Erfolg oder Misserfolg Ihres Testprojekts präzise zu dokumentieren, empfiehlt sich die Integration von fortschrittlichen Testmanagement-Tools, die umfassende Analysen bieten.

Sie müssen sich ähnlich wie ein investigativer Journalist verhalten – immer auf der Suche nach der wahren Geschichte, mit einem kritischen und unabhängigen Blick. Wie Kipling schrieb:

Wenn du mit Triumph und Katastrophe umgehen kannst und beide Hochstapler gleich behandelst …

Dann behalten Sie einen klaren Kopf und leisten gute Arbeit für Ihr Projekt und die Stakeholder.

Testabdeckungserosion

Unabhängig davon, welche Abdeckungsziele zu Beginn der Testphase festgelegt wurden, gibt es verschiedene Faktoren, die dazu führen, dass die tatsächlich erreichte Testabdeckung geringer ausfällt. "Erosion" ist hier ein treffender Begriff, da er den schrittweisen Rückgang des Umfangs geplanter Tests und die unvermeidliche Erkenntnis widerspiegelt, dass nicht alle geplanten Tests in der verfügbaren Zeit durchgeführt werden können.

Testabdeckungserosion hat mehrere Ursachen vor der Testdurchführung:

• Zunächst identifizieren Testpläne die zu adressierenden Risiken und die geplante Vorgehensweise. Für das Testen wird in der Regel ein Budget angenommen – das immer ein Kompromiss ist.
• Schlechte, instabile oder unfertige Systemanforderungen, Entwürfe und Spezifikationen erschweren die Testspezifikation. Die Abdeckung im System leidet unter mangelnden Spezifikationsdetails.
• Die späte Verfügbarkeit oder Unzulänglichkeit von Testumgebungen macht bestimmte geplante Tests unpraktikabel oder wenig aussagekräftig. Größere Integrationstests lassen sich möglicherweise nicht wie geplant durchführen, da nicht alle Schnittstellen oder angebundenen Systeme bereitgestellt werden können.
• Leistungstests können beeinträchtigt werden, weil Umgebungen nicht ausreichend skaliert sind oder nicht die Produktivumgebung widerspiegeln.
• Eine späte Lieferung der zu prüfenden Software führt dazu, dass bei festen Deadlines der Umfang der Tests reduziert werden muss.

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

• Wenn die zu testende Software zu Beginn einer Testphase eine schlechte Qualität aufweist, kann das Testen besonders frustrierend sein. Schon die grundlegendsten Tests könnten fehlschlagen, und die gefundenen Fehler sind so gravierend, dass die Entwickler mehr Zeit für die Behebung benötigen als geplant. Wird das Testen unterbrochen, weil die Softwarequalität zu schlecht ist, gerät man in Verzug. Wenn die Deadline bleibt, werden Tests aus dem Umfang gestrichen.
• Treten mehr Fehler auf als erwartet, dauert der Fehlerbehebungs- und Retest-Zyklus selbst länger – und die Zeit reicht nicht, um alle geplanten Tests abzuschließen.
• Läuft die Zeit ab und die Entscheidung zur Freigabe wird getroffen, ist das Testen nicht komplett. Entweder wurden im Plan manche Tests gar nicht erreicht, oder noch bestehende Fehler verhindern den Abschluss fehlgeschlagener Tests. Wenn sich das Go-Live-Datum nicht verschiebt, ist dies das klassische "Test-Squeeze", wie oben beschrieben.

Mit der Erosion der Testabdeckung umzugehen, ist eine der Herausforderungen, denen Tester in allen Projekten begegnen. Selten läuft alles reibungslos und meist bleibt als Möglichkeit nur, Testzeit (und damit Abdeckung) zu reduzieren, um das Projekt auf Kurs zu halten.

Es ist nicht falsch, den Testumfang zu reduzieren; falsch ist nur, dies willkürlich zu tun. Wenn Sie also Entscheidungen treffen, welche Tests gestrichen werden sollen, müssen die Auswirkungen auf Ihre Testziele und die abzudeckenden Risiken überprüft werden. Es kann einige unangenehme Gespräche mit Stakeholdern erfordern.

Wenn die Auswirkungen erheblich sind, müssen Sie möglicherweise ein Meeting zwischen jenen moderieren, die die Streichungen fordern (typischerweise das Projektmanagement), und jenen, deren Interessen davon betroffen sind (die Stakeholder). Ihre Rolle besteht darin, die Situation mit Blick auf die abgeschlossenen Tests, den derzeit bekannten Zustand des getesteten Systems, die Tests, die fehlschlagen und/oder den Fortschritt blockieren, sowie den noch offenen Testaufwand darzustellen.

Ihre Pläne und Modelle spiegeln den ursprünglichen Testumfang wider und sind entscheidend, um Stakeholdern und Management die bestehenden Lücken und verbliebenen Risiken zu verdeutlichen und die Entscheidung zu ermöglichen, ob weitergetestet oder gestoppt wird.

Störfallmanagement

Sobald das Projekt in die Phasen Systemtests und Abnahmetests übergeht, wird es weitgehend von den während der Testausführung auftretenden Störfällen bestimmt. Solche Störfälle lösen weitere Aktivitäten im Projekt aus, und Statistiken über diese Vorfälle können manchmal einen guten Einblick in den Projektstatus geben. Bei der Klassifizierung von Störfällen sollten wir vorausschauend überlegen, wie diese Informationen später genutzt werden.

Ein Störfall ist ein ungeplantes Ereignis, das während des Testens auftritt und das den erfolgreichen Abschluss des Testens, die Abnahmeentscheidung oder die Notwendigkeit weiterer Maßnahmen beeinflussen kann.

Für diese ungeplanten Ereignisse nutzen wir den neutralen Begriff Störfall. In der Praxis werden dafür aber oft auch andere Begriffe verwendet; manche davon sind neutraler als andere. 

Fehlschlagende Tests werden manchmal als Beobachtungen, Auffälligkeiten oder Probleme bezeichnet – neutrale Begriffe, die keine Ursache unterstellen. Aber auch Begriffe wie Probleme, Bugs, Defekte oder Fehler sind im Umlauf – diese unterstellen jedoch bereits einen Fehler im System. Das kann eine zu frühe Schlussfolgerung sein und irreführend wirken.

Wir empfehlen, die Begriffe Bug, Defekt oder Fehler jenen Ergebnissen aus der Fehleranalyse des getesteten Systems vorzubehalten, die üblicherweise eine Nachbesserung durch das Entwicklungsteam nach sich ziehen.

Störfälle können sich auf zwei Arten äußern:

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

Systemfehler

Diese Vorfälle sind oft von unmittelbarer Bedeutung, da sie das Vertrauen in die Systemqualität untergraben. 

Unterbrechungen und Beeinträchtigte Tests

Manche Organisationen behandeln diese Vorfälle überhaupt nicht als solche – Unterbrechungen gehören zum normalen Auf und Ab von Projekten, die sich ihrem Abschluss nähern. Beeinträchtigte Tests, bei denen die Umgebung oder das Test-Setup fehlerhaft ist, werden möglicherweise dem Testteam angelastet (für die fehlerhafte Einrichtung oder zumindest dafür, dass vor Testbeginn nicht kontrolliert wurde).

In beiden Fällen wird der Testfortschritt beeinträchtigt und, wenn Sie den Prozess verantworten, müssen Sie Verzögerungen erklären. Aus diesem Grund sollten Sie entweder diese Ereignisse als Vorfälle erfassen oder das Team bitten, ein Testprotokoll zu führen, in dem Ausfälle der Testumgebung, Konfigurationsprobleme oder fehlende geeignete Softwareversionen dokumentiert werden. Tun Sie dies nicht, wird es schwierig, Verzögerungen im Fortschritt zu rechtfertigen, und es könnte auf Sie und Ihr Team negativ zurückfallen.

Sollten Incidents protokolliert werden oder nicht?

Mit dem Aufkommen von agilen und kontinuierlichen Auslieferungsansätzen wurde die traditionelle Sichtweise des Incident-Managements in Frage gestellt. In klassischen Projektphasen werden Vorfälle als potenzielle Arbeitspakete für Entwickler behandelt, die abhängig von Schweregrad und/oder Dringlichkeit genehmigt werden. 

Es gibt einen formalen, oft bürokratischen Prozess, in dem Vorfälle überprüft, priorisiert und von der Entwicklungs- (oder einer anderen) Abteilung bearbeitet werden. Dabei können komplexe Werkzeuge für das Incident-Management zum Einsatz kommen.

In kleineren, agilen Teams ist die Beziehung zwischen Testern und Entwicklern eng. Das Team als Ganzes trifft sich vielleicht täglich, um über größere Vorfälle zu sprechen, aber meist werden Fehler informell gefunden, diagnostiziert, behoben und erneut getestet, ohne dass ein Vorfall protokolliert oder andere Teammitglieder oder externe Geschäfts- oder IT-Personen eingebunden werden müssen. Schwerwiegendere Fehler werden ggf. diskutiert und in die Arbeit zu einer User Story aufgenommen oder in speziellen Bugfix-Sprints zusammengefasst.

Wir haben den Zweck und die Notwendigkeit von Dokumentation in einem früheren Artikel besprochen. Diese Überlegungen sind auch für Vorfälle relevant. Das Team muss klären, ob ein Incident-Tool und -Prozess erforderlich ist und ob es für das Team hilfreich ist oder von außerhalb verlangt wird.

Größere Teams verlassen sich aus drei Gründen oft auf Prozesse und Werkzeuge zur Incident-Steuerung: 

1. Um sicherzustellen, dass Vorfälle nicht vergessen werden
2. Damit schwerwiegende Probleme von Stakeholdern und Projektleitung überprüft werden 
3. Um Kennzahlen zu erfassen, die während und nach dem Projekt hilfreich sein können.

More Articles

• 9 Arten von Softwaretests in der Softwaretechnik
• 5 Arten von Performancetests + Top-Tools
• Softwaretest-Trends: Neueste QA-Technologien, Statistiken & Daten

Dringlichkeit und Schwere trennen

Unabhängig davon, welches Incident-Management-Verfahren Sie verwenden, empfehlen wir, jedem Vorfall sowohl eine Priorität als auch einen Schweregrad zuzuordnen.

• Priorität wird aus Testperspektive vergeben und beeinflusst, wann ein Vorfall behoben wird. Der Tester sollte entscheiden, ob ein Vorfall hohe oder niedrige Priorität (oder eine der zulässigen Zwischenstufen) hat. Die Priorität gibt an, wie dringend dieser Fehler für die Tester selbst ist und basiert auf dem Einfluss des Testfehlers auf die weitere Testdurchführung.
• Die Schwere wird aus der Perspektive des Anwenders vergeben und zeigt an, wie akzeptabel (meist) ein Defekt ist. Die Endanwender oder deren Leitung sollten den Schweregrad bestimmen oder (effizienter) die Einschätzung der Tester bei Bedarf überschreiben. Die Schwere spiegelt die Auswirkung des Fehlers auf das Geschäft wider, wenn er nicht vor der Auslieferung behoben wird. In der Regel macht ein schwerer Fehler das System untragbar. Ist ein Fehler geringfügig, kann beschlossen werden, ihn erst in einer späteren Version zu beheben.

Wenn ein Vorfall das Testen stoppt und das Testen auf dem kritischen Pfad liegt, steht das gesamte Projekt still.

Ein Vorfall mit hoher Priorität stoppt alle Tests und in der Regel das gesamte Projekt.

Wichtig bei Incident-Klassifikationsschemen ist: Nicht jeder dringende Vorfall ist schwerwiegend, und nicht jeder schwerwiegende Vorfall ist dringend.

Das Endspiel steuern

Wir nennen die letzten Phasen unseres Testprozesses das „Endspiel“, da das Management der Testaktivitäten in diesen letzten, möglicherweise hektischen und stressigen Tagen eine andere Disziplin erfordert als die eher entspannte Phase der Testplanung zuvor.

Denken Sie daran: Das Ziel von Testing ist es, Informationen an die Stakeholder zu liefern, die es ihnen ermöglichen, eine Entscheidung zu treffen – zu akzeptieren, zu korrigieren, abzulehnen, das Projekt zu verlängern oder es ganz aufzugeben. 

Wenn ein gemeinsames Verständnis der zu testenden Modelle besteht, ist es viel einfacher zu erklären, was im Hinblick auf das Modell „funktioniert“ und wo Dinge nicht funktionieren und welche Risiken mit diesen Fehlern verbunden sind. Es liegt an den Stakeholdern, diese Informationen zu nutzen, um ihre Entscheidungen zu treffen – von Ihnen angeleitet.

Einer der Vorteile eines risikobasierten Testansatzes ist, dass, wenn das Testen in einem späten Projektstadium gekürzt wird, wir das Restrisiko als Argument nutzen können, um weiterhin zu testen oder sogar mehr Tests durchzuführen. 

Wenn das Management darauf besteht, das Testen einzuschränken, sollten Tester einfach die Risiken aufzeigen, die dabei „abgewogen“ werden. Das ist viel einfacher, wenn frühzeitig eine Risikoanalyse durchgeführt wurde, die zur Steuerung der Testaktivitäten genutzt und während des Projekts beobachtet wird. Wenn das Management kontinuierlich über die Restrisiken informiert ist, ist es weniger wahrscheinlich, dass das Testen überhaupt eingeschränkt wird.

Das war’s – viel Erfolg beim Testen!

Melden Sie sich für den The QA Lead Newsletter an, um benachrichtigt zu werden, wenn neue Teile der Serie erscheinen. Diese Beiträge sind Auszüge aus Pauls Leadership In Test Kurs, den wir Ihnen sehr empfehlen, um tiefer in dieses und andere Themen einzutauchen. Falls Sie sich anmelden, nutzen Sie unseren exklusiven Gutscheincode QALEADOFFER und sparen Sie $60 auf den vollständigen Kurspreis!