090827 ERP-EP Testmanagemenkonzept V8 0

Teilprojekt IT

Testmanagementkonzept

ERP-Einfhrung bei der Bundesagentur fr Arbeit

Version 8.0

Erstelldatum: 27. August 2009

Enterprise Resource Planning (ERP) Einfhrungsprojekt

BA/ SAP/ Accenture 2/108

090827_ERP-EP_Testmanagemenkonzept_V8.0.doc

Informationen ber das DokumentZustand: in Bearbeitung seit: 23.10.2008

vorgelegt am: 27.08.2009

akzeptiert / abgeschlossen: tt.mm.jjjj

Projektbezeichnung ERPEinfhrungsprojekt, Teil Projekt IT

Verfasser Bernd Honsa, SAP

Stefan Witt, Accenture

Sven Friess, SAP

Gesamtprojektleitung Herbert Pick, GPL, Bundesagentur fr Arbeit

Ralf Ott, GPL, SAP

Beate Kartte, stellvertr. GPL, Accenture

Thomas Holtmann, stellvertr. GPL, Accenture

Teilprojektleitung Teilprojekt IT

Thomas Kastl, TPL, Bundesagentur fr Arbeit

Roger Regitz, TPL, SAP

Ralf Haida, stellvertr. TPL, Accenture

Fachbereichs-verantwortung

Christian Wagner, Testkoordinator, Bundesagentur fr Arbeit

Dokument-Identifikation 090827_ERP-EP_Testmanagemenkonzept_V8.0.doc

Druckdatum / Anzahl Seiten 27.08.2009 / 108

Copyright ? 2009 Accenture/ SAP



nderungen

VersionNr. Datum

Genderte

SeitenBemerkungen Freigabe

0.1 23.10.08 Initiale Erstellung des Dokumentes

0.2 27.10.08 Review der Struktur

0.3 04.11.08 Integration der Template-Struktur

0.4 07.11.08 Ergnzungen zur Strategie

0.5 17.11.08 Ergnzung von Anforderungen

0.6 18.11.08 Anpassung Teststrategie

0.7 19.11.08 Anpassung der Teststufenbeschreibung

0.8 21.11.08 Anpassung der Kapitel Dokumentation undKommunikation im Test

0.9 26.11.08 Anpassung Kapitel Allgemeines,Testvorbereitung, Organisation

0.10 03.12.08/04.12.08/08.12.08

Einarbeitung Anmerkungen QMErgnzung Customizing Anforderungen QCEinarbeitung Anmerkungen GPL

0.11 09.12.08 Einarbeitung Anmerkungen GPL, Entfernungder Anglizismen, Umbenennung desDokuments

0.12 16.12.08 Einarbeitung Anmerkungen GPL SAP/ACNTeil 1 und 2

0.13 17.12.08 Einarbeitung Anmerkungen GPL SAP/ACNTeil 3

1.0 22.12.08 Abschluss der berarbeitung vorVerffentlichung

1.1 03.02.09 Einarbeitung Anmerkungen TPL SAP/ACN

2.0 09.02.09 Formale QS

2.1 06.03.09 Einarbeitung Review-Anmerkungen BA

2.2 12.03.09 Anpassungen zur Schlsselwort-basiertenNotation

2.3 19.03.09 Anpassung hinsichtlich Verlagerung desIntegrationstests in das Vorintegrationssystem

4.0 20.03.09 Formale QS

5.0 21.04.09 Anpassung des Kapitels 5.1.5, 5.2.2Ergnzungen aufgrund Review TP HR unddes Befundes der BA basierend auf Version4.0

6.0 04.06.09 Formale QS



6.1 17.06.09 Wrdigung Verifikation der Barrierefreiheit inAbschnitt 5.1.5Anpassung Abschnitt 7.2. quivalenzklassenAnpassung Abschnitt Testdaten in Abschnitt5.6.5.1 und 5.7

6.2 20.08.09 Folgende offene Punkte wurdeneinvernehmlich gelst:

? 27.11.08 2.2 Abstimmung mitden Teilprojektleitern sowie der SETFdurchfhren

? 27.11.08 5.7Testdatenmanagement wie erfolgtes? Ergnzung sptere Version

? 27.01.09: Abstimmung VorgehenMigrationstest/AnzahlMigrationstestlufe/Migrationswerkzeuge/Datenprfung

? 27.01.09: Testkonventionen fr denBetrieb; Abstimmung mitBetriebsfhrungsrahmenkonzeptdurchfhren

? 03.02.09 Was sind die Anforderungenan die betriebliche Abnahme (wird ineinem zu konstituierenden FachkreisTest- & Qualittsmanagementbehandelt/ Organisator ist Herr Dr.Philip Hartmann (BA))

8.0 27.08.09 Formale QS



Offene Punkte

Datumbetroffenes

KapitelKurzbeschreibung des offenen Punktes

Status/weiteresVorgehen

27.11.08 5.2.2.4.5 Systemtest Abrechnung und Prozesse vervollstndigen ZulieferungdesTeilprojektsPersonal

27.11.08 5.2.2.4.6 Paralleltest Beschreibung vervollstndigen ZulieferungdesTeilprojektsPersonal

27.01.09 3.1 Was ist die Liste der anzubindenden Verfahren? Und wieerfolgt die Integration von SETF?

KlrungSETF/TP-IT

02.02.09 Handling von SAP Standardfunktionalitten (z.B.Trennung der Rechtskreise, Abbildung derOrganisationshierarchie der BA)

AbstimmungGPL, TPL

14.05.09 5.2.2.3.3.,5.2.2.3.4,5.2.2.4.3.,5.2.2.4.4.

Namentliche Benennung der korrespondierenden BAFachbereiche fr die Mitwirkungsleistung

25.08.09 bertrag OP aus den Reviewbefunden ERP-EP_TMK_V4Rckmeldungen_incl-Matrix.xls [Stand25.08.09]

Punkt 40: Testdaten: Przisierung realittsnahe Daten

25.08.09 bertrag OP aus den Reviewbefunden ERP-EP_TMK_V4Rckmeldungen_incl-Matrix.xls [Stand25.08.09]

Punkt 40: Klrung QS der Modultests

26.08.09 Bezug auf OP8 Findings_Review_TMK_V6.13_CG.xls :

Das Testen mit Echtdaten jeglicher Art ist gernerellunzulssig und widerspricht dem Vorgehen in der BA.Ausnahmen bilden Lasttests, Migrations- und BI-Reportingtests. Fr diese sind jedoch nur anonymisierteEchtdaten zugelassen. Fr den Test der Funktionalittder Migrationsskripte sind auch synthetische Daten zuverwenden.

Weitere Nutzung von Echtdaten zu Testzwecken mussmit IT-Sicherheit abgestimmt werden.

Ebenso Abgleich von Tabelle 14 mit der Forderung vonwohldefinierten und reproduzierbaren Startzustnden.

berarbeitung Tabelle14



Datumbetroffenes

KapitelKurzbeschreibung des offenen Punktes

Status/weiteresVorgehen

27.08.09 Vorgehensweise bei Risikoanalyse und Ableitung derTestflle an Projektvorgehen angleichen



Abkrzungsverzeichnishttps://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/01-Projektmanagement/06-Projekthandbuch

Abkrzung Beschreibung

SEA Systementwicklung Geschftsbereich Architektur

SETF Systementwicklung Geschftsbereich Testfactory

SETF1 Systementwicklung Geschftsbereich Testfactory Service Fachlicher Test

SETF2 Systementwicklung Geschftsbereich Testfactory Service Technischer Test



AnlagenverzeichnisAnlage-Nr. Titel Dateiname

Firma/Verlag

Stand/Version

1 Fachgrobkonzept C.6Projektorganisation

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/01-Projektmanagement/10-Allgemeine_Informationen/02-Fachgrobkonzept_pdf/080806_ERP-EP_Fachgrobkonzept_C.6_v1-0.pdf

SAP/BA

2 RahmenkonzeptImplementierungsrichtlinien (1.Stufe)

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/04-TP_IT/04-Konzepte/03-Implementierungsrichtlinien/081114_ERP_RahmenkonzeptImplementierungsrichtlinien (Stufe 1)V1.1_TST.doc

SAP

3 Mandanten &Transport Konzept

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/04-TP_IT/04-Konzepte/02-Mandanten-Transportkonzepte/

SAP/ACN

4 ProjekthandbuchERP

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/01-Projektmanagement/06-Projekthandbuch/

SAP/ACN

5 BA ERPDokumententemplate

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/01-Projektmanagement/07-Projektstandards_Templates/081017_ERP-EP_Word_Template.dot

SAP/ACN

6 BA SETFTestkonzeptTemplate

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/06-Zentrale_Projektfunktionen/04-Qualitaetsmanagement/03-Testkonzepte/05-BA_Konzepte/Template Testkonzept-BA.doc

BA

7 BA SETFVorbereitung ReviewSAP-Testkonzept

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/06-Zentrale_Projektfunktionen/04-Qualitaetsmanagement/03-Testkonzepte/05-BA_Konzepte/081112_SETF_Teststufen_fr_ERP_0.2.doc

BA

8 ArchitekturkonzeptSystemlandschaftund Sizing

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/04-TP_IT/04-Konzepte/01-Systemlandschaft/01-

SAP/ACN 18.02.2009/Version1.1



Anlage-Nr. Titel Dateiname

Firma/Verlag

Stand/Version

Systemlandschaft_Sizing/090218_ERP-EP_Architekturkonzept_Systemlandschaft_Sizing_v1.1.doc

9 Fachgrobkonzept C.5 https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/01-Projektmanagement/10-Allgemeine_Informationen/02-Fachgrobkonzept_pdf/080730_ERP-EP_Fachgrobkonzept_C.5_v1-0.pdf

SAP/BA

10 bersicht derSchlsselwrter undihrer Verwendung

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/06-Zentrale_Projektfunktionen/04-Qualitaetsmanagement/03-Testkonzepte/05-BA_Konzepte/Nutzungskonzept_Schlsselwrter.doc

BA

11 KonzeptAnforderungsanalyse-und Management

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/04-TP_IT/04-Konzepte/03-Implementierungsrichtlinien/01-Anforderungsmanagement

SAP

12 KonzeptGeschftsprozessmodellierung

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/04-TP_IT/04-Konzepte/03-Implementierungsrichtlinien/02-Gesch%c3%a4ftsprozessmodellierung/

SAP

13 KonzeptImplementierung

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/04-TP_IT/04-Konzepte/03-Implementierungsrichtlinien/03-Implementierung

SAP

14 Einsatzkonzept SAPQuality Center by HP

Erste Version Ende April 2009 SAP

15 Einsatzkonzept SAPQuick TestProfessional by HP

Erste Version Ende April 2009 SAP

16 Customizing-Handbuch QualityCenter by HP

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/06-Zentrale_Projektfunktionen/04-Qualitaetsmanagement/03-Testkonzepte/02-Einsatzkonzept_QualityCenter

SAP

17 Customizing-Handbuch SAP QuickTest Professional by

Erste Version Ende Januar 2008 SAP




Firma/Verlag

Stand/Version

HP

18 ERP FreigabeAbnahmeprozess

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/06-Zentrale_Projektfunktionen/04-Qualitaetsmanagement/01-QM_QS-Handbuch

19 Dokumentation derTestobjekte aus denFachteams

SAP/ACN

20 ERP EP Glossar https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/01-Projektmanagement/06-Projekthandbuch

SAP/ACN

21 Testobjekte imKomponententest

Erstellung in den TeilprojektenSAP/ACN

SAP/ACN

22 Testobjekte imModultest


SAP/ACN

23 Testobjekte imIntegrationstest


SAP/ACN

24 Testobjekte imSystemtest


SAP/ACN

25 Teilprojekt FinanzenDatenmigrationSollkonzept

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/02-TP_Finanzen/04-Konzeption/04-Design/02-Migration/

SAP/ACN

26 Teilprojekt PersonalSollkonzept Migrationder Altdaten

SAP/ACN

27 ERPRisikomanagement

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/06-Zentrale_Projektfunktionen/03-Risikomanagement/

SAP/ACN

28 Zusammenhangzwischen Anforder-ungen und Testfllen

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/06-Zentrale_Projektfunktionen/04-Qualitaetsmanagement/03-Testkonzepte/01-Rahmenkonzept_Testmanagement/090512_ERP-EP_Anforderungen_zu_Testfllen_FH_V1.1.ppt

SAP/ACN

29 StufenkonzeptIncident Managementim SAP

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/04-TP_IT/04-Konzepte/04-

SAP/ACN




Firma/Verlag

Stand/Version

Applikationsumfeld Betriebsfuehrungsrahmenkonzept/Incident%20Management/

30 StufenkonzeptBackup und Recoveryim SAPApplikationsumfeld

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/04-TP_IT/04-Konzepte/04-Betriebsfuehrungsrahmenkonzept/Backup%20und%20Recovery

31 BasiswissenSoftwaretest

Dpunkt.verlag

3. Auflageaus 2005

32 Betriebsfhrungshandbuch

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/04-TP_IT/04-Konzepte/04-Betriebsfuehrungsrahmenkonzept/(10)%20Betriebshandbuch

SAP/ACN

33 GesamtkonzeptMigration

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/07-Entwicklungsobjekte/05-Migration/01-Uebergreifende_Themenstellungen/02-Konzeption

SAP/ACN 2.1

34 ERP EPWartungskonzept

https://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/04-TP_IT/04-Konzepte/04-Betriebsfuehrungsrahmenkonzept/(20)%20Betriebsfuehrungskonzepte/Wartungskonzept

SAP/ACN

Glossarhttps://erp.arbeitsagentur.de/Phase4_ERP-Implementierung/01-Projektmanagement/06-Projekthandbuch



Inhaltsverzeichnis1 Management Summary ....................................................................................................... 172 Allgemeines ......................................................................................................................... 18

2.1 Einordnung in den Gesamtzusammenhang...........................................................................18

2.2 Ziele des Dokuments ..............................................................................................................18

2.3 Grundlage des Dokuments, Abhngigkeiten und Abgrenzung ............................................18

2.3.1 Mitgeltende Detailkonzepte .................................................................................. 18

2.3.2 Anwenderhandbcher Werkzeuge........................................................................ 18

2.3.3 Customizing Dokumente ...................................................................................... 192.4 Struktur des Dokuments .........................................................................................................19

3 Ergebnisse der Ist-Analyse ................................................................................................. 203.1 Vorhandene Struktur / Systeme / Daten .................................................................................20

4 Anforderungen ..................................................................................................................... 214.1 Anforderungen aus dem Grobkonzept ...................................................................................21

5 Konzept ................................................................................................................................ 245.1 Teststrategie............................................................................................................................24

5.1.1 Risikobehandlung ................................................................................................. 24

5.1.2 Verwendete Richtlinien und Normen .................................................................... 26

5.1.3 Leistungskennzahlen fr den Test ........................................................................ 30

5.1.4 Qualittsmerkmale und Gewichtung ..................................................................... 35

5.1.5 Nicht zu testende Komponenten und Qualittsmerkmale ..................................... 365.2 Teststufen und Methoden .......................................................................................................36

5.2.1 System- und Testlandschaft ................................................................................. 37

5.2.1.1 XXE-System ...................................................................................................... 38

5.2.1.2 XXV-System ...................................................................................................... 39

5.2.1.3 XXI-System ........................................................................................................ 39

5.2.1.4 XXP-System ...................................................................................................... 39

5.2.2 Teststufen ............................................................................................................ 41

5.2.2.1 Testmethoden .................................................................................................... 41

5.2.2.2 Komponententest ............................................................................................... 45

5.2.2.3 Modultest ........................................................................................................... 46

5.2.2.4 Integrationstest .................................................................................................. 49

5.2.2.5 Systemtest ......................................................................................................... 52

5.2.2.6 Akzeptanztest .................................................................................................... 62

5.2.2.7 Produktivsimulation (Teilprojekt FI) .................................................................... 63

5.2.3 Verteilung in der Systemlandschaft ...................................................................... 63



5.3 Dokumentation im Test ...........................................................................................................63

5.3.1 Dokumenttypen .................................................................................................... 63

5.3.2 Dokumentvorlagen ............................................................................................... 65

5.3.3 Ablage der Dokumente ......................................................................................... 65

5.3.4 Verwendete Werkzeuge ....................................................................................... 665.4 Kommunikation im Test ..........................................................................................................66

5.4.1 Projektkommunikation .......................................................................................... 66

5.4.2 Berichtswesen ...................................................................................................... 67

5.4.3 Eskalationswege .................................................................................................. 685.5 Testablauf ................................................................................................................................69

5.5.1 Eingangskriterien fr die Teststufen ..................................................................... 70

5.5.2 Ausgangskriterien fr einen Testlauf .................................................................... 70

5.5.3 Testvorbereitung .................................................................................................. 71

5.5.3.1 Testfallerstellung ................................................................................................ 74

5.5.3.2 Herstellung des Startzustands fr einen Testzyklus ........................................... 76

5.5.3.3 Testautomatisierung........................................................................................... 76

5.5.4 Testfalldurchfhrung ............................................................................................. 77

5.5.5 Testauswertung und Fehlermanagement ............................................................. 78

5.5.5.1 Anwendung Quality Center ................................................................................ 78

5.5.5.2 Fehlerklassen..................................................................................................... 83

5.5.5.3 Reaktionszeiten ................................................................................................. 84

5.5.6 Bewertung des Testabschlusses .......................................................................... 84

5.5.6.1 Teststufe Komponententest und Modultest ........................................................ 84

5.5.6.2 Teststufe Integrationstest ................................................................................... 84

5.5.6.3 Teststufe Systemtest.......................................................................................... 855.6 Organisation ............................................................................................................................86

5.6.1 Testplanung ......................................................................................................... 86

5.6.2 Projektorganisation ............................................................................................... 87

5.6.3 Testteam .............................................................................................................. 87

5.6.3.1 Testmanager ...................................................................................................... 88

5.6.3.2 Teilprojekt-Testkoordinator................................................................................. 88

5.6.3.3 Test-Designer .................................................................................................... 89

5.6.3.4 Testautomationsexperte ..................................................................................... 89

5.6.3.5 Tester ................................................................................................................ 89

5.6.4 Weitere Rollen im Test ......................................................................................... 89

5.6.4.1 Projekt Manager ................................................................................................. 89



5.6.4.2 Projekt Qualittsmanager ................................................................................... 90

5.6.4.3 Anforderungsmanager ....................................................................................... 90

5.6.4.4 Entwickler/Customizer ........................................................................................ 90

5.6.4.5 Teamleiter Entwicklung/Teilprojektleiter ............................................................. 90

5.6.4.6 Testsystem Administrator ................................................................................... 90

5.6.4.7 Transport Manager ............................................................................................ 90

5.6.4.8 bersicht zu den Verantwortlichkeiten ............................................................... 90

5.6.4.9 Bentigte Ausbildungsmanahmen sowie Einarbeitungsmanahmen ............... 92

5.6.5 Konfigurationsmanagement .................................................................................. 92

5.6.5.1 Anforderungen an eine kontrollierbare und reproduzierbare Testumgebung ...... 92

5.6.5.2 Transportauftrge .............................................................................................. 93

5.6.5.3 SAP Support Packages und Patches ................................................................. 945.7 Testdaten Management...........................................................................................................94

6 Richtlinien ............................................................................................................................ 997 Anhang ............................................................................................................................... 101

7.1 Glossar ..................................................................................................................................101

7.2 Begriffe ..................................................................................................................................101



AbbildungsverzeichnisAbbildung 1: Qualittsmanagement - Inhalte und Einordnung im Projekt ...................................... 17

Abbildung 2: Vorgehensmodell fr die verschiedenen Teststufen ................................................. 27

Abbildung 3: Darstellung der Beziehung Anforderung, Testfall, Testobjekt ................................... 28

Abbildung 4: Darstellung der Relation zwischen Anforderung, Testfall, Testobjekt........................ 33

Abbildung 5: Zusammenspiel der Komponenten in der ERP Systemlandschaft ............................ 37

Abbildung 6: SAP ERP System- und Testlandschaft ..................................................................... 38

Abbildung 7: Teststufen ................................................................................................................ 41

Abbildung 8: Anbindungsszenario BA-Fachverfahren ? ERP-System .......................................... 51

Abbildung 9: Ablaufplanbeispiel - Migrationstest HR (Massen-Datenbernahme) ......................... 57

Abbildung 10: Migrationsphasen in der Integrationsumgebung ..................................................... 58

Abbildung 11: Verteilung der Tests in der SAP ERP Systemlandschaft ........................................ 63

Abbildung 12: Kommunikation in der Phase Testvorbereitung ...................................................... 68

Abbildung 13: Kommunikation in der Phase Testdurchfhrung ..................................................... 68

Abbildung 14: Testablauf .............................................................................................................. 69

Abbildung 15: bersicht der Anforderungsdokumente .................................................................. 72

Abbildung 16: bersicht Schritte zur Testfallerstellung.................................................................. 73

Abbildung 17: Bestimmung der Testfallermittlungsmethode .......................................................... 73

Abbildung 18: Zusammenhang Testfall, Testschritt und Testsuite ................................................. 74

Abbildung 19: Quality Center Fehlerbeschreibung ........................................................................ 79

Abbildung 20: Statusbergangsdiagramm fr das Fehlermanagement ......................................... 80

Abbildung 21: Statusbergangsdiagramm fr den Detailprozess Fehlerprfung ......................... 81

Abbildung 22: Testplanung Personal............................................................................................. 86

Abbildung 23: Testplanung Finanzen ............................................................................................ 87

TabellenverzeichnisTabelle 1: Anforderungen .............................................................................................................. 23

Tabelle 2: Projekt- und Produktrisiken ........................................................................................... 26

Tabelle 3: Monitoring der Teststufen im Gesamtprojekt ................................................................ 34

Tabelle 4: Gewichtung der Qualittskriterien ................................................................................. 36

Tabelle 5 Kriterien fr die Risikobewertung der Testobjekte .......................................................... 42

Tabelle 6: bersicht Prfverfahren je Testobjekt und Teststufe .................................................... 44

Tabelle 7: Dokumentenvorlagen ................................................................................................... 65

Tabelle 8: Einsatz der Testwerkzeuge pro Teststufe ..................................................................... 66

Tabelle 9: Eingangskriterien der Teststufen .................................................................................. 70

Tabelle 10: Ausgangskriterien fr einen Testlauf........................................................................... 71



Tabelle 11: Fehlerklassen ............................................................................................................. 84

Tabelle 12: Testorganisationsstruktur ........................................................................................... 87

Tabelle 13: Verantwortlichkeiten pro Teststufe .............................................................................. 92

Tabelle 14: Testdatenanforderungen ............................................................................................ 98

Tabelle 16: Vorgehensweise Black-Boxtest ................................................................................ 102

Tabelle 17 Beispiel fr Vorgnger-Nachfolger-Matrix .................................................................. 107

Tabelle 18 Ergebnis fr Beispiel der Vorgnger-Nachfolger-Matrix ............................................. 107

Tabelle 19: Testaufgaben im White-Box Test .............................................................................. 108



1 Management SummaryDas Testmanagementkonzept gibt den Rahmen fr die Planung und Durchfhrung derTestaktivitten im Projekt vor. Hierbei werden Festlegungen bzgl. der zu absolvierendenTeststufen und die Vorgehensweisen inkl. Testmethodik sowie Testablauf betrachtet. Es enthltauch die Aufstellung der Testorganisation mit den Verantwortlichkeiten in den einzelnenTestphasen (Planung, Vorbereitung, Durchfhrung, Auswertung).

Die folgende Abbildung zeigt die Einbindung der Qualittssicherung Software imQualittsmanagement auf.

Abbildung 1: Qualittsmanagement - Inhalte und Einordnung im Projekt

Das Testmanagementkonzept schafft die Voraussetzungen fr eine effektive Qualittssicherungder Softwareprodukte im Projekt. Fachliche Konzepte und die Architektur sind in weiterenDokumenten beschrieben, die im Anlagenverzeichnis auf Seite 8 aufgezhlt werden.



2 Allgemeines

2.1 Einordnung in den GesamtzusammenhangDas vorliegende Testmanagementkonzept wird von der zentralen ProjektfunktionQualittsmanagement erstellt und gepflegt. Seine Regelungen gelten im Gesamtzusammenhangdes bergeordneten ERP Projekthandbuchs, siehe [4] im Anlagenverzeichnis.

2.2 Ziele des DokumentsZiel des allgemeinen Testmanagementkonzeptes ist die Definition der einheitlichenRahmenbedingungen fr die Durchfhrung der Tests im Projekt ERP der BA.

Der Schwerpunkt des Konzeptes liegt auf der Entwicklung und Beschreibung eines projekt-bergreifenden Gesamtkonzeptes fr das Testmanagement und der zugrunde liegendenWerkzeuge. Es werden die wesentlichen Prozessschritte, Werkzeuge und Richtlinien im berblickbeschrieben.

Die im vorliegenden Dokument enthaltenen Richtlinien sind verbindlich. Sie wurden im Rahmenvon Workshops mit den Teilprojektleitern (SAP/ACN/BA) und der Gesamtprojektleitungabgestimmt. Um die berprfung der Einhaltung des Konzeptes zu vereinfachen, werden die indiesem Testmanagementkonzept verfassten Richtlinien besonders hervorgehoben, eineZusammenfassung aller Richtlinien findet sich in Kapitel 6.

2.3 Grundlage des Dokuments, Abhngigkeiten und AbgrenzungGrundlage des Rahmenkonzepts sind die im Fachgrobkonzept C.6 Projektorganisation [1] imAnlagenverzeichnis formulierten Anforderungen an den Entwicklungsprozess und insbesonderedessen Werkzeuguntersttzung (zu den Anforderungen siehe Kapitel 4).

Nicht betrachtet werden die folgenden Punkte:

? Projektmanagement? Qualittsmanagement (QS Dokumente, KPV)? Dokumentenmanagement? Breitstellung von Dokumentenvorlagen? Inhaltliche Ausarbeitung der Themenfelder? Anforderungs- und nderungsmanagement? Betriebskonzepte1

2.3.1 Mitgeltende Detailkonzepte

Ergnzend zu dem vorliegenden Testmanagementkonzept gelten die nachfolgendenDetailkonzepte zu den oben genannten Bereichen.

? Anforderungsanalyse- und Management, siehe [11] im Anlagenverzeichnis.? Geschftsprozessanalyse, siehe [12] im Anlagenverzeichnis.? Implementierung, siehe [13] im Anlagenverzeichnis.

2.3.2 Anwenderhandbcher Werkzeuge

Zu den in diesem Testmanagementkonzept referenzierten Werkzeugen werdenAnwenderhandbcher vorliegen, die grundlegende Informationen (z. B. Beantragen desSystemzugangs, An- und Abmelden, Allgemeine Administration) bereitstellen:

1 Die Behandlung von Regressionstests in Wartung & Betrieb wird in Anlage [34] beschrieben.



? SAP Quality Center by HP, siehe [14] im Anlagenverzeichnis.

? SAP Quick Test Professional by HP, siehe [15] im Anlagenverzeichnis.Vorgehensspezifische Aspekte der Werkzeugnutzung z. B. im Rahmen der Anforderungsanalysewerden jedoch in der Regel in den jeweiligen Detailkonzepten beschrieben (siehe Abschnitt 2.3.1).

2.3.3 Customizing Dokumente

Auf Basis des vorliegenden Konzeptes und der anderen Detailkonzepte werden die eingesetztenWerkzeuge konfiguriert. Die zugehrige Spezifikation und Dokumentation dieser Konfiguration frdie Werkzeuge ist in den folgenden Dokumenten beschrieben.

? SAP Quality Center by HP, siehe [16] im Anlagenverzeichnis.

? SAP Quick Test Professional by HP, siehe [17] im Anlagenverzeichnis.

2.4 Struktur des DokumentsDie fr die Entwicklung des Testmanagementkonzeptes mageblichen Anforderungen aus denFachgrobkonzepten und der aktuelle Diskussionstand zu diesen Anforderungen werden im Kapitel4.1 Anforderungen aus dem beschrieben.

Kapitel 5 Konzept enthlt einleitend einen berblick ber die Gesamtmethodik und dieWerkzeuglandschaft. Die Methodik wird in den folgenden Abschnitten des Kapitels genauerbeschrieben, wobei verbindliche Regelungen in Form von Richtlinien besonders hervorgehobenwerden.

Kapitel 6 Richtlinien fasst die im Kapitel 5 genannten Richtlinien noch einmal zusammen, um diesptere berprfung der Einhaltung zu erleichtern.



3 Ergebnisse der Ist-Analyse

3.1 Vorhandene Struktur / Systeme / DatenDie Ist-Analyse der vorhandenen Strukturen bei der BA hat folgendes ergeben:

1. Die BA betreibt eine Testfactory (Abkrzung SETF), welche Testdienstleistungen innerhalbder BA anbietet. Dazu gehren auch die Vorbereitung, Durchfhrung sowie Auswertung vonPerformance- und Systemintegrationstests. Das IT-Systemhaus und damit auch die SETFarbeitet dabei nach dem Standard ISTQB2.

2. Bei der BA werden fr das Testmanagement der Borland SilkCentral Test Manager, fr dieTestautomatisierung Borland SilkTest und fr Lasttests Borland SilkPerformer eingesetzt.Innerhalb der BA gibt es darber hinaus einzelne Entwicklungsprojekte, die, abweichend zuden soeben genannten, andere Testwerkzeuge einsetzen. Dies ist allerdings historischbedingt.

3. SETF setzt fr die Testfallbeschreibungen eine Schlsselwort-basierte Notation ein, siehe[10] im Anlagenverzeichnis.

4. Fr den Test von SAP Anwendungen gab es vor Start dieses Projektes keine SAPTestsysteme und damit keine Testdaten in SAP.

5. Die BA nutzt fr ihre Testplanung ein Testkonzept-Template, siehe [6] imAnlagenverzeichnis.

6. Externe Testsysteme, welche im Rahmen der Integrationstests fr die berprfung derexternen Schnittstellen bentigt werden, mssen ber die SETF beauftragt werden. Dafrgibt es die Testumgebung TU2.

2 ISTQB International Standard Testing Qualifications Board (www.istqb.org)



4 Anforderungen

4.1 Anforderungen aus dem GrobkonzeptDie fachlichen und technischen Anforderungen an das neue ERP System, die in denFachgrobkonzepten beschrieben wurden, werden ins Quality Center ein gepflegt. JedeAnforderung muss mindestens in einem Testfall abgebildet werden um eine 100%igeTestabdeckung aller Anforderungen zu gewhrleisten3. Diese fachlichen Anforderungen sind vomAnforderungsmanagement im Quality Center dokumentiert und werden in diesemTestmanagementkonzept nicht weiter erlutert oder aufgelistet.

Die im Grobkonzept aufgefhrten Anforderungen (siehe Anlage 1 im Anlagenverzeichnis) die ausprojektorganisatorischer Sicht eine Relevanz fr das Testmanagement haben, sind in diesemTestmanagementkonzept in den entsprechenden Kapiteln bercksichtigt worden.

Name Anfor-derungs-

typ

Grob-konzept-Kapitel

Beschreibung Seite

SolutionManager

Grobkonzeptanforderung

C.6.3.1. Der SAP Solution Manager ist das zentraleEinfhrungswerkzeug und bietet die Integration in dieproduktive Phase eines ERP-Lebenszyklus an, in derdie Aufgaben im Betrieb, Support und berwachunguntersttzt werden.

43

Parallellauf Grobkonzeptanforderung

C.6.3.1.6. Im Bereich der Bezgeabrechnung ist ein Paralleltestvor der Produktivsetzung erforderlich. 52

Verantwort-lichkeiten


C.6.3.1.6. Das Entwicklungsberaterteam ist verantwortlich fr dieDurchfhrung der Modultests, Integrationstests undLast- und Performancetests, sowie den Systemtests.

86

Systemtest Grobkonzeptanforderung

C.6.3.1.6. Systemtests dienen als so genannte Vor-Abnahmetests, durchgefhrt von BA Endanwendern.Hierbei wird der Systemtest nicht parallel undgleichfrmig in allen dezentralen Bereichendurchgefhrt, sondern stellvertretend ein Test jeFunktionalittenkombination durchgefhrt. Basis sinddie Testflle aus dem Integrationstest.

87

Produktiv-freigabe


C.6.4.1. Nach dem erfolgreichen Abschluss des Tests wird dieFreigabe fr die Produktivsetzung durch denEntwicklungsleiter, das Rollout-Team sowie die frden Rollout verantwortlichen Mitarbeiter auf Seitender betroffenen Bereiche erteilt, so dass derProduktivbetrieb und damit die produktive Nutzungdes SAP ERP-Systems durch die Mitarbeiter der BAaufgenommen werden kann. Gleichzeitig wird dieVerantwortung fr den Produktivbetrieb der neuenFunktionalitten und aus dem Projekt in dieVerantwortung der Betriebsorganisation bergeben.

87

Testdoku-mentation


C.6.4.1.1. Funktions-, Performance- und Lastprfungen mssenprotokolliert werden. 96

Modultest Grobkonzeptanfor

C.6.4.1.1. Im Modultest werden die Funktionalitten auf ihregenerelle Funktionstchtigkeit berprft 98

3 SAP Standardfunktionalitten (z.B. Sortieren von Tabellen) werden nicht explizit mittels eigener Testflle geprft.



Name Anfor-derungs-

typ


Beschreibung Seite

derung

Integrationstest 1


C.6.4.1.1. Im Integrationstests werden einzelne Funktionalittenim Zusammenspiel mit angrenzenden Funktionalitteninnerhalb des ERP-Systems sowie zu anzubindendenVerfahren getestet

98

Testdaten Grobkonzeptanforderung

C.6.4.1.1. Der Test der Funktionalitten erfolgt hierbei mitrealittsbezogenen Testdaten, welche reprsentativfr die BA stehen.

98

Produktiv-start


C.6.4.1.1. Der Produktivstart wird im Rahmen eines Produktiv-bzw. Systemstests (bzw. erweiterten Systemtests imTeilprojekt Finanzen) vorbereitet, in welchem diegrundstzlichen Geschftsprozesse des jeweiligenRollout-Bereiches anhand von realen Testdaten undSAP-Benutzerrollen (Zugriffsberechtigungen) voll-stndig getestet werden.

98

Migrations-test


C.6.4.2.1. Nach erfolgreichem Abschluss des Produktiv- bzw.(erweiterten) Systemtests folgt nach entsprechendenerfolgreichen Migrationstests die Produktivmigrationder fr den Produktivbetrieb notwendigen underforderlichen Datenstrukturen.

99

Geschfts-prozess-modell


C.6.4.2.1. Basierend auf den im SAP Solution Manager und imSAP Quality Center hinterlegtenGeschftsprozessmodellen werden die folgendenTestschritte mit Untersttzung des SAP QualityCenter by HP durchgefhrt:- Erstellen eines Testplanes auf der Basis derSollkonzept-Prozess-Struktur fr die jeweiligeTeststufe- Definition von Testpaketen zum Testplan,- Durchfhrung der Tests: manuell bzw. automatisiert,- Integrierte Fehler/Rckmeldung und Retests,- Ergebnismonitoring und -verfolgung

106

Testergeb-nisse


C.6.4.3. Nachhalten der Testergebnisse: Das Nachhalten derTestergebnisse geschieht durch Ergebnismonitoringund -verfolgung sowohl im SAP Quality Center by HPals auch im SAP Solution Manager.

106

FachlicheSystemtests


C.6.4.3. Fachlichen Systemtests: Diese komplettenSystemtests sind bei bergabe an den AG zurWeiterverwendung als Regressionstests zubergeben.

111

Integrationstest 2


C.6.4.3. Integrationstests: Zur Durchfhrung derSchnittstellentests zu allen beteiligten Verfahren inAbstimmung mit dem Releasemanagement (richtigeSW-Versionen) sind Testflle zu erstellen und an denAG zu bergeben.

111

Lasttest Grobkonzeptanforderung

C.6.4.3. Neben Funktionstests sollen zustzlich Last- undPerformancetests durchgefhrt werden, umsicherzustellen, dass das ERP-System auch unterBelastung noch den zugesicherten

111



Name Anfor-derungs-

typ


Beschreibung Seite

Leistungen/Qualitten gerecht wird.Transak-tionsmix


C.6.4.3.3. Fr den Lasttest soll ein realittsnaherTransaktionsmix produziert werden, um dieWechselwirkungen zwischen Transaktionen zusimulieren.

111

Testflle Grobkonzeptanforderung

C.6.4.3.4. Die im Rahmen der Testphasen abzuarbeitendenTestflle und Testskripte sind ber Werkzeuge wieBorland Silk und/ oder den SAP Solution Managerabbildbar.

124

Reporting Grobkonzeptanforderung

C.6.4.3.4. Die Durchfhrung der Messungen der ERP-Komponenten und -Funktionen erfolgt nach der V-Modell Methode, dem mehrstufigen Testvorgehen,das zum V-Modell 97 weiterentwickelt wurde.

124

Testvor-gehen


Im mehrstufigen Testvorgehen kann in der Regel erstmit der nchsten Stufe des Tests begonnen werden,wenn die vorherige Teststufe erfolgreichabgeschlossen wurde.

124

Tabelle 1: Anforderungen



5 Konzept

5.1 TeststrategieDas Ziel aller Tests ist die Verifikation der Produktqualitt und der Nachweis der Einsatztauglich-keit. Die zu testende Software soll unter mglichst produktionsnahen Bedingungen ablaufen unddabei die spezifizierten Anforderungen erfllen. Vorhandene Fehler, Mngel und Problememssen dabei aufgedeckt werden, um sie vor der Produktivschaltung zu beseitigen oderbeherrschbar gestalten zu knnen.

Eine Teststrategie definiert den Rahmen fr die Testphase aus methodischer Sicht und umfasstdabei:

? die Benennung der fr die Testvorbereitung und -durchfhrung relevanten Richtlinien undNormen

? eine Analyse der Qualittsrisiken im Projekt? eine Aufstellung der Kennzahlen fr die berwachung der Testvorbereitung und -

durchfhrung

? eine Gewichtung der zu testenden Qualittsmerkmale

Ein System vollstndig auszutesten ist in der Praxis nicht bzw. nur mit sehr hohem Aufwandmglich. Deshalb ist effizient und kostenbewusst zu testen, d.h.

? zielgerichtet (zur Konzentration der knappen Ressourcen),? die wichtigsten Risiken abdeckend,? mit systematisch ausgewhlten Testfllen, inkl. Sonderfllen.

Alle definierten Manahmen und Abgrenzungen sollen eine mglichst groe Testabdeckung in derzur Verfgung stehenden Zeit ermglichen.

Notwendige Testwiederholungen knnen durch den Einsatz von Testautomationswerkzeugenwirtschaftlicher gestaltet werden.

5.1.1 Risikobehandlung

Im Risikomanagement werden Risiken identifiziert und bewertet, Risikostrategien festgelegt undeingeleitete Manahmen berwacht. Die Gesamtprojektleitung ist verantwortlich fr allebergreifenden Risiken des ERP Projektes (siehe dazu Anlage [27] im Anlagenverzeichnis).

Manahmen zur Minderung eines Risikos, die die Teststrategie betreffen, werden durch dieGesamtprojektleitung kommuniziert und das Testvorgehen ggf. angepasst.

Folgende bisher identifizierte Projekt- und Produktrisiken knnen eine erfolgreicheTestdurchfhrung gefhrden:



Nr. Kriterium Beschreibung

Projektrisiko1

MehrereTeilprojekte

Die geforderte Lsung wird in mehreren Teilprojekten wobei zweiTeilprojekte in mehreren Referenzmodellen planen erstellt. Diese habenfunktionale Abhngigkeiten und pro Referenzmodell existierenunterschiedliche Zieltermine.

Hierdurch erhhen sich die Komplexitt und der Abstimmungsaufwandwhrend der Testphase.

Die Definition des Testumfangs je Testphase innerhalb der Fachteamsobliegt den jeweiligen Teilprojektleitern bzw. im Teilprojekt IT demEntwicklungsleiter.

Manahmen:

Bei den Integrations- und Systemtests wird vorausgesetzt, dass alleTeilprojekte termingerecht ihre Teillsung abliefern. Werden kritischeFehler entdeckt, muss eine zeitnahe Fehlerbehebung gewhrleistetwerden.

Des Weiteren werden die Testflle fr das vorangegangeneReferenzmodell im zu prfenden Referenzmodell als Regressionstestausgefhrt. Ausgewhlte Testflle aus vorangegangenen Teststufenwerden vor Beginn eines Testzyklus4 einer Teststufe ausgefhrt, so z.B.Testflle aus dem Modultest vor Beginn eines Integrations- oderSystemtestzyklus auf dem XXV- bzw. XXI-System.

Der Testmanager muss eine enge und frhzeitige Abstimmung bzgl.Inhalt und Zeitplanung der Tests mit den Verantwortlichen der einzelnenTeilprojekte durchfhren.

Produkt-risiko 2

Einsatz neuerTechnologien

Mit SAP ERP5 wird eine in vielen Projekten bewhrte, fr denAuftraggeber jedoch neue Technologie eingefhrt. Erfahrungen undmgliche Seiteneffekte im IT-Umfeld des Auftraggebers mssen im Laufeder Test- und Pilotierungsphase noch evaluiert werden.

Manahmen:

Der Auftraggeber muss unaufgefordert Informationen ber seinTestvorgehen, seine Systemumgebung und mgliche Seiteneffektebereitstellen, um einen reibungslosen Test des Auftragnehmers zuermglichen.

Bereits bestehende Funktionalitt der Umsysteme und Fremdverfahrenwird nur dann im Rahmen eines Regressionstests getestet, wennSeiteneffekte durch neue Funktionen zu erwarten sind.

4 Ein Testzyklus ist die Ausfhrung aller geplanten Testflle einer Teststufe gegen ein einfaches identisches Release/Version einesTestobjekts, an dessen Ende Fehlerkorrektur- oder nderungsauftrge fr die Entwickler vorliegen.5 Erklrungen zu den Abkrzungen finden sich im Anhang.



Nr. Kriterium Beschreibung

Projektrisiko3

Fester Endtermin Fr den Auftraggeber hat die Fertigstellung der Gesamtlsung bis zum31.12.20116 hchste Prioritt. Durch den engen Zeitrahmen ist esnotwendig, die Testabdeckung auf ein sinnvolles Ma zu reduzieren undein hohes Ma an Effizienz einzubringen, ohne die gefordertenQualittsanforderungen zu reduzieren. Es knnten mglicherweiseweitere Kosten entstehen, um erfahrene Mitarbeiter aus dem BereichTestmanagement und Testdurchfhrung in dem Projekt einzusetzen.

Manahmen:

Durch Kennzahlen wird der Testfortschritt durch den Testmanagerpermanent berprft; berschreitungen der geplanten Zeiten sindunverzglich der Gesamtprojektleitung mitzuteilen.

Durch die Gewichtung der zu testende Qualittsmerkmale knnen dieTestszenarien genau auf die Anforderungen abgestimmt werden. Zudemwird eine Risikobewertung der Testobjekte7 durchgefhrt, um einerisikobasierte Testvorbereitung und durchfhrung zu ermglichen.

Durch den Testmanager in Abstimmung mit der Gesamtprojektleitung unddem Auftraggeber muss ein Minimum an Tests definiert werden, dererfllt sein muss, bevor Funktionen in den Rollout bergehen knnen.

Tabelle 2: Projekt- und Produktrisiken

5.1.2 Verwendete Richtlinien und Normen

Alle notwendigen Richtlinien und Normen werden hier aufgefhrt, bzw. es gibt Hinweise auf dieentsprechenden Dokumente. Die relevanten rechtlichen Grundlagen sind im Grobkonzept C.6 ([1]im Anlagenverzeichnis) definiert.Im Projektverlauf von ERP werden eine Reihe von Tests durchgefhrt, die zusammengefasst imWesentlichen die folgenden Ziele verfolgen:? berprfung von Design, Customizing und Entwicklung in Verbindung mit einem korrekten

Ablauf der fachlichen Prozesse und Strukturen

? modulbergreifende berprfung der Geschftsprozesse

? berprfung der Programmierung und der Vorgehensweise bei der Datenmigration

? berprfung der SAP Berechtigungsprofile

? Verifikation der Funktionsfhigkeit der gesamten eingesetzten Hard- und Software im Rahmender erwarteten Performanceparameter

Das Gesamtziel, das im Rahmen der Tests verfolgt wird, ist die Untersttzung des Rollouts durchBesttigung der Realisierung des jeweiligen Funktionsumfangs der Referenzmodelle mit dendazugehrigen Komponenten, d.h. auch die Besttigung des korrekten Ablaufs der Prozesse und

6 Der genaue Liefertermin einzelner Teilprojekte und Referenzmodelle vor dem Projektabschluss ist dem Gesamtprojektplan zuentnehmen.7 Testobjekt kann das zu testende IT-System bzw. ein definierter Teil des IT-Systems sein. Testobjekte sind die Einheiten, fr die dieTestflle und Testdaten erstellt werden sollen. Testobjekte haben je nach Testart einen unterschiedlichen Umfang. Im Modultest handeltes sich um einzelne Module wie z.B. Transaktionen, im Systemtest handelt es sich um komplette Geschftsprozesse. WeitereErluterungen siehe Kap 7.2



der Korrektheit der Daten. Am Ende der Tests steht die Freigabe des Produktivsystems durch denAuftraggeber.

Die einzelnen Tests bauen aufeinander auf bzw. stehen in einer Beziehung zueinander. Grundlageist das so genannte V-Modell, ein Standardmodell.(1) Es wird nicht nur ein Gesamttest durchgefhrt, sondern alle Testttigkeiten werden in logisch

und funktional voneinander trennbare Teilabschnitte zerlegt. Diese Teilung wird nachIntegrationsgrad vorgenommen, wobei das Testen auf der Stufe mit dem geringstenIntegrationsgrad beginnt.

(2) Dabei kann erst mit der nchst hheren (also integrativeren) Stufe des Tests grundstzlichbegonnen werden, wenn alle Komponenten der vorherigen Stufe getestet und freigegebenwurden (Stufenprinzip) bzw. die Eingangskriterien der jeweiligen Teststufe erfllt sind.

(3) Auf dem linken Ast des Modells ist dargestellt, wie im Rahmen von Entwicklungsschritten dasDesign des Systems immer weiter detailliert wird. Der bergang zwischen zwei Stufen ist miteinem Freigabeprozess verbunden, der die Verifikation und Validierung der Arbeiten einerStufe beinhaltet. Unter Verifikation versteht man die Besttigung, dass ein Projektergebniskomplett ist und den Spezifikationsanforderungen entspricht. Validierung beinhaltet dieBesttigung, dass ein Projektergebnis den auf der vorhergehenden Stufe spezifiziertenAnforderungen gengt.

Abbildung 2: Vorgehensmodell fr die verschiedenen Teststufen

Fr die Validierung des Projektergebnisses gegen die spezifizierten Anforderungen (sind jeweils imFachfeinkonzept, Sollkonzept, Customizing-/Designvorgaben in der notwendigen Detaillierungbeschrieben) in der jeweiligen Teststufe wird das vorliegende Projektergebnis (ist in jederTeststufe die ERP-Softwarelsung) in unterschiedlicher Granularitt betrachtet.

Komponenten-test

Validierungder Konzeption

Verfizierungder vorange-gangenenTeststufe

Abnahme-test

Anforderungs-definition

Grob-konzeption

System-test

Fein-konzeption

Integrations-test

Modul-spezifikation

Modul-test

Implementierung

auf Basis von Abnahme-test


Grob-konzeption

System-test

Fein-konzeption

Integrations-test

Modul-spezifikation

Modul-test

Implementierung

auf Basis vonAnforderungs-definition

Fachfein--konzeption

System-test

Soll--konzeption

Integrations-test

Customizing--vorgaben

Modul-test

Implementierung+ Komponententest

auf Basis von

Komponenten-test

Validierungder Konzeption

Verfizierungder vorange-gangenenTeststufe

Abnahme-test


Grob-konzeption

System-test

Fein-konzeption

Integrations-test

Modul-spezifikation

Modul-test

Implementierung



Grob-konzeption

System-test

Fein-konzeption

Integrations-test

Modul-spezifikation

Modul-test

Implementierung



System-test

Soll--konzeption

Integrations-test


Modul-test




Grob-konzeption

System-test

Fein-konzeption

Integrations-test

Modul-spezifikation

Modul-test

Implementierung



Grob-konzeption

System-test

Fein-konzeption

Integrations-test

Modul-spezifikation

Modul-test

Implementierung



System-test

Soll--konzeption

Integrations-test


Modul-test


auf Basis von



Aus den zentralen Anforderung die Untersttzung von bestimmten Geschftsprozessen der BAmittels einer Gesamtlsung basierend auf SAP ERP leiten sich immer feinere Anforderungen ab.Diese beziehen sich angefangen im Fachfeinkonzept hauptschlich auf Prozesse sowieProzessketten bis zu Customizing- sowie Entwicklungsobjekten in den Customizing-/Designvorgaben. Damit beziehen sich die Anforderungen in der jeweiligen Konzeptsstufe aufunterschiedliche detaillierte Objekte im Folgenden als Testobjekte bezeichnet derGesamtlsung. Zur Validierung der Anforderungen bezogen auf die Testobjekte in einerKonzeptionsstufe werden die dazugehrigen Tests geplant und durchgefhrt. Dazugehrig meintz.B. fr den Modultest, dass die Testflle die Realisierung der Anforderungen (Customizing-/Designvorgaben) an die Testobjekte (Customizing-/Entwicklungsobjekte) in der Softwarelsungberprfen bzw. die Korrektheit nachweisen.

In der folgenden Abbildung sind die mglichen Anforderungen und Testobjekte fr diedurchzufhrenden Teststufen dargestellt.

Abbildung 3: Darstellung der Beziehung Anforderung, Testfall, Testobjekt

Die Kardinalitt, also der Grad oder Komplexitt der Beziehung, zwischen den Objekten(Anforderung, Testfall, Testobjekt) ist abhngig von der jeweiligen Teststufe. Diese wird detailliertin Anlage 28 im Anlagenverzeichnis erlutert.

Die geplanten Tests gliedern sich in die folgenden Teststufen8:

? Komponententest9

- Der Entwickler/Customizer wird die fr die BA relevanten und spezifisch ausgeprgten SAP-Realisierungen in den Komponenten10 unabhngig voneinander auf ihre Funktionalitttesten.

8 Eine Teststufe ist eine Gruppe von Testaktivitten, die gemeinsam ausgefhrt und verwaltet werden.9 wird innerhalb der BA auch Unittest genannt. (=synonym zu Entwicklertest)



- Der Komponententest im Kontext des ERP-Projektes kann mit dem Komponententest (oderauch Unittest) nach ISTQB-Notation verglichen werden.

- Der AN ist fr die Testdurchfhrung verantwortlich.

? Modultest- Einzelne Funktionalitten eines Moduls11 werden durch den fachlich Verantwortlichen im

Projektteam gegen die Anforderungen aus den Customizing-/Designvorgaben getestet.

- Der Modultest im Kontext des ERP-Projektes kann nicht unmittelbar mit einer Teststufe nachISTQB-Notation verglichen werden. Der Modultest ist als qualittssichernde Manahmezwischen dem Komponententest und dem integrativen Test des Gesamtsystems zuverstehen.


? Integrationstest- Testen der modulbergreifenden Funktionalitten, Schnittstellenfunktionalitten, Prozesse,

Transporte sowie anzubindenden Verfahren gegen die Anforderungen aus dem Sollkonzept

- Der Integrationstest im Kontext des ERP-Projektes kann mit der ISTQB-TeststufeIntegrationstest verglichen werden. Im Kontext des ERP-Projektes erfolgt weiterhin keineUnterscheidung nach Komponentenintegrationstest bzw. Systemintegrationstest. Der Testvon Geschftsprozessen bezieht sich auf den prozessualen Ablauf innerhalb des ERP-Systems sowie den Test von Schnittstellen zwischen Umsystemen und dem ERP-Systemohne die auslsenden bzw. ausgelsten Prozesse auerhalb/innerhalb des ERP-Systems zubetrachten (siehe hierzu Kap 5.2.2.4.4).


? Systemtest- Verifizierung der fr die BA im SAP-System ausgeprgten Funktionalitten unter

Bedingungen, die dem spteren Produktivsystem vergleichbar sind.

- Testen der ERP-Geschftsprozesse12 gegen das Fachfeinkonzept

- Der Systemtest im Kontext des ERP-Projektes kann mit der ISTQB-Teststufe Systemtestverglichen werden. Dabei ist wie oben im beschrieben zu bemerken, dass derSystemtest im Kontext des ERP-Projektes als Testgegenstand die bergreifendenGeschftsprozessen mit Schnittstellen zu BA-Verfahren und Umsystemen hat. Prfungenbzw. Eingaben an externen Systemen, welche nicht zum ERP-Projekt Geltungsbereichgehren, werden allerdings von der BA vorgenommen.

- Der Systemtest wird in die folgenden Teilaspekte unterteilt:

? Migrationstest

? Test der Datenbernahme

10 Als Komponente werden aus Testsicht die Teile einer Applikation bezeichnet, die dem Endanwender nicht direkt zur Verfgungstehen. Dazu gibt es zwei Gruppen: Customizing-Objekte und Entwicklungs-Objekte. Customizing-Objekte knnen beispielsweiseIMGs, Tabellen, Reports sein. Entwicklungs-Objekte haben im Projekt ERP knnen BI (Batch-Input), ENH (Enhancement Package),FRM (Framework), INF(Interface), REP (Report), WFL (Workflow) sein.11 Als Modul werden aus Testsicht die Teile der Applikation bezeichnet, die der Endanwender direkt aufrufen kann. Im Projekt ERP wirddarunter beispielsweise eine Transaktion gesehen oder ein Batch-Job. Es ist im Zusammenhang des Testmanagement nicht vonModulen im Sinne der SAP Terminologie (HR-Modul, FI-Modul) die Rede.12 Der Begriff "Geschftsprozess" im Sinne dieses Konzeptes bezeichnet systeminterne Ablufe bzw. Abfolgen von Prozessschritteninnerhalb des ERP-Systems, im Folgenden 'ERP-Geschftsprozesse' genannt.



? Lasttest (als nicht-funktionaler Test)

? Verifikation der Performance der Produktionsplattform

? Systemtest Abrechnung (HR)

? Kontrolle der SAP-Abrechnungsergebnisse

? Paralleltest (HR)

? Simulation des Produktivbetriebes im neuen SAP-HR-System und anschlieenderVergleich mit dem Altsystem

? Systemtest ERP-Geschftsprozesse

? Kontrolle der Geschftsprozesse innerhalb des ERP-Systems


? Akzeptanztest- Tests auf Basis definierter Anforderungen mit dem Ziel einer funktionalen und non-

funktionalen Freigabe des in die BA-Systemlandschaft integrierten ERP-Systems. DerAuftraggeber verantwortet die Planung und Durchfhrung dieser Tests. Erfolgreichdurchgefhrte Freigabetests/Akzeptanztests sind Voraussetzungen fr die jeweiligen (Teil-)Produktivsetzungen des ERP-Systems

- Nach erfolgreicher Durchfhrung erfolgt die Freigabe des Systems durch den Auftraggebersowie die Erklrung der Akzeptanz

- Die Verantwortung zur Durchfhrung der Akzeptanztests liegt beim AG unter Einbezug desAN zur Abstimmung der Testflle. Dieses Vorgehen dient dem Ziel, diese Testflle schon imSystemtest durch den AN durchfhren zu lassen.

? Produktivsimulation im Teilprojekt FI- Hier wir in einem Parallelbetrieb des Alt- und des Neu-Systems die gesamte Funktionalitt

ber eine definierten Zeitraum berprft.

- Letzte Entscheidungen zur Durchfhrung einer Produktivsimulation sind noch nicht gefallen.Sollte es eine Produktivsimulation geben, dann wird die konzeptionelle Ausarbeitung zueinem spteren Zeitpunkt dokumentiert.

Richtlinie 1 Fr jedes Teilprojekt werden die Teststufen Komponenten-, Modul-, Integrations-,System- und Akzeptanztest geplant, vorbereitet und durchgefhrt.

5.1.3 Leistungskennzahlen fr den Test

Fr die berwachung des Status und der Messung des Fortschritts bei der Vorbereitung undDurchfhrung der geplanten Tests sowie fr die abschlieende Betrachtung der Tests werden indiesem Kapitel Aspekte und Kennzahlen beschrieben. Die berwachung anhand von Kennzahlensoll zum Erfolg des Tests im Gesamtprojekt beitragen.

berwachung des Fortschritts bei der TestvorbereitungFr die berwachung der Testvorbereitungsarbeiten werden generelle Techniken desProjektmanagements zur Fortschrittskontrolle eingesetzt. Hier werden keine speziellenKennzahlen aufgefhrt. Folgende Aspekte mssen im zeitlichen Projektverlauf betrachtet undgegenber der Projektplanung abgeglichen werden:



? Aufbau der Infrastrukturen- HW-Beschaffung,

- Systemeinrichtung,

- Arbeitsplatzausstattung

- Bereitstellung von Kommunikationsplattformen,

- Netzwerkanbindungen etc.

? Spezifikation der Testflle und Testszenarien inkl. Testdatenzuordnung- Anzahl der Testflle pro Teststufe

- Grad der Testautomation pro TeststufeGesamtanzahl der spezifizierten Testflle im Verhltnis zur Anzahl der automatisiertenTestflle pro Teststufe

%TeststufeeinerinTestfllehlGesamtanza

100TeststufeeinerinTestflleerteautomatisitionTestautomaderGrad ?

? ??? Bereitstellung der initialen Testdatenbasis in der Testsystemlandschaft

Kennzahlen zum Fortschritt bei der Testausfhrung in einer TeststufeDie zu berwachenden Kennzahlen whrend der aktiven Testphase sind:

? Grad der Testausfhrung:Anzahl der bereits ausgefhrten Testflle (bzw. Testszenarien) unabhngig vom Ergebnis (okayoder nicht okay) gegenber den geplanten Testfllen im aktuellen Testlauf

%Testfllegeplanter

100TestflleerausgefhrtrungTestausfhderGrad ?

? ??? Anteil der erfolgreich durchgefhrten/fehlerhaft verlaufener Testflle zur Gesamtanzahl der

Testflle

%TestfllehlGesamtanza

100TestflleheerfolgreicTestfllehenerfolgreicderAnteil ?

? ??

%TestfllehlGesamtanza

100TestflleefehlerhaftTestflleenfehlerhaftderAnteil ?

? ??? Anzahl der Testlufe pro Teststufe und Referenzmodell

? Anzahl der Fehler pro Teststufe und Referenzmodell

? Verteilung der entdeckten Fehler auf die Fehlerklassen (Kritikalitt eines Fehlers)

? Varianz der Testdauer:Gegenberstellung der geschtzten Dauer13 zur Durchfhrung der noch offenen Testflle bzw.Testszenarien unter Bercksichtigung von Verarbeitungszeiten (z.B. Prozessdurchlaufzeit,

13 Die geschtzte Testdauer wird vom Teilprojekt-Testkoordinator SAP/ACN bzw. vom Teilprojektleiter SAP/ACN vor Beginn derTeststufe geplant.



tgliche Batchlufe etc.) und der noch verbleibenden Zeit fr den aktuellen Testlauf gem derPlanung.

TeststufeeinerinTestlauffr ZeitdeverbleibenTeststufeeinerinTestlauffr ZeitbentigteTeststufeeinerinarianzTestdauerv ?

Bei einem Ergebnis > 1 mssen Manahmen eingeleitet werden.

? TestabdeckungDie Messung der Testabdeckung kann auf unterschiedlicher Basis erfolgen. Dieberdeckungsmessung kann z.B. anhand von funktionalen Entscheidungsstrukturen,Prozessablufen oder funktionalen Anforderungen (= Elemente) erfolgen.Hierbei wird die mgliche Anzahl der zu testenden Elemente der tatschlich im Testbercksichtigen Elementen gegenbergestellt. Bei einer Pfadabdeckung im Rahmen einesProzesstests sind damit alle mglichen Pfade, die im Prozess vorhanden sind, und die imRahmen der Testflle sowie den dabei verwendeten Daten getesteten Pfade gemeint. DieTestabdeckung im Rahmen der quivalenzklassenmethode14 fr Eingabefelder vergleicht dieAnzahl der mglichen gltigen/ungltigen quivalenzklassen mit der Anzahl der beschriebenenTestflle je quivalenzklasse.

%Elementeenzu testendderGesamtzahl

100ElementegeprftehtatschlicungTestabdeck ?

? ??

Bewertung der Testeffektivtt je TeststufeDie Bewertung der Testeffektivitt einer Teststufe ist erst nach Abschluss einer Teststufe mglich.Dafr kann man folgende Metriken anwenden:

? Quote der Fehlerentdeckung:Fr die Messung der Testqualitt wird die Anzahl der gefundenen Fehler der abgeschlossenenTeststufe mit der Anzahl aller ber alle Teststufen gefundener Fehler verglichen.

%Fehleraller

100TeststufeeinerFehlerteeckungsquoFehlerentd ?

? ??Der prozentuale Anteil der gefundenen Fehler sollte mit zunehmender Teststufe abnehmen.

? Erzielter Grad der Testreife:Bei der Testreife wird die Anzahl der gefundenen Fehler unter Bercksichtigung der Aktivittdes Tests (Anzahl der Testflle) und der erzielten Testabdeckung betrachtet.

???

ungTestabdeck*Testflleeausgefhrt100 /TeststufeeinerFehler

-1radTestreifeg

Da Grad der Testreife mglichst hoch sein sollte, muss der Wert mglichst nah am Wert 1 liegen.

14 Die quivalenzklassenmethode ist eine Art der systematische Testfallermittlung. Bei der Ermittlung von Testfllen und der Zuordnungvon Testdaten wird untersucht, welche Klassen von mglichen Eingabewerten (Wertebereiche) zu einer gleichen oder hnlichenVerarbeitung fhren. Die Eingabewerte werden so gewhlt, dass die Durchfhrung eines Testfalls gengt, um eine reprsentativeAussage ber das zu erwartende Ergebnis fr den damit abgebildeten Wertebereich zu erhalten. Siehe dazu auch Kap 7.2



Bewertung der Anforderungs- und TestobjektabdeckungDie nachfolgenden Auswertungen dienen dazu eine Abdeckung zwischen Anforderungen,Testobjekten und Testfllen sicherzustellen.

Abbildung 4: Darstellung der Relation zwischen Anforderung, Testfall, Testobjekt

? Prfungen der Vollstndigkeit zu erstellender Relationen- Testobjekte ohne Testflle: Dient zur Identifikation von Testobjekten, denen kein Testfall

zugewiesen ist. Diese Konstellation ist nicht zulssig.

- Testflle ohne Testobjekte: Dient zur Identifikation von Testfllen ohne Bezug zu einemTestobjekt. Diese Option kann bei der intuitiven Testfallerstellung auftreten. Ziel ist es eineZuordnung fr jeden Testfall herzustellen.

- Testobjekte ohne Anforderung: Dient zur Identifikation von Testobjekten, die in keinerAnforderungen in Bezug stehen.

- Anforderungen ohne Testobjekte: Dient zur Identifikation von Anforderungen, denen keinTestobjekt zugewiesen ist. Diese Konstellation ist nicht zulssig.

? Prfungen zum Verhltnis zwischen Anforderungen und Testfllen- Anforderungen? (zu) Testfllen: Report zeigt die Gesamtmenge der Testflle zur Prfung

der Testobjekte, welche zur Umsetzung einer Anforderung realisiert wurden

- optional: Testflle ? (zu) AnforderungenDie nachfolgende Tabelle zeigt eine bersicht, welche Kennzahlen in welcher Teststufeeinzusetzen sind.

PhaseTeststufe

Testvorbereitung Testdurchfhrung Nach Abschluss

Komponententest keine Vorgaben keine Vorgaben keine Vorgaben

Modultest Anzahl der TestflleGrad der Testautomation

Grad der TestausfhrungAnteil erfolgreicher/fehlerhafter TestflleTestabdeckungVerteilung der Fehler aufFehlerklassen

Fehlerentdeckungsquote



PhaseTeststufe

Testvorbereitung Testdurchfhrung Nach Abschluss

Integrationstest Anzahl der TestflleGrad der Testautomation


Fehlerentdeckungsquote

Systemtest Anzahl der TestflleGrad der Testautomation


FehlerentdeckungsquoteTestreifegrad

Tabelle 3: Monitoring der Teststufen im Gesamtprojekt

Aus Tabelle 3 ergeben sich die folgenden Richtlinien:

Richtlinie 2 Fr den Modultest werden die folgenden KPIs berwacht: Anzahl der Testflle inder Testvorbereitung, Grad der Testautomation in der Testvorbereitung, Grad derTestausfhrung, Anteil erfolgreicher/fehlerhafter Testflle in der Testdurchfhrung,Testabdeckung in der Testdurchfhrung, Verteilung der Fehler in den Fehlerklassenin der Testdurchfhrung und die Fehlerentdeckungsquote.

Richtlinie 3 Fr den Integrationstest werden die folgenden KPIs berwacht: Anzahl der Testfllein der Testvorbereitung, Grad der Testautomation in der Testvorbereitung, Grad derTestausfhrung, Anteil erfolgreicher/fehlerhafter Testflle in der Testdurchfhrung,Testabdeckung in der Testdurchfhrung, Verteilung der Fehler in den Fehlerklassenin der Testdurchfhrung und die Fehlerentdeckungsquote.

Richtlinie 4 Fr den Systemtest werden die folgenden KPIs berwacht: Anzahl der Testflle inder Testvorbereitung, Grad der Testautomation in der Testvorbereitung, Grad derTestausfhrung, Anteil erfolgreicher/fehlerhafter Testflle in der Testdurchfhrung,Testabdeckung in der Testdurchfhrung, Verteilung der Fehler in den Fehlerklassenin der Testdurchfhrung und die Fehlerentdeckungsquote.



5.1.4 Qualittsmerkmale und Gewichtung

Die Gewichtung dient als Orientierungsvorgabe bei der Planung und Definition der einzelnenTestflle und -szenarien. Es sind keine Richtlinien, deren Einhaltung zwingend erfllt werdenmuss. Sind bspw. insgesamt 100 Testflle geplant, so wrden wir empfehlen mit ca. 70 Testfllendie Funktionalitt zu testen, wenn diese eine Gewichtung von 70 hat.

Nr. Kriterium Gewichtung

1 Funktionalitt

? Angemessenheit: Eignung von Funktionen fr spezifizierte Aufgaben, z.B.aufgabenorientierte Zusammensetzung von Funktionen aus Teilfunktionen.

? Richtigkeit: Liefern der richtigen oder vereinbarten Ergebnisse oderWirkungen, z.B. die bentigte Genauigkeit von berechneten Werten.

? Sicherheit: Fhigkeit, unberechtigten Zugriff, sowohl versehentlich als auchvorstzlich, auf Programme und Daten zu verhindern.

70%

2 Benutzbarkeit

? Verstndlichkeit: Aufwand fr den Benutzer, das Konzept und die Anwendungzu verstehen.

? Bedienbarkeit: Aufwand fr den Benutzer, die Anwendung zu bedienen.

8%

3 Zuverlssigkeit

? Reife: Geringe Versagenshufigkeit durch Fehlerzustnde.? Fehlertoleranz: Fhigkeit, ein spezifiziertes Leistungsniveau bei Software-

Fehlern oder Nicht-Einhaltung ihrer spezifizierten Schnittstelle zu bewahren.

? Robustheit: Fhigkeit, ein stabiles System bei Eingaben zu gewhrleisten, diegar nicht vorgesehen sind.

? Widerherstellbarkeit: Fhigkeit, bei einem Versagen das Leistungsniveauwiederherzustellen und die direkt betroffenen Daten wiederzugewinnen. Zubercksichtigen sind die dafr bentigte Zeit und der bentigte Aufwand.

8%

4 Effizienz

? Zeitverhalten: Antwort- und Verarbeitungszeiten sowie Durchsatz bei derFunktionsausfhrung, Bundesweite Systemnutzung

? Verbrauchsverhalten: Anzahl und Dauer der bentigten Betriebsmittel bei derErfllung der Funktionen. Ressourcenverbrauch, wie CPU-Zeit,Festplattenzugriffe usw.

4%

5 bertragbarkeit

? Anpassbarkeit: Fhigkeit der Software, diese an verschiedene Umgebungenanzupassen.

? Installierbarkeit: Aufwand, der zum Installieren der Software in einerfestgelegten Umgebung notwendig ist.

Koexistenz: Fhigkeit der Software neben einer anderen mit hnlichen odergleichen Funktionen zu arbeiten.

2%



Nr. Kriterium Gewichtung

6 nderbarkeit

? Analysierbarkeit: Aufwand, um Mngel oder Ursachen von Versagen zudiagnostizieren oder um nderungsbedrftige Teile zu bestimmen.

? Modifizierbarkeit: Aufwand zur Ausfhrung von Verbesserungen, zurFehlerbeseitigung oder Anpassung an Umgebungsnderungen,Beschrnkung BA-spezifischer Anpassungen

? Stabilitt: Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen vonnderungen.

? Prfbarkeit: Aufwand, der zur Prfung der genderten Software notwendig ist.

8%

Summe = 100%

Tabelle 4: Gewichtung der Qualittskriterien

5.1.5 Nicht zu testende Komponenten und Qualittsmerkmale

Das vorliegende Testmanagement-Konzept bercksichtigt alle Testaktivitten in den Teststufen,welche in Verantwortung von SAP/Accenture durchgefhrt werden. Dabei finden integrative Testsstatt, welche einzelne Funktionalitten im Zusammenspiel mit angrenzenden Funktionalitteninnerhalb des ERP-Systems sowie zu anzubindenden Verfahren testen. Diese integrativen Testswerden von SAP/Accenture mit der BA abgestimmt, damit diese entsprechenden Vorbereitungenin den Umsystemen getroffen werden knnen. Mssen auf diesen externen Systemen Aktionen(Prfungen, Eingaben etc.) durchgefhrt werden, werden diese durch Mitarbeiter der BAvorbereitet sowie ausgefhrt und liegen in der Verantwortung der BA.

Tests von externen Systemen, die nicht zum Geltungsbereich des ERP-Einfhrungsprojekts sowiezu anzubindenden Verfahren gehren, werden von SAP/Accenture nicht geplant und liegen in derVerantwortung der BA.

Eine Besonderheit betrifft Komponenten, die in ihrer SAP-Funktionalitt nicht gendert wurden(keine nderung der Verarbeitung von Eingabewerten etc., z.B. nur nderung der Bezeichnung).Fr diese mssen ausschlielich Testflle geplant werden, welche die grundstzlicheFunktionalitt mittels Positiv-Testfllen nachzuweisen.15

Das Qualittsmerkmal Usability, welches im SAP Standard beinhaltet ist und bereits mehrfach imRahmen dieser Auslieferungen verifiziert wurde, wird keiner weiteren Prfung unterzogen.

Die Verifikation der Barrierefreiheit wird durch das Kompetenz-Center-CANS (KCC) geplant,durchgefhrt und dokumentiert. Das ERP Projekt gibt Hilfestellungen oder initiale Anleitungbeispielsweise beim Bedienen der SAP Oberflchen oder stichprobenhaftig ausgewhlterfachlicher Prozesse.

Des Weiteren sind zurzeit auer Lasttests keine weiteren nicht-funktionalen Tests vorgesehen.

5.2 Teststufen und MethodenIm Folgenden wird die Testlandschaft der SAP-Lsung beschrieben.

15 Siehe auch Kap. 5.2.2.1.1



5.2.1 System- und Testlandschaft

Fr die SAP-Bestandteile des Projekts ERP wird eine vierstufige Systemlandschaft aufgebaut. Dergenaue Aufbau der Systemarchitektur inklusive der Nicht-SAP Systeme ist in [8] imAnlagenverzeichnis beschrieben.

In der folgenden Abbildung ist die ERP Systemlandschaft dargestellt.

Abbildung 5: Zusammenspiel der Komponenten in der ERP Systemlandschaft

Die fr das Projekt ERP erforderliche Testsystemlandschaft bezogen auf die SAP-Kernsystemesieht folgendermaen aus:



Abbildung 6: SAP ERP System- und Testlandschaft

Die Bezeichnung XX in der Abbildung steht hier fr die jeweilige SAP-Anwendung, so z.B. frSAP ERP, SAP NW-BI oder SAP NW-PORTAL.

5.2.1.1 XXE-System

Das XXE-System (Entwicklung) dient als Entwicklungs- und Konfigurationsplattform. In diesemSystem fhrt der Customizer alle Konfigurationsarbeiten durch und berprft seine Customizing-Einstellungen. Die Programmierer entwickeln und berprfen hier ebenfalls ihre entwickeltenProgramme.

Im Weiteren dient das XXE-System der Qualittssicherung von Konfigurations- undEntwicklungsarbeiten der Teilprojekte im Rahmen des Modultests oder die aufgrund vonFehlerbehebungen aus anderen Teststufen erforderlich waren. Testverantwortlicher und Testererhalten Zugriff auf das XXE-System.

Nach Abschluss des Modultests bzw. des Regressionstests fr Fehler aus anderen Teststufen imXXE-System erfolgt nach Transport-Freigabe (Veranlassung des Transports) der Transport in dasXXV-System.

SAP-Patches werden in Abstimmung mit den SAP-/Accenture-Teilprojektleitern auf dem XXE-System eingespielt und auf Seiteneffekte geprft16.

Richtlinie 5 Alle nderungen (Entwicklungen, Customizing) werden auf dem XXE-Systemvorgenommen und von dort nach erfolgten QS-Manahmen in die nachfolgendenSysteme transportiert.

Richtlinie 6 Auf dem XXE-System werden ausschlielich die Komponententests und dieModultests bzw. Regressionstests fr Fehler aus anderen Teststufen durchgefhrt.

16 siehe dazu Richtlinie 11



5.2.1.2 XXV-System

Das XXV-System (Vorintegration) dient der Qualittssicherung von Konfigurations- undEntwicklungsarbeiten der Teilprojekte im Rahmen des Integrationstests. Testverantwortlicher undTester erhalten Zugriff auf das XXV-System.

Auf dem XXV-System gibt es aus Testmanagement-Sicht mindestens drei Mandanten:

? einen Testdaten-Mandanten (enthlt die im Integrationstest genutzten synthetischen Daten)

? einen Migrationsandaten (enthlt Echtdaten fr den Migrationstest)

? einen Test-Mandanten (Kopie der Daten aus dem Testdaten-Mandanten vor Beginn jedesTestzyklus17)

Nach Abschluss des Integrationstests bzw. des Regressionstests fr Fehler aus dem Systemtestim XXV-System erfolgt nach Transport-Freigabe (Veranlassung des Transports) der Transport indas XXI-System.

Richtlinie 7 Auf dem XXV-System werden ausschlielich die Integrationstests bzw.Regressionstests fr Fehler aus dem Systemtest durchgefhrt.

5.2.1.3 XXI-System

Das XXI-System (Integration) dient der Qualittssicherung von Konfigurations- undEntwicklungsarbeiten im Rahmen des System- und Akzeptanztests. Testverantwortlicher undTester erhalten Zugriff auf das Integrations-System.

Auf dem XXV-System gibt es aus Testmanagement-Sicht mindestens drei Mandanten:

? einen Testdaten-Mandanten (enthlt die im Integrationstest genutzten synthetischen Daten)

? einen Migrations-Mandaten (enthlt Echtdaten fr den Migrationstest)

? einen Test-Mandanten (Kopie der Daten aus dem Testdaten-Mandanten vor Beginn jedesTestzyklus18)

Nachdem die Tests durchgefhrt worden sind und das System durch den AG freigegeben wurde,wird die Konfiguration fr den Transport in das Produktivsystem freigegeben. Nach Transport-Freigabe (Veranlassung des Transports) erfolgt der Transport vom XXI-System in das XXP-System.

Richtlinie 8 Auf dem XXI-System werden ausschlielich die System- und Akzeptanztestsdurchgefhrt.

5.2.1.4 XXP-System

Das Produktivsystem ist die Arbeitsplattform der Endanwender. Hier wird vor der Produktivsetzungvon Transporten ein Smoketest durchgefhrt. Dieser erfolgt ohne datenverndernde Aktionen undnicht-automatisiert.

17 Details siehe Kap. 5.5.318 Details siehe Kap. 5.5.3



Richtlinie 9 Auf dem XXP-System werden bis auf den speziellen Smoketest (keinedatenverndernde und nicht-automatisierte Aktionen) vor der Produktivsetzung vonnderungen keine Tests durchgefhrt.



5.2.2 Teststufen

Vor dem Go-live werden fnf Teststufen durchlaufen:

Abbildung 7: Teststufen

Nach dem Modultest erfolgt eine formale bergabe der Komponenten durch denModulverantwortlichen bzw. Teilprojekt-Testkoordinator.

Richtlinie 10 Die Komponenten mssen nach dem Modultest durch den Modulverantwortlichen/Teilprojekt-Testkoordinator freigegeben werden.

Zustzlich werden Smoke-Tests19 zu folgenden Zeitpunkten durchgefhrt:

? Beim bergang vom XXE- zum XXV-System

? Beim bergang vom XXV- zum XXI-System

? Beim bergang vom XXI- zum XXP-System

? Nach jedem Transport bzw. Verteilung auf dem XXV- sowie XXI-System, bspw. nach einemBugfixing

Der prinzipielle Ablauf des Smoke-Tests wird vom Testmanager definiert und im Quality Centerdokumentiert.

Richtlinie 11 Bei jedem bergang von einem zum nchsten System (XXE?XXV sowieXXV?XXI) und bei jedem Transport bzw. Verteilung auf dem XXV- sowie XXI-System wird ein Smoke-Test durchgefhrt.

Fr die Komponenten FI, HCM und externe Schnittstellen werden Lasttests auf dem XXI-Systemim Rahmen des Systemtests durchgefhrt.

5.2.2.1 Testmethoden

Fr jede Teststufe sind unterschiedliche Teile des Software-Systems der Gegenstand des Tests.Diese werden im weiteren Verlauf als Testobjekte bezeichnet.

5.2.2.1.1 Klassifizierung der TestobjekteDie einzelnen Testobjekte werden einer Risiko-Klasse zugeordnet. Diese Klassifizierung soll vorallem bei der Festlegung der Reihenfolge von Testszenarien bzw. Testfllen untersttzen. Auch

19 Der Smoke-Test ist ein Probelauf nach der Installation der Software, eine oberflchliche berprfung der grundlegendenProgrammfunktionen. Smoke-Tests werden nach dem Transport vom DEV- auf das QA-System und vom QA- auf das PROD-Systemsowie nach jedem neuen Build durchgefhrt. Fr den Smoketest wird von den SAP-/Accenture-Fachteams bzw. dem Teilprojekt IT eineAuswahl reprsentativer, fr den Bereich kritischen, mglichst automatisierbarer Testflle (in Tabelle 6 als Regressionstest aufgefhrt)getroffen. Der Testflle werden von den jeweiligen Fachteams/Teilprojekt IT durchgefhrt. (siehe auch im Kap 7.1)



kann diese Klassifizierung als Entscheidungsgrundlage herangezogen werden, falls die geplantenUmfnge der Tests auf Grund der zeitlichen Restriktionen gekrzt werden mssen.

Fr eine Klassifizierung werden die Testobjekte einer Risikobewertung nach Geschftskritikalittund Fehlereintrittswahrscheinlichkeit unterzogen. Dabei werden die folgenden Fragestellungen freine Risikobewertung herangezogen:

Risikokriterium Mgliche Werte fr das Risikokriterium

Geschftskritikalitt

Art des Prozesses Berechnung/berprfung Datennderung Datenanzeige

MglicheFehlerauswirkung

Rechtliche/VertraglicheAuswirkung

Falschinformation KeineAuswirkung

Hufigkeit der Nutzung Sehr oft Oft Selten

Anzahl der betroffenenNutzer/Bedeutsamkeit

Viele/Hoch Einige/Mittel Wenige/Niedrig

Fehlereintrittswahrscheinlichkeit

Art der Anpassung Neue Funktion GenderteFunktion

ungenderteFunktion

Softwarereife bzw.Testobjektreife

Unausgereift Mittlere Reife Sehr reif

Erwartete Fehleranzahlfr das Testobjekt

Viele Einige Wenige

Anzahl der betroffenenMasken/Datentabellenetc.

Mehr als 4 2-4 Weniger als 2

Tabelle 5 Kriterien fr die Risikobewertung der Testobjekte

Ein einmal bewertetes Testobjekt besitzt dann fr die Geschftskritikalitt bzw.Fehlereintrittswahrscheinlichkeit einen der folgenden Werte:

? Geschftskritikalitt

? A Hohe

? B Mittlere

? C Niedrige

? Fehlereintrittswahrscheinlichkeit

? 1 Hohe

? 2 Mittlere

? 3 Niedrige



Auf Basis dieser Risikobewertung der Testobjekte kann dann in der Testfallspezifikation ermitteltwerden, welche Testarten20 sowie Testverfahren21 fr die Prfung der Anforderung proTestobjekttyp in der jeweiligen Teststufe angewandt wird.

Die nachfolgende Tabelle gibt einen berblick dieser Zuordnung und dient der Aufteilung desTestaufwands auf die zu prfenden Teile/Qualittsmerkmale. Die dabei aufgefhrtenTestfallermittlungsverfahren sind im Kapitel 7.2 nher beschrieben; die dort benanntenEingangsartefakte zur Testfallerstellung sind durch den Testfalldesigner zu erstellen (siehe auchAbschnitt 5.6.4.9 Bentigte Ausbildungsmanahmen sowie Einarbeitungsmanahmen).

20 Eine Testart ist eine Gruppe von Testaktivitten, die gemeinsam ausgefhrt und verwaltet werden, mit dem Ziel der berprfungeiner Komponente und eines Systems auf einige zusammenhngende Qualittsmerkmale. Eine Testart kann sich auf bestimmteTestziele beziehen, wie z.B. Zuverlssigkeitstest, Regressionstest, Benutzbarkeitstest. Die Testart kann sich auch auf eine odermehrere Testebenen oder -phasen beziehen. Synonym fr die Testart ist der Testtyp.21 Testverfahren oder auch die Testmethode ist zum einen ein planmiges, auf einem Regelwerk aufbauendes Vorgehen zurHerleitung und/oder Auswahl von Testfllen. Zweitens definiert die Testmethode das Vorgehen (z.B. manuell, Einsatz einesMitschnittwerkzeugs, ... ) bei der Durchfhrung von Tests.



Tabelle 6: bersicht Prfverfahren je Testobjekt und Teststufe

Anhand der Tabelle 6 kann abgeleitet werden, dass z.B. fr Testobjekte vom Typ Transaktion undeiner Risikoeinstufung mit dem Wert 1 fr die Fehlereintrittswahrscheinlichkeit im Modultest fr dieTestart Funktionstest die Testfallermittlungsverfahren Intuitive Testfallermittlung undquivalenzklassenanalyse in den Ausprgungen:

? zulssige/unzulssige quivalenzklassen

? zulssige/unzulssige Wertebereiche fr Kann-/Pflichtfelder sowie

? zulssige Kombinationen von quivalenzklassen anzuwenden sind.Beim gleichen Testobjekttyp aber mit der Risikoeinstufung 3 werden nur dieTestfallermittlungsmethoden Intuitive Testfallermittlung und quivalenzklassenanalyse in denAusprgungen:

? zulssige quivalenzklassen

? zulssige Wertebereiche fr Kann-/Pflichtfelderfr eine Anwendung empfohlen. Daraus resultiert eine geringere Testabdeckung als beiTransaktionen der Risikoeinstufung 1, die allerdings bewusst fr Testobjekte mit einer geringenRisikoeinstufung in Kauf genommen wird, um den Testaufwand in einem vernnftigen Verhltniszum Nutzen zu halten.

Eine Besonderheit betrifft Testobjekte, die in ihrer SAP-Funktionalitt nicht gendert wurden (keinenderung der Verarbeitung von Eingabewerten etc., z.B. nur nderung der Bezeichnung). Frdiese mssen im Modultest keine Testflle fr unzulssige Eingabeklassen/Kann-/Pflichtfelder-Klassen definiert werden, da sie im SAP-Standard schon mehrfach geprft wurden. Hier ist eshinreichend die grundstzliche Funktionalitt mittels Positiv-Testfllen nachzuweisen.

Die Spalte Verantwortung fr die QS der Testflle sagt aus, welche Rolle in der jeweiligenTeststufe die Verantwortung fr eine berprfung der Testflle hat. Zur berprfung gehrt u.a.eine regelmige Stichprobenprfung auf formale und inhaltliche Qualitt der Testflle.



5.2.2.1.2 Architekturbersicht der TestobjekteDie Architektur der Gesamtlsung wird im Architektur-berblick (siehe [9] im Anlagenverzeichnis)spezifiziert.

Die Testumgebung mit den einzelnen Komponenten und deren Schnittstellen ist in [8] imAnlagenverzeichnis definiert.

5.2.2.1.3 AbgrenzungEs werden nur die im Rahmen des ERP-Einfhrungsprojekts ermittelten funktionalen und nicht-funktionalen Anforderungen getestet. Bereits bestehende Vor- und Nachverfahren die nicht imGeltungsbereich des Projektes ERP liegen werden nicht bercksichtigt.

5.2.2.2 Komponententest

5.2.2.2.1 TestzielDer Komponententest soll die Funktion der fr die BA relevanten und spezifisch ausgeprgtenKomponenten22 berprfen. Durch diese Teststufe weisen die Entwickler/Customizer dieFunktionsfhigkeit der von ihnen realisierten Komponenten und (Teil-) Applikationen nach.

Der Komponententest

Documents

090827 ERP-EP Testmanagemenkonzept V8 0