Prozesse des TQC Sub-Prozess „Funktionsgruppen identifizieren“ Zunächst wird die Testbasis einem

Review unterzogen. Ziel dieses Reviews ist es, die Anforderungen der Tests an dem Testobjekt zu identifizieren. Innerhalb dieses Prozesses wird zusätzlich überprüft, ob die Testbasis, wie die Softwarespezifikation und das Testkonzept, bereits über Fehler oder ungenau spezifizierte Anforderungen verfügt, die als Defekt in dem bestehenden Incident Management System aufgenommen werden. Das Review kann in Anlehnung der IEEE 1028-2008 (siehe [Ins08a]) erfolgen.

Folgend wird das Testobjekt auf die Testbarkeit bewertet und die zu testenden Funktionen in Funktionsgruppen eingeteilt. Die Funktionsgruppen sind angelehnt an die Architektur der Software. So können z.B. Module in Programmen (in diesem Fall keine Programmkompo-nenten, wie Java-Klassen) als Funktionsgruppen identifiziert werden. Die Gruppen werden entsprechend ihrer Risikobereiche aus dem Testkonzept priorisiert und den Stakeholdern zur Genehmigung vorgelegt. Sollte eine Ablehnung erfolgen, so müssen die Schritte wiederholt werden. Ist die Genehmigung erfolgt, werden die Funktionsgruppen in der Testdesignspezifi-kation dokumentiert. (Siehe Abbildung B.25 auf Seite xxii)

Sub-Prozess „Testbedingungen ableiten“ Aus den Funktionsgruppen werden die Test-bedingungen abgeleitet. Dieses können Funktionen, Transaktionen oder Qualitätsmerkmale sein. Die Testbedingungen werden in der Testdesignspezifikation dokumentiert, die folgend von den Stakeholdern genehmigt werden muss. Eine Ablehnung der Testdesignspezifikation hat zur Folge, dass der erste Schritt wiederholt werden muss. (Siehe Abbildung B.26 auf Seite xxiii)

Sub-Prozess „Testüberdeckungselemente ableiten“ Sind die Testbedingungen iden-tifiziert, so werden daraus die Testüberdeckungselemente abgeleitet. Dieses sind Elemente, die durch Testfälle getestet werden müssen, um ihre Funktionalitäten zu validieren. Diese Elemente werden so kombiniert, dass bei der Ermittlung der Testfälle mehrere Testbedingun-gen durch wenige Testfälle abgedeckt werden können. Die Testüberdeckungselemente werden sodann in der Testdesignspezifikation dokumentiert. (Siehe Abbildung B.26 auf Seite xxiii)

Sub-Prozess „Testfälle ableiten“ Folgend werden die Testfälle zu den Testbedingungen erstellt. Es ist dabei zu beachten, dass die Testfälle so gewählt werden, dass ein Testfall meh-rere Testüberdeckungselemente testet. Für die Ermittlung der Testfälle können Testentwurfs-verfahren für dynamische Tests, wie der Äquivalenzklassenbildung oder der Grenzwertanalyse (siehe z.B. [SL04, S. 98 ff]) verwendet werden.

Die erstellten Testfälle werden in der Testfallspezifikation dokumentiert und den jeweiligen Stakeholdern zur Genehmigung übergeben. Erfolgt eine Ablehnung der Testfallspezifikati-on, so müssen die Testfälle optimiert oder neue erstellt werden. (Siehe Abbildung B.28 auf Seite xxiii)

Sub-Prozess „Testgruppen zusammenstellen“ Basierend auf der Beziehung und der Ausführung der einzelnen Testfälle, werden diese zu Testgruppen zusammengestellt und in der Testablaufspezifikation dokumentiert. (Siehe Abbildung B.29 auf Seite xxiv)

Sub-Prozess „Testablauf erstellen“ In Abhängigkeit zu den bestehenden Bedingungen, wie der Anordnung der Testfälle oder der Risikopriorisierung, werden die Testabläufe erstellt.

Kommen Testwerkzeuge in der Ausführung der jeweiligen Testfälle zum Einsatz, werden die

Abläufe detaillierter beschrieben, um aus den Beschreibungen Testskripte erstellen zu kön-nen. Die Testabläufe werden in der Testablaufspezifikation dokumentiert. Folgend werden die Testdaten für das Testobjekt und parallel dazu die Testumgebung, mit Unterstützung durch das Service Management, identifiziert. Die Ergebnisse werden ebenfalls in der Testablaufspe-zifikation vermerkt.

Die Testablaufspezifikation wird den Stakeholdern zur Genehmigung übergeben. Sollte ei-ne Ablehnung erfolgen, so müssen die jeweiligen Schritte wiederholt werden. (Siehe Abbil-dung B.30 auf Seite xxv)

4.3.2.2.2. Prozess „Testumgebung vorbereiten“ Entgegen den Ausführungen der ISO/IEC DIS 29119-2:2011-2012 werden die folgenden Prozesse zur Implementierung der Te-stumgebung getrennt und als zwei eigenständige Prozesse angeführt. Der Grund dafür ist, dass die Installation der Testumgebung und die Testausführung erst später beginnen können, wenn das Service Management die Implementierung der Software und die eigenen Testakti-vitäten abgeschlossen hat. Zwischen der Erstellung und Implementierung der Testfälle und der Konzeption und Installation der Testumgebung würden dementsprechend Leerlaufzeiten entstehen. Diese können vermindert werden, indem der Testmanager Teile der Konzeption der Testumgebung aus dem ursprünglichen Prozess extrahiert und vorzieht.

Zunächst wird die Installation der Testumgebung geplant und konzeptioniert. Parallel zur Konzeption ist der Einflussgrad des Configuration Managements als Unterstützung zu be-stimmen. (Siehe Abbildung B.31 auf Seite xxvi)

4.3.2.2.3. Prozess „Testumgebung installieren“ Der Prozess „Testumgebung instal-lieren“ besteht aus den zwei Sub-Prozessen „Testumgebung bereitstellen“ und „Testumge-bung warten“. Er erfolgt erst, wenn die Freigabe durch das Service Management erteilt wird.

Für diese Freigabe ist erforderlich, dass die Implementierung der Software sowie die entwick-lungseigenen Tests abgeschlossen sind und die notwendigen Dokumente dem Testmanagement übergeben wurden. (Siehe Abbildung B.32 auf Seite xxvi)

Sub-Prozess „Testumgebung bereitstellen“ Die in der Testablaufspezifikation doku-mentierte Testumgebung wird implementiert. Darauf aufbauend werden die notwendigen Testdaten generiert und die spezifizierten Testwerkzeuge installiert. Die Installation der ro-hen Testumgebung ist damit abgeschlossen und es erfolgt die Installation und Konfiguration des Testobjektes. Die Installation ist folgend auf ordnungsgemäße Ausführung zu überprüfen und wird ggf. angepasst, sodass die Testumgebung den Anforderungen der Testablaufspezifi-kation entspricht. Der Status der Testumgebung wird nach Beendigung der Implementierung den relevanten Stakeholdern kommuniziert. Sollte eine Beschreibung der produktiven Umge-bung existieren, so sollte diese den Stakeholdern mit einer Zusammenstellung über Abwei-chungen der Testumgebung zur Produktivumgebung zur Verfügung gestellt werden. (Siehe Abbildung B.33 auf Seite xxvii)

Sub-Prozess „Testumgebung warten“ Während die Testausführung erfolgt, wird die Testumgebung nach den Anforderungen der relevanten Spezifikationen in periodischen Ab-ständen und bei Konflikten, die die Testumgebung beeinflussen, gewartet. Der Status der Testumgebung wird in festgelegten Abständen anhand der Testablaufspezifikation den rele-vanten Stakeholdern kommuniziert. (Siehe Abbildung B.34 auf Seite xxviii)

4.3. Prozesse des TQC 4.3.2.2.4. Prozess „Test durchführen“ Innerhalb der Testdurchführung erfolgt nach der eigentlichen Ausführung der Vergleich der Testergebnisse. Diese werden in dem Test-konzept dokumentiert. Derweil erfolgt die Einforderung von Feedbacks der Tester bzgl. des Testprozesses. Der Testprozess wird mit dem Erfahrungsaustausch der Tester in dem Test-konzept dokumentiert. (Siehe Abbildung B.35 auf Seite xxviii)

Sub-Prozess „Test durchführen“ Bevor die Tests zur Ausführung kommen, werden die Tester über das Testobjekt geschult, wie es in dem Testkonzept festgelegt wurde. Folgend erfolgt die Durchführung der Testfälle anhand der Testfallspezifikation und der Testablauf-spezifikation. Die erkannten Fehlerzustände werden in einem Fehlerbericht dokumentiert und in einem Configuration Management System (CMS) erfasst. Innerhalb des CMS können die Fehlerzustände einem jeweiligen Entwickler des Service Managements zugeordnet werden, der dann das Debugging vornimmt.

Ist die Ausführung beendet, werden die Ergebnisse der Tests mit den Fehlerberichten doku-mentiert. (Siehe Abbildung B.36 auf Seite xxviii)

Sub-Prozess „Testergebnisse vergleichen“ Die Ergebnisse der Testausführung werden mit den erwarteten Ergebnissen verglichen. Die daraus resultierenden Ergebnisse werden be-stimmt. Das Testergebnis kann an dieser Stelle u.a. aufzeigen, dass die Testendekriterien nicht erreicht wurden oder andere Softwarekomponenten noch intensiver als bisher getestet werden sollten. In diesem Fall muss das Testmanagement mit entsprechenden Maßnahmen reagieren.

(Siehe Abbildung B.37 auf Seite xxix)

4.3.2.2.5. Prozess „Testendebericht erstellen“ Innerhalb des Prozesses „Testende-bericht erstellen“ werden zunächst die Testergebnisse analysiert und darauf aufbauend der finale Fehlerbericht erstellt. Ist die Testausführung nicht in der ersten Testphase erfolgt, wird der finale Fehlerbericht um die neuen Fehlerzustände erweitert oder korrigierte Defizite als geschlossen dokumentiert. Als Abschluss des dynamischen Testprozesses erfolgt die Mittei-lung an das Testmanagement, dass die Testendekriterien erreicht wurden und die Testphase abgeschlossen ist. (Siehe Abbildung B.38 auf Seite xxix)

Sub-Prozess „Testergebnisse analysieren“ Wurden in der Testausführung Fehlerzu-stände gefunden, wird aus der vorliegenden Dokumentation analysiert, ob ein Fehlernachtest erfolgte. Ist dieses geschehen, so werden die Ergebnisse des Fehlernachtests mit dem alten Fehlerbericht verglichen. Der Fehlerbericht wird darauf aktualisiert. Sollte kein Fehlernach-test erfolgt sein ist eine Analyse des Fehlerzustandes notwendig. Dieser wird anhand der Analyse in drei Kategorien priorisiert. „Niedrig“ hat zur Folge, dass keine weiteren Schritte zur Fehlerbereinigung erfolgen, da der Fehlerzustand nicht relevant ist. Im Falle der Priorisie-rung mit der Kategorie „Mittel“ wird dem Fehlerzustand ein Verantwortlicher zugeteilt. Die Priorisierung „Hoch“ hat zur Folge, dass eine Berichterstattung an das Testmanagement, an das Service Management und ggf. an die relevanten Stakeholder erfolgt.

Alternativ kann anstatt der von der ISO/IEC DIS 29119-2:2011-2012 vorgegebenen Kate-gorisierung der Fehlerzustände auch die Einstufung der IEEE 1044 (siehe [Ins10, Ins95]) erfolgen, wobei die Kommunikationswege gewahrt werden müssen. (Siehe Abbildung B.39 auf Seite xxx)

Abbildung 4.5.: Die Supportprozesse im Überblick 4.3.3. Supportprozesse

Supportprozesse unterstützen die Kernprozesse in ihrer Ausführung, indem sie die Basis für die Wertschöpfung stellen. Diese Prozesse sind nicht direkt an der Wertschöpfung des Unter-nehmens beteiligt, haben aber indirekt Einfluss auf diese (vgl. [BKR05, S. 7]).

Da sich die Supportprozesse aus einer Vielfalt an Bereichen zusammensetzen können, wird in der folgenden Betrachtung nur auf das Personal- und Skillmanagement eingegangen. Grund für die Wahl dieser zwei Prozesse ist die Gefahr von ineffizientem Personaleinsatz (vgl. [Spi08a, S. 268 f]) und der stetige Bedarf an Qualifikationen zum Thema Softwaretest. Besonders die Entwickler weisen einen Mangel an Schulungsmöglichkeiten auf, wie die Umfrage „Softwa-retest in der Praxis“ zeigt (vgl. [HSVW11, S. 29 ff]), aber auch Tester benötigen eine gute Ausbildung, um ihre Arbeit effizient zu gestalten (vgl. [HL10, S. 3 f]).

Die vorliegenden Supportprozesse sind vorwiegend dem TMMi® in der Version 3.1 entnom-men (vgl. [vV10, S. 91 ff]). Sie sind Bestandteil der spezifischen Ziele des Reifegrads drei. Die Einteilung erfolgte ursprünglich nach den spezifischen Zielen „Establish Test Functions for Test Specialists“, „Establish Test Career Paths“, „Establish an Organizational Test Training Capability“ und „Provide Necessary Test Training“. Für eine bessere Darstellung der Pro-zesse in den verantwortlichen Rollen wurde diese Einordnung nicht übernommen. Hingegen ist eine Zusammenfassung und Einteilung in die Prozessrollen „Personalmanagement“ und

„Skillmanagement“ erfolgt.

4.3. Prozesse des TQC