Test Management
Die Qualität von Software lässt sich am Besten mit entsprechenden Tests beurteilen. Damit reduziert das Testen das Risiko, dass Fehler im Betrieb auftreten. Dabei ist das Testen nicht auf das bloße Testen der Software beschränkt, sondern wird durch unterschiedliche Aktivitäten begleitet. Testen ist als ein Prozess zu verstehen, der Planung, Analyse, Entwurf und Durchführung der Tests einschließt, und schließlich auch aus Managementsicht das Reporting hinsichtlich der Fortschritte, der Ergebnisse und letztlich der Beurteilung der Qualität der Testobjekte im Blick behält.
Als ISTQB® Certified Tester Foundation Level unterstütze ich Sie beim Aufbau einer geeigneten Test-Strategie, die auf Ihr Unternehmen und Ihre Anforderungen zugeschnitten ist. Neben den klassischen Abnahmetests ist es notwendig, Systemtests, Integrations- und Komponententests durchzuführen. Hierbei kann ich auch auf Entwicklungsebene wertvolle Unterstützung leisten, und dazu beitragen, dass sich die Philosophie des Testens auf allen Teststufen etabliert.
Über die Grundsätze des Testens
Die sieben Grundsätze des Testens:strong> Beim Testen an sich sind einige Grundsätze zu berücksichtigen. So können Tests nur Fehlerzustände aufdecken, aber nicht beweisen, dass es keine gibt, denn vollständiges Testen ist nicht möglich. Je früher mit dem Testen begonnen wird, umso mehr Zeit und Geld kann eingespart werden. Dabei ist zu berücksichtigen, dass es oftmals eine Häufung von Fehlerzuständen in wenigen Modulen gibt, was in Bezug auf Risikoanalysen Berücksichtigung finden sollte. Weiterhin sollten Tests kontextabhängig definiert und regelmäßig angepasst werden, um neue Fehlerzustände aufdecken zu können. Wenn keine Fehler gefunden werden, bedeutet dies nicht, dass ein System brauchbar ist.
Testen im agilen Umfeld
Der inkrementell iterative Ansatz agiler Vorgehensweisen bietet bereits eine gute Basis, ein geeignetes Test Management aufzusetzen. Allerdings ist zu beachten, dass Tests eben nicht nur funktionale Aspekte abdecken, sondern häufig Qualitätsanforderungen adressieren. Eine User-Story als Basis für einen Testfall ist u. U.dafür nicht ausreichend. Eine wesentliche Frage stellt sich auch dazu, wann die Testfälle im Rahmen einer Sprint-Planung oder eines Release durchzuführen sind, bzw. wann genau eine User Story als "done" gesehen werden kann. Hier bieten sich unterschiedliche Strategien an, das Testen in den agile Prozess einzubetten. Die Teststufen bieten einen möglichen Ansatz, bestimmte Aktivitäten bei den jeweiligen Rollen aufzuhängen und gleichzeitig sicherzustellen, dass die Ereignisse in Scrum kontinuierlich fortgeführt werden können.
Coaching von Entwicklungsteams
Integration der Testaktivitäten in den unteren Teststufen: Wie oben bereits angedeutet, können die Teststufen dazu verwendet werden, die Testaktivitäten im Sinne einer kontinuierlichen Begleitung des Software-Entwicklungsprozesses auf bestimmte Rollen zu verteilen. Die Entwickler haben die Möglichkeit, insbesondere Komponententests (Unit-Tests) bereits bei der Erstellung des Codes zu implementieren und damit z. B. die Grundlage für Continious Integration / Delivery zu schaffen. Damit ist die auch die Basis für die nächste Teststufe, den Integrationstests, gelegt. Häufig wird behauptet, dass Unit-Tests überflüssig seien und zu viel Zeit kosteten. Es ist deshalb wichtig, die Unit-Tests im Kontext adäquat zu definieren, damit die Vorteile daraus zu ziehen sind. Dies ist ein Aspekt, der seitens der Entwickler viel Erfahrung voraussetzt bzw. durch entsprechende Anleitung etabliert werden kann.
