Qualitätssicherung (Testen) im Application Life Cycle

Größe: px

Ab Seite anzeigen:

Download "Qualitätssicherung (Testen) im Application Life Cycle"

Götz Heinrich
vor 8 Jahren
Abrufe

Unternehmensberatung GmbH www.triton.at www.tritonqs.

2 Agenda Über uns Fragestellungen und Metriken im Test Testabdeckung Risikobewertung Beantwortung der Fragenstellungen Zusammenfassung

3 Über uns Methodik Testplanung Testfallermittlung Testautomatisierung Testbetrieb Einfach testen. Services Beratung Schulungen Projektunterstützung Betrieb eines Testcenters Tools TOSCA Commander Testmanagement TOSCA Adaptoren Testautomatisierung TOSCA PortfolioManager Testfallgenerierung

Services Beratung Schulungen Projektunterstützung Betrieb eines

4 Wesentliche Fragestellungen im Testprozess Application Lifecycle Testplanung Testdurchführung Testauswertung Im Testprozess sind drei essenzielle Fragestellungen immer wieder zu beantworten:? Wie kommen die Vorbereitungen des Tests (Spezifikation) voran?? Wie viel haben wir bereits getestet?? Welche Qualität haben wir (bereits) erreicht?? Wie ist der Status der Testdurchführung?? Wie viele Fehler haben wir?

Wie kommen die Vorbereitungen des Tests (Spezifikation) voran?? Wie viel haben wir bereits getestet?

5 Von der Fragestellung zur Metrik... Die Metrik (griechisch µετρική - Zählung, Messung) bezeichnet im Allgemeinen ein System von Kennzahlen oder ein Verfahren zur Messung einer quantifizierbaren Größe.? Wie kommen die Vorbereitungen des Tests (Spezifikation) voran?? Wie viel haben wir bereits getestet?? Welche Qualität haben wir (bereits) erreicht?? Wie ist der Status der Testdurchführung?? Wie viele Fehler haben wir? Testabdeckung Ausführungsstatus Fehleranzahl

Verfahren zur Messung einer quantifizierbaren Größe.? Wie kommen die Vorbereitungen des Tests (Spezifikation) voran?

6 Testabdeckung absolut und relativ Die Testabdeckung sagt aus, inwieweit die gesamte im System unter Test (SuT) vorliegende Funktionalität über einen Test geprüft werden kann bzw. wurde. Die Testabdeckung wird in % angegeben. Absolute Testabdeckung Alle einzelnen Funktionen des SuT werden gleich bewertet. Die Testabdeckung ergibt sich als Quotient aus getesteten und verfügbaren Funktionen. Relative Testabdeckung Die einzelnen Funktionen des SuT werden einer Risikobewertung unterzogen. Diese Risikobewertung wird in die Bestimmung der Testabdeckung einbezogen. Die Risikobewertung liefert zugleich den Ausgangspunkt für die sequenzielle Planung der Spezifikations- und Durchführungsarbeit.

Die Testabdeckung ergibt sich als Quotient aus getesteten und verfügbaren Funktionen.

7 Testabdeckung technische und fachliche Sicht Testabdeckung aus technischer Sicht Die Bestimmung erfolgt über Tracer/Profiler-Programme. Diese speziellen Werkzeuge werden von der Entwicklung in der Anwendung verankert und registrieren jeden technischen Funktionsaufruf im SuT, der im Zuge der Durchführung eines Testportfolios verursacht wird. Der Quotient aus aufgerufenen/aufrufbaren Funktionen ist die Testabdeckung in %. Die Testabdeckung wird also gemessen (nachgelagerte Bestimmung der Testabdeckung eines Testportfolios). Testabdeckung aus fachlicher Sicht Die Testabdeckung in % wird bestimmt über... Relation getestete Funktionalität zu gesamter Funktionalität Relation getestete Datenkonstellationen zu gesamte Datenkonstellationen Die Testabdeckung wird also vermutet bzw. geschätzt (Prognose der Testabdeckung).

verursacht wird. Der Quotient aus aufgerufenen/aufrufbaren Funktionen ist die Testabdeckung in %.

8 Risikobewertung fachliche, relative Testabdeckung Die Risikobewertung der Funktionalität ist Ausgangspunkt für die Planung der Spezifikationsarbeiten und Grundlage für die Bestimmung der fachlichen, relativen Testabdeckung. Bestimmung des Risikos - allgemein Risiko = Häufigkeit x Schadenshöhe Häufigkeit, in der Funktionen in Anspruch genommen werden Potenzieller monetärer Schaden, der bei Fehlfunktion im Zuge des funktionalen Aufrufs entstehen kann Vorgehen zur Risikobewertung Zunächst werden übergeordnete Einheiten/Bereiche in Bezug auf ihr Risiko bewertet. Anschließend wird stufenweise eine weitere Detaillierung vorgenommen (aus Zeitgründen kann eine vollständige Risikobewertung auf der Ebene einzelner Funktionen in der Regel nicht erfolgen).

Bestimmung des Risikos - allgemein Risiko = Häufigkeit x Schadenshöhe Häufigkeit, in der Funktionen in Anspruch genommen werden Potenzieller monetärer Schaden, der bei Fehlfunktion im Zuge

9 Risikobewertung ein Beispielergebnis (1) Aus der Risikobewertung werden absolute Risikozahlen gewonnen. Diese werden in jeder Ebene auf 1 normiert.

10 Risikobewertung ein Beispielergebnis (2) Absolute Risikozahlen Normierte Risikovektoren

11 Spezifizierte (theoretische) und tatsächliche Testabdeckung Die Antworten auf die Fragen...? Wie kommen die Vorbereitungen des Tests (Spezifikation) voran? Spezifizierte (theoretische) Testabdeckung? Wie viel haben wir bereits getestet?? Welche Qualität haben wir (bereits) erreicht? Tatsächliche (erreichte) Testabdeckung Teststatus

Spezifizierte (theoretische) Testabdeckung? Wie viel haben wir bereits getestet?

12 Spezifizierte Testabdeckung Der Spezifikationsstatus der geplanten Testfälle wird vermerkt. Daraus wird sofort und auf jeder Ebene die aktuell spezifizierte Testabdeckung errechnet und visualisiert.

13 Tatsächliche Testabdeckung und Teststatus Der Ausführungsstatus der geplanten Testfälle wird vermerkt. Daraus wird sofort die tatsächliche Testabdeckung errechnet und deren Status visualisiert.

14 Zusammenfassung Die Metriken im Software-Test lassen sich auf einige wenige Fragestellungen zurückführen. Grundsätzlich gilt für Metriken: weniger ist oft mehr, besser wenige Maßzahlen, die aussagekräftig sind und deren Werte erhoben werden können, als eine Zahlenflut um der Zahlen Willen! Von zentraler Bedeutung ist die relative, fachliche Testabdeckung. Zwingende Voraussetzung für die Aussagekraft ist eine Risikobewertung auf funktionaler Ebene (Funktionale Bereiche, Requirements, UseCases). Die Beantwortung der Fragestellungen wird in TOSCA abgedeckt.

können, als eine Zahlenflut um der Zahlen Willen! Von zentraler Bedeutung ist die relative, fachliche Testabdeckung.

Ähnliche Dokumente

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649 Testautomatisierung Lessons Learned qme Software GmbH Gustav-Meyer-Allee 25 13355 Berlin Telefon 030/46307-230 Telefax 030/46307-649 E-Mail qme Software info@qme-software.de GmbH Testautomatisierung Lessons