Qualitätssicherung in Enterprise Software meistern: Strategische Überlegenheit (2/4)

In der Softwareentwicklung gibt es spannende Momente: Die Testphase rückt näher, der Countdown läuft und alle Augen sind auf Ihr QS-Team gerichtet. Zeit und Ressourcen sind knapp, während die Zahl der Testfälle und -aktivitäten steigt. Es ist wie ein Balanceakt auf einem schmalen Grat, der mit zunehmendem Wind immer schwieriger wird. Unentdeckte Fehler können später zu einem Sturm von Problemen führen. Wie meistern Sie diesen Spagat und stellen sicher, dass Ihre Software in höchster Qualität ausgeliefert wird, während Sie in dieser kritischen Phase die Ruhe bewahren? 

Im ersten Teil der Artikelserie haben wir wichtige Herausforderungen besprochen, die bei der Qualitätssicherung auftreten können. In diesem zweiten Teil erkunden wir, wie Sie durch die richtige Strategie, kluge Ressourcennutzung und einen geschulten Blick für das Wesentliche das Risiko in Testphasen minimieren und die Softwarequalität maximieren – um strategische Überlegenheit zu erlangen.

Die Teststrategie muss anpassungsfähig und flexibel sein, um auf unvorhergesehene Umstände reagieren zu können. Selbst ein gut vorbereitetes QS-Team kann mit unerwarteten Herausforderungen konfrontiert werden, sei es durch Hardwareprobleme, verspätete Implementierung von Funktionen oder eine fehlerhafte Umsetzung von wichtigen Anforderungen. Die Fähigkeit, in solchen Momenten strategisch zu handeln und die Teststrategie dynamisch anzupassen, kann den Unterschied zwischen Erfolg und Misserfolg ausmachen.

Sie steigern die Effizienz der Qualitätssicherung, in dem Sie bewusster und sparsamer mit Ihren Ressourcen umgehen und gleichzeitig eine gute Qualität anstreben. Es ist sehr wichtig, dass Sie bei Ihren QS-Entscheidungen stets Aufwand und Nutzen abwägen und berücksichtigen. Im Folgenden stelle ich Ihnen verschiedene Ansätze vor, die Ihnen helfen können, eine strategische Überlegenheit in der Qualitätssicherung zu erlangen.

Welche Browser verwenden Ihre Endnutzer am häufigsten?

In der Welt der Qualitätssicherung ist Zeit oft ein kostbares Gut. Die Testausführungszeit kann exponentiell zunehmen, wenn Sie Ihre Webanwendung auf allen verfügbaren Browsern testen. Es ist jedoch nicht immer notwendig, diesen aufwändigen Weg zu gehen, insbesondere, wenn Sie nur über begrenzte Zeit und Ressourcen verfügen. Eine der wichtigsten Taktiken besteht darin, sich auf das zu konzentrieren, was wirklich zählt. Beginnen Sie damit, die Präferenzen Ihrer Endbenutzer zu verstehen. Welche Browser verwenden sie am häufigsten?

Stellen Sie sich vor, 95 Prozent Ihrer Nutzer verwenden Chrome, während 4 Prozent Edge und nur 1 Prozent Firefox nutzen. Ein Fehler, der Firefox betrifft, mag ärgerlich sein, betrifft aber nur eine kleine Nutzergruppe. Diese Nutzer könnten im Notfall ohne großen Aufwand auf Chrome oder Edge ausweichen. Ein Fehler in Chrome hingegen wäre schwerwiegender und müsste wahrscheinlich sofort behoben werden. Hier wird die Priorität deutlich. Sie wollen sicherstellen, dass die Mehrheit der Nutzer ein reibungsloses Erlebnis hat. Es wäre unrealistisch zu erwarten, dass sie auf einen anderen Browser umsteigen, um das Problem zu umgehen.

Indem Sie sich auf die wichtigsten Browser fokussieren, sparen Sie wertvolle Ressourcen und Zeit, die Sie für andere Aspekte der Qualitätssicherung nutzen können. Eine kluge Browserstrategie ist daher ein entscheidender Schritt auf dem Weg zu maximaler Qualität mit minimalen Aufwänden.

Reduzieren Sie Ihre Tests auf die meist verwendeten Browser und sparen Sie wichtige Ressourcen und kostbare Zeit.

Zudem ist es ratsam, die Entwickler darauf hinzuweisen, dass sie ihre Tests vorrangig mit den gängigsten Browsern durchführen sollten. Alternativ sollten sie die Durchführung von Tests mit verschiedenen Browsern in Betracht ziehen, um eine breitere Testabdeckung zu gewährleisten. Dieser Ansatz stellt sicher, dass die Entwicklung und Optimierung auf die Bedürfnisse einer breiten Nutzerbasis abgestimmt ist.

Randomized Browser statt Cross-Browser

Stellen Sie sich vor, Ihre Nutzer verwenden Chrome, Edge und Firefox gleichermaßen, und Sie müssen Ihre Tests auf all diesen Browsern durchführen. Das kann die Testausführungszeit drastisch verlängern. Diese kostbare Zeit haben Sie in der Regel nicht, insbesondere während der Testphase für Testwiederholungen (Reruns).

Eine bewährte Methode für automatisierte (Regressions-)Tests ist die Verwendung von randomized Browsern. Dabei wird bei jeder Testwiederholung ein Browser zufällig ausgewählt. Dies mag auf den ersten Blick wie Glücksspiel erscheinen, hat aber einen klaren Vorteil: Über die Testwiederholungen hinweg werden faktisch alle Browser abgedeckt. Dies bedeutet, dass Ihre Tests eine ausgewogene Abdeckung bieten, ohne dass jeder Browser in jeder Durchführung getestet werden muss.

Eine alternative Methode besteht darin, Ihre Tests nach Themen zu unterteilen und diese Themen mit verschiedenen Browsern zu testen. Beim nächsten Testdurchlauf ändern Sie die Browser-Auswahl für die Themen. Auf diese Weise gewährleisten Sie, dass jedes Thema im Laufe der Zeit mit allen Browsern gründlich getestet wird. Dies ermöglicht eine effiziente Abdeckung, ohne die Testausführungszeit zu verlängern.

Die Entscheidung für eine dieser Methoden hängt von der jeweiligen Situation ab. Der Schwerpunkt liegt jedoch auf die Maximierung der Testabdeckung auf verschiedenen Browsern, ohne die Testausführungszeit übermäßig zu verlängern. Auf diese Weise können Sie Ihre Testressourcen optimal nutzen und dennoch sicherstellen, dass Ihre Anwendung reibungslos auf den gängigsten Browsern einwandfrei funktioniert.

Anzahl der Betriebssysteme vervielfacht die Testausführungszeit

Eine der Herausforderungen bei der Software-Qualitätssicherung besteht darin, sicherzustellen, dass Ihre Anwendung auf verschiedenen Betriebssystemen einwandfrei funktioniert. Das Testen auf Windows, macOS und Ubuntu kann die Testausführungszeit erheblich erhöhen und Ressourcen binden.

Um diesen Spagat zwischen verschiedenen Betriebssystemen zu meistern, ist es entscheidend, zunächst zu verstehen, welche Betriebssysteme Ihre Nutzer am häufigsten verwenden. So können Sie Ihre Ressourcen auf die am häufigsten verwendeten Plattformen konzentrieren. In den meisten Fällen ist es sinnvoll, primär auf dem am häufigsten verwendeten Betriebssystem zu testen, da dies die größte Nutzerbasis abdeckt.

Sobald Sie Ihre Tests auf dem Hauptbetriebssystem durchgeführt haben, können Sie stellvertretend einen Teil Ihrer Tests auf die anderen Betriebssysteme ausweiten. Der Schwerpunkt liegt dabei auf betriebssystemspezifischen Tests und Funktionen. Auf diese Weise können Sie die Testausführungszeit reduzieren und gleichzeitig sicherstellen, dass Ihre Anwendung auf verschiedenen Plattformen funktioniert.

Ein weiterer wichtiger Aspekt ist die Analyse der auf einem Betriebssystem gefundenen Fehler. Die Anzahl der entdeckten Fehler gibt Ihnen oft Aufschluss darüber, ob Sie weitere Tests auf dieser Plattform durchführen müssen. Wenn ein Betriebssystem eine hohe Anzahl von Fehlern aufweist, kann dies darauf hinweisen, dass intensivere Tests erforderlich sind, um potenzielle Probleme zu identifizieren und zu beheben.

Es ist auch ratsam, die Tests aufzuteilen und rotierend auf verschiedenen Betriebssystemen durchzuführen, anstatt in jedem Durchlauf alle Tests auf allen Plattformen auszuführen. Dies ermöglicht es Ihnen, die Testressourcen effizienter zu nutzen und dennoch sicherzustellen, dass Ihre Anwendung auf verschiedenen Betriebssystemen robust ist.

Die richtige Strategie bei der Auswahl der Betriebssysteme und der Organisation der Tests kann dazu beitragen, die Testausführungszeit zu optimieren und gleichzeitig sicherzustellen, dass Ihre Software auf den von Ihren Nutzern am häufigsten verwendeten Plattformen einwandfrei funktioniert.

Gesamtüberblick

Stellen Sie sich Ihr QS-Team wie ein Orchester vor, in dem jedes Mitglied ein Instrument spielt. Damit die Musik harmonisch und fehlerfrei erklingt, brauchen Sie einen Dirigenten, der den Überblick über das gesamte Ensemble behält. In ähnlicher Weise erfordert strategische Überlegenheit, dass mindestens eine Person Ihres QS-Teams den Gesamtüberblick über alle Aspekte behält, die für den Qualitätssicherungsprozess relevant sind. Dazu gehören nicht nur die Tests selbst, sondern auch die Testumgebungen, die Besonderheiten Ihrer Software und die Testabdeckung. Der Gesamtüberblick hilft dabei, die Qualität strategischer Entscheidungen zu verbessern und Ressourcen effizienter einzusetzen. Insgesamt spielt der Gesamtüberblick eine entscheidende Rolle bei der strategischen Ausrichtung der Software-Qualitätssicherung. Er ermöglicht es Ihrem Team, die richtigen Prioritäten zu setzen, Risiken zu minimieren und letztendlich eine Software von höchster Qualität zu liefern.

Der Tanz mit Bugs: Priorisierung

Bug-Management ist ein essenzieller Prozess in der QS. Dabei werden Bugs, also Fehler oder Probleme in einer Softwareanwendung, erfasst, überwacht, gemeldet, priorisiert, behoben und überprüft. Es ist wichtig zu verstehen, dass nicht jeder gefundene Bug zwangsläufig behoben werden muss und schon gar nicht sofort. Die strategische Auswertung und Priorisierung von Bugs sind entscheidend, um begrenzte Ressourcen effizient zu nutzen. Dieser Prozess erfordert eine klare Unterscheidung zwischen dem Schweregrad und der Dringlichkeit von Bugs, um ein effektives Bug-Management zu gewährleisten.

Schweregrad (Severity): Dieses Kriterium bewertet die Auswirkungen eines Fehlers auf die Anwendung und die Benutzer. Der Schweregrad lässt sich typischerweise wie folgt kategorisieren:

• Kritisch: Die Anwendung ist nicht funktionsfähig oder es kommt zu Datenverlust.
• Hoch: Ein wesentliches Feature ist beeinträchtigt, aber die Anwendung funktioniert weiterhin.
• Mittel: Ein nicht kritisches Feature ist beeinträchtigt.
• Niedrig: Kosmetischer Fehler, der die Benutzererfahrung minimiert.

Beispiel: Ein E-Commerce-Shop hat einen Fehler, bei dem Bestellungen zufällig verloren gehen. Dies ist ein schwerwiegender Fehler, da er zu Umsatzeinbußen und Kundenverlust führen kann.

Dringlichkeit (Urgency): Dieses Kriterium berücksichtigt den Zeitrahmen, in dem ein Fehler behoben werden muss. Ein Fehler kann dringend sein, wenn er sofortige Aufmerksamkeit erfordert, zum Beispiel, um eine wichtige Deadline oder eine Kundenerwartung einzuhalten.

Beispiel: Angenommen, derselbe E-Commerce-Shop hat einen kosmetischen Fehler, bei dem ein Bild auf der Startseite leicht verschoben ist. Dies ist zwar keine schwerwiegende Beeinträchtigung, aber wenn dieser Fehler kurz vor einem wichtigen Verkaufsereignis auftritt, kann seine Dringlichkeit zunehmen.

Unterscheidung zwischen Schweregrad und Dringlichkeit bei der Priorisierung:

• Ein Fehler mit hohem Schweregrad und hoher Dringlichkeit sollte oberste Priorität haben, da er sowohl schwerwiegend ist als auch schnell behoben werden muss.
• Ein Fehler mit geringem Schweregrad, aber hoher Dringlichkeit, sollte möglicherweise schnell behoben werden, z.B. um eine Sicherheitslücke zu schließen, auch wenn er die Funktionalität der Anwendung nicht beeinträchtigt.
• Ein schwerwiegender Fehler mit hohem Schweregrad und geringer Dringlichkeit muss trotz seiner gravierenden Auswirkungen möglicherweise nicht sofort behoben werden, wenn keine unmittelbaren Fristen oder Kundenanfragen vorliegen.
• Ein Fehler mit geringem Schweregrad und geringer Dringlichkeit kann auf die niedrigste Priorität gesetzt werden und möglicherweise später behoben werden.

Relevanz für den Benutzer (User Impact): Hier wird bewertet, wie viele Benutzer von einem Fehler betroffen sind und wie stark deren Erfahrung beeinträchtigt wird. Ein Fehler, der viele Benutzer betrifft oder deren Hauptaufgaben beeinträchtigt, hat eine höhere Priorität.

Geschäftliche Auswirkungen (Business Impact): Dieses Kriterium berücksichtigt die finanziellen Auswirkungen eines Fehlers auf das Unternehmen. Ein Fehler, der zu Umsatzeinbußen führt oder rechtliche Konsequenzen hat, wird höher priorisiert.

Reproduzierbarkeit (Reproducibility): Die Einfachheit oder Schwierigkeit, einen Fehler zu reproduzieren, kann die Priorisierung beeinflussen.

Abhängigkeiten (Dependencies): Wenn ein Fehler das Beheben anderer Fehler erfordert oder von anderen Faktoren abhängt, sollte dies bei der Priorisierung berücksichtigt werden.

Historische Daten (Historical Data): Die Analyse historischer Daten kann helfen, Muster bei wiederkehrenden Fehlern zu erkennen und diese höher zu priorisieren, um langfristige Verbesserungen zu erzielen.

Kundenfeedback (Customer Feedback): Wenn Kunden aktiv auf einen Fehler hinweisen oder sich darüber beschweren, sollte dies als starkes Signal für die Priorisierung betrachtet werden. Tritt derselbe Fehler jedoch in der nächsten Version erneut auf, ist in der Regel eine Eskalation der Kundenunzufriedenheit zu befürchten.

Regulatorische Anforderungen (Regulatory Requirements): Wenn die Einhaltung von Gesetzen oder Branchenstandards betroffen ist, sollten Fehler, die diese Anforderungen verletzen, höher priorisiert werden.

Risikoakzeptanz (Risk acceptance): In einigen Fällen kann ein Unternehmen entscheiden, einen Fehler mit niedrigerer Priorität zu akzeptieren, wenn die Behebung einen erheblichen Aufwand erfordert und das Risiko gering ist.

Die genauen Kriterien und Gewichtungen können je nach Unternehmen, Produkt und Projektkontext variieren. Es ist wichtig, klare Richtlinien für die Priorisierung festzulegen und sicherzustellen, dass das gesamte Team diese Kriterien versteht und einhält. Dies ermöglicht eine konsistente und effektive Priorisierung von Bugs.

Je näher das Ende der Testphase rückt, desto weniger Bugs sollten gefunden oder behoben werden. Nimmt die Anzahl der Bugs bis zum Release nicht ab, müssen die Ursachen nach dem Release (z.B. in der Retrospektive) untersucht und behoben bzw. in Zukunft vermieden werden.

Testfall-Tetris: Effizientes Management wachsender Testfallzahlen

“Tetris” ist ein beliebtes Videospiel, bei dem Blöcke in verschiedenen Formen herunterfallen und der Spieler sie so anordnen muss, dass sie eine durchgehende horizontale Linie bilden. Sobald eine horizontale Linie vollständig ist, verschwindet sie, und der Spieler erhält Punkte. Wenn sich die Tetris-Blöcke jedoch unaufhaltsam stapeln, wird es mit der Zeit immer schwieriger die Situation zu bereinigen, und der Spieler verliert schließlich das Spiel. In der Software-Qualitätssicherung verhält es sich mit den Testfällen ähnlich. Mit zunehmender Zeit und wachsender Komplexität der Software steigt auch die Anzahl der benötigten Testfälle.

Dies führt jedoch zu erhöhten Wartungsaufwänden und längeren Testausführungszeiten, was die Effizienz Ihrer QS-Aktivitäten erheblich beeinträchtigen kann.

Skalierende Aufwände stellen eine ernsthafte Herausforderung dar und können Ihr QS-Team früher oder später lahmlegen. Es ist daher von entscheidender Bedeutung, frühzeitig Maßnahmen zu ergreifen, um dieses Problem anzugehen und entgegenzuwirken. Hier sind einige hilfreiche Ansätze zur Bewältigung dieses Dilemmas:

Kompaktifizierung der Testfälle: Überprüfen Sie Ihre bestehenden Testfälle kritisch und versuchen Sie, sie zu optimieren. Reduzieren Sie unnötige Schritte und konzentrieren Sie sich auf das Wesentliche. Testfälle sollten kompakt und effektiv sein, um Redundanzen und unnötige Komplexität zu vermeiden.

Implizites und explizites Testen: Vermeiden Sie doppelte Testarbeit. Aktionen oder Prozesse, die bereits in anderen Testfällen enthalten sind, z.B. in der Vorbereitung, müssen nicht noch einmal explizit getestet werden.

Fokussierung auf das Notwendige: Identifizieren Sie den Hauptzweck jedes Testfalls und reduzieren Sie ihn auf das Minimum, das benötigt wird, um diesen Zweck zu erfüllen. Durch eine genaue Identifizierung des Testziels können Sie Testfälle auf das Wesentliche reduzieren, ohne an Qualität einzubüßen.

Gemeinsame Testdurchführung: Testfälle mit gleichen oder ähnlichen Voraussetzungen (Preconditions) können, wenn möglich, gemeinsam ausgeführt werden, um Testvorbereitungsaufwände zu minimieren.

Überwachung der Testausführungszeiten: Behalten Sie die Zeit im Auge, die für die Durchführung Ihrer Tests benötigt wird. Vergleichen Sie die tatsächliche Ausführungszeit mit der geplanten Zeit, um Abweichungen zu identifizieren. Vergleichen Sie bei den automatisierten Tests zwischen „Realtime“ und „Executiontime“, um Zeitverluste zu erkennen.

Reduzierung von Wartezeiten: Minimieren Sie Wartezeiten (Sleeptime) bei automatisierten Tests auf das notwendige Minimum. Stattdessen können Sie beispielsweise einen Application Busy Detector verwenden, der auf bestimmte Bedingungen wartet wie z.B. das Verschwinden von Ladeanzeigen (Loading Indicator), bevor er mit dem nächsten Schritt fortfährt.

Ursachenanalyse bei steigenden Ausführungszeiten: Wenn die Ausführungszeiten einer Testsuite ansteigen, sollten Sie die Ursachen frühzeitig identifizieren und zeitnah beheben, um die Effizienz zu bewahren.

Überarbeiten Sie und optimieren Sie Ihre (automatisierten) Tests, um die Ausführungszeiten zu reduzieren und die Wartbarkeit zu verbessern.

Refactorings: Wenn Testfälle oder Testumgebungen veraltet oder unübersichtlich werden, führen Sie Refactorings durch, um die Wartungsaufwände zu minimieren und die Erweiterbarkeit zu ermöglichen.

Eine kluge Strategie für den Umgang mit der wachsenden Anzahl von Testfällen ist entscheidend, um sicherzustellen, dass Ihre QS-Aktivitäten auch in komplexen langlaufenden Projekten effizient und kosteneffektiv bleiben.

Priorisierung der Testfälle

Ähnlich wie bei der Priorisierung von Bugs sollten Testfälle je nach ihrer Auswirkung auf den Arbeitsablauf des Endbenutzers priorisiert werden. Dieser Schritt ermöglicht es Ihrem QS-Team, sich auf die kritischsten Aspekte Ihrer Anwendung zu konzentrieren und das Risiko auch unter ungünstigen Umständen zu minimieren. Das ist strategische Überlegenheit.

Die Priorisierung von Testfällen erfolgt in der Regel in verschiedenen Stufen:

Blocker: Hierbei handelt es sich um Testfälle, die für den Grundbetrieb Ihrer Anwendung unerlässlich sind. Dazu gehören z.B. der Anmeldeprozess oder die Verwaltung von Berechtigungen.

Kritisch: Kritische Testfälle betreffen Funktionen, die zwar nicht den gesamten Arbeitsablauf (Workflow) blockieren, aber dennoch von hoher Bedeutung sind. Beispiele hierfür sind Zahlungsmethoden oder Datenübertragungen.

Wichtig: Diese Testfälle sind relevant, aber nicht unmittelbar geschäftskritisch. Die Kategorie “Wichtig” für Testfälle sollte Testfälle abdecken, die zwar nicht als unmittelbare Blocker oder kritische Funktionen gelten, aber dennoch von erheblicher Bedeutung für die Gesamtfunktionalität und die Benutzererfahrung Ihres Softwareprodukts sind. Zum Beispiel:

• Passwortwiederherstellung: Stellen Sie sicher, dass Benutzer ihr Passwort zurücksetzen können, falls sie es vergessen haben. Dies ist wichtig für die Sicherheit und die Benutzerfreundlichkeit.
• Suchfunktion: Testen Sie die Suchfunktion Ihrer Anwendung, um sicherzustellen, dass die Benutzer relevante Ergebnisse finden können. Eine effiziente Suche ist wichtig für die Benutzerzufriedenheit.

Normal: Testfälle in dieser Kategorie behandeln allgemeine Funktionalitäten, die die Anwendung vervollständigen, aber keinen unmittelbaren Einfluss auf den Workflow des Endbenutzers haben. Beispiel: Testfälle für Filter und Sortieroptionen

Unwichtig: Testfälle dieser Art beziehen sich auf Aspekte, die für den normalen Betrieb der Anwendung von geringer Relevanz sind, wie beispielsweise die Position eines Buttons oder die genaue Formulierung einer Fehlermeldung.

Wenn die Zeit knapp ist, sollten Sie die Blocker und kritischen Testfälle zuerst durchführen, um sicherzustellen, dass die essenziellen Funktionen einwandfrei funktionieren. Wenn dann noch Zeit übrig ist, können Sie sich den wichtigen und normalen Testfällen zuwenden. In diesem Zusammenhang ist es besonders wichtig, dass Sie bei Zeitmangel alle Schlüsselprüfungen in allen Bereichen durchführen.

Die Priorisierung von Testfällen ist eine strategische Entscheidung, die dazu beiträgt, die Qualität Ihrer Anwendung zu gewährleisten und gleichzeitig flexibel auf unterschiedliche Zeit- und Ressourcenbeschränkungen zu reagieren. Dieses gezielte Herangehen ermöglicht es Ihrem QS-Team, das Wesentliche im Auge zu behalten.

Stichprobenartig

Wenn die Zeit für die Durchführung der Tests nicht ausreicht und die Tests dieselbe Priorität haben, empfehlt es sich stichprobenartig zu testen.

Alt und unverändert

Bereiche in Ihrer Anwendung, die über einen längeren Zeitraum unverändert geblieben sind, wurden in der Vergangenheit üblicherweise ausgiebig getestet und neigen dazu, kaum bis keine Fehler mehr aufzuweisen. Identifizieren Sie solche Bereiche, da sie Ihnen einen strategischen Vorteil verschaffen können, besonders unter herausfordernden Bedingungen, wie z.B. Zeitdruck. Wenn Sie diese stabilen Bereiche gar nicht oder nur stichprobenartig testen, sparen Sie wertvolle Zeit ohne dabei das Risiko zu erhöhen.

Diese stabilen Bereiche eignen sich meistens sehr gut für die Testautomatisierung. Durch die Ausführung automatisierter Regressionstests lassen sich Fehler, insbesondere mögliche Seiteneffekte, in diesen Bereichen schnell und kosteneffizient ausschließen. Solche automatisierten Tests erfordern normalerweise nur minimale Wartung, da sich diese stabilen Bereiche in der Regel nicht ändern. Dieser Ansatz hilft, Zeit zu sparen und Risiko zu minimieren, ohne die Qualität der Testabdeckung zu beeinträchtigen.

Neue oder veränderte Features

Im Gegensatz zu den unveränderten Bereichen in Ihrer Anwendung haben neue sowie veränderte Funktionalitäten höhere Priorität. Es muss sichergestellt werden, dass die umgesetzten Anforderungen die Erwartungen des Kunden bzw. des Endbenutzers erfüllen.

Im Gegensatz zu den Entwicklern testen Sie aus der Sicht des Endbenutzers. Verlassen Sie sich nicht auf die Tests der Entwickler. Zum einen, weil sie nicht auf dem Endprodukt, sondern in isolierten Umgebungen durchgeführt werden. Zum anderen, weil sie eventuell mangelhafte oder falsch verstandene Anforderungen absichern.

Der Gutfall

Die maximale Qualität eines Softwareproduktes bezieht sich nicht nur auf die Fehlerfreiheit oder das Erfüllen negativer Testfälle, sondern darauf, dass die Software in den zentralen, vom Endbenutzer erwarteten Funktionen optimal und zuverlässig agiert.

Ein Gutfall in der Qualitätssicherung beschreibt primäre Funktionalitäten, die ein Endbenutzer fehlerfrei durchführen sollte. Gutfälle sind üblicherweise höher zu priorisieren als negative Testfälle, da sie die Basis für die grundsätzliche Funktionsfähigkeit der Software bilden. Bevor Sie sich also auf die Negativtests und Ausnahmesituationen stürzen, ist es von entscheidender Bedeutung, zunächst sicherzustellen, dass die normalen Abläufe einwandfrei funktionieren.

Indem Sie die wahrscheinlichsten und am häufigsten auftretenden Nutzerszenarien prioritär behandeln, wird die Qualität in den Schlüsselbereichen Ihrer Anwendung maximiert. Das führt zu einer verbesserten Benutzererfahrung und trägt dazu bei, dass Ihre Software die Anforderungen und Erwartungen der Endbenutzer besser erfüllt und deren Vertrauen gewinnt. Das ist strategische Überlegenheit.

Wo Rauch ist, ist meist auch Feuer

Wenn Sie Bugs in einem Bereich Ihrer Anwendung finden, so ist es sinnvoll, dort weiter zu bohren. Wenn die Anzahl der Bugs in einem Bereich hoch ist, hat die Qualitätssicherung in diesem Bereich in der Regel eine höhere Priorität.

Effiziente Testfallauswahl

Die Testfallauswahl für Testläufe und Testlaufwiederholungen ist ein kritischer Schritt in der Software-Qualitätssicherung. Sie ermöglicht es, die Effizienz der Testausführung zu maximieren und gleichzeitig die Qualität der Software sicherzustellen. Dieser Prozess beinhaltet die sorgfältige Auswahl der Testfälle, die in einem bestimmten Testlauf oder einer Testlaufwiederholung ausgeführt werden sollen. Durch eine sorgfältige Auswahl der minimal benötigten Testfälle können Sie Features und Bugs mit der richtigen Balance zwischen Effizienz und Qualität testen.

Hier sind einige Schritte, die Ihnen bei der Auswahl der richtigen Testfälle helfen können:

Identifizierung des Ziels: Bevor Testfälle ausgewählt werden, muss das Ziel des Testlaufs oder der Testlaufwiederholung klar definiert werden. Dabei kann es sich z.B. um die Überprüfung neuer Funktionen, die Validierung von Fehlerkorrekturen oder die Bewertung der Gesamtleistung der Anwendung handeln.

Priorisierung: Testfälle sollten nach ihrer Priorität ausgewählt werden. Das bedeutet, dass kritische Funktionen oder solche, die wichtige Geschäftsprozesse beeinträchtigen, Vorrang haben sollten. Die Priorisierung basiert häufig auf Risikoanalysen und Geschäftsanforderungen.

Abhängigkeiten erkennen: Verstehen Sie die Abhängigkeiten zwischen den verschiedenen Funktionen und Modulen Ihrer Anwendung. Dies hilft bei der Auswahl der Testfälle, die die kritischen Wechselwirkungen abdecken.

Historische Daten nutzen: Frühere Testergebnisse und Fehlerberichte können hilfreiche Hinweise liefern, welche Testfälle erneut ausgeführt werden sollten. Dies ist besonders nützlich, um sicherzustellen, dass zuvor identifizierte Fehler behoben wurden.

Änderungen an der Anwendung: Wenn seit dem letzten Testlauf Änderungen an der Anwendung vorgenommen wurden, sollten Testfälle ausgewählt werden, die diese Änderungen abdecken. Dies ist wichtig, um sicherzustellen, dass neue Funktionen oder Fehlerbehebungen korrekt funktionieren.

Zeitmanagement: Testfälle sollten so ausgewählt werden, dass die Testausführung innerhalb eines akzeptablen Zeitrahmens erfolgen kann. Dies erfordert die Berückaichtigung von Ressourcenbeschränkungen und Zeitplänen.

Testabdeckung: Es ist wichtig sicherzustellen, dass die ausgewählten Testfälle eine angemessene Abdeckung der Anwendung bieten. Dies schließt grundlegende Funktionalitäten, Randfälle und verschiedene Anwendungsbereiche ein.

Testmatrix: Erstellen Sie eine Testmatrix, in der Sie die ausgewählten Testfälle und ihre Abdeckung dokumentieren. Dies hilft Ihnen, den Überblick zu behalten und sicherzustellen, dass Sie alle wichtigen Aspekte abdecken.

Automatisierung: Automatisierte Testfälle sind oft schneller und konsistenter in der Ausführung. Daher sollten geeignete Testfälle für die Automatisierung ausgewählt werden, um die Effizienz zu steigern.

Dokumentation und Nachverfolgung: Es ist wichtig, die ausgewählten Testfälle klar zu dokumentieren und ihre Ausführung zu verfolgen. Dies ermöglicht eine spätere Nachverfolgung der Ergebnisse und eine zielgerichtete Berichterstellung.

Anpassungsfähigkeit: Die Auswahl der Testfälle ist nicht in Stein gemeißelt. Sie sollten bereit sein, Ihre Strategie anzupassen, wenn sich die Anforderungen oder Bedingungen ändern. Dies ermöglicht es Ihnen, flexibel auf neue Informationen oder Entwicklungen zu reagieren.

Die Auswahl von Testfällen ist ein iterativer Prozess, der sorgfältige Planung, Analyse und Abwägung erfordert. Indem Sie Testfälle sorgfältig auswählen und sich auf diejenigen konzentrieren, die am ehesten zu wichtigen Erkenntnissen führen, können Sie Zeit und Ressourcen effizienter nutzen und gleichzeitig eine hohe Testqualität sicherstellen.

Externe Software

Wenn Sie Teile von Fremdsoftware in Ihre Anwendung integriert haben, so müssen Sie sowohl Ihre eigene Software als auch die Integration der Fremdsoftware in Ihre Anwendung testen. Das Testen der Fremdsoftware selbst ist normalerweise nicht Ihre Aufgabe.

Hintertür für die QS

Manchmal müssen Sie sehr aufwendige Voraussetzungen schaffen, um die Tests starten zu können. Wenn die Testvorbereitungen nicht möglich oder nur schwer umsetzbar sind, kann es für die Qualitätssicherung kritisch werden. Es ist deshalb wichtig, diese Risiken vor den Testphasen zu identifizieren und rechtzeitig entsprechende Maßnahmen zu ergreifen:

• Automatisierung der Bereitstellung der für die Tests benötigten Testdaten, Zertifikate, die im nächsten Release zu migrierenden Entitäten etc.
• Einfrieren der notwendigen Voraussetzungen u.a. durch Erstellung von Dumps, Templates etc.
• Vereinfachung eines sehr aufwendigen Vorbereitungsprozesses durch Bereitstellung einer Hintertür, die nur für die QS sichtbar ist.

Dadurch können Sie kostbare Aufwände sparen und zugleich das Risiko eines QS Blockers minimieren.

Gibt es eine effizientere Alternative?

Bevor Sie einen für Sie unumgänglichen Weg beschreiten und dafür mit teuren Aufwänden bezahlen, nehmen Sie sich die Zeit, nach Alternativlösungen oder Abkürzungen zu suchen.

Behalten Sie Ihren QS-Aufwand immer im Auge. Suchen Sie nach Lösungsmöglichkeiten, z.B. durch Automatisierung, um überdurchschnittliche, skalierbare sowie wiederkehrende Aufwände in der Qualitätssicherung loszuwerden oder zumindest zu reduzieren.

Zusammenfassung

Strategische Überlegenheit in der Software-Qualitätssicherung erfordert eine kluge Strategie, die auf Priorisierung und Effizienz setzt. Durch die gezielte Reduktion von Tests, die geschickte Auswahl von Testumgebungen und die Fokussierung auf das Wesentliche können Sie nicht nur die Qualität Ihrer Software verbessern, sondern auch Zeit und Ressourcen optimal nutzen. Dies ist der Schlüssel zu maximaler Qualität bei minimalem Aufwand.

In Teil 3 erfahren Sie, wie eine effiziente Qualitätssicherungsstrategie bereits im Testfall beginnt. (in Kürze online)