LinearQTM und SAP Reto Züst, CEO, Qcentris AG

Präsentation zum Thema: "LinearQTM und SAP Reto Züst, CEO, Qcentris AG"—  Präsentation transkript:

1 LinearQTM und SAP Reto Züst, CEO, Qcentris AG
Winterthur, 19. April 2012 Reto Züst, CEO, Qcentris AG Roman Rehm, Head of SAP Consulting, Qcentris AG

2 Warum muss SAP überhaupt getestet werden
Kein Testen der Funktion an sich („Standardsoftware“) Scope des Testens: kundenspezifische Produkte, Organisation, Prozesse und Buchungsregeln sind korrekt umgesetzt Integration in die Systemlandschaft Schnittstellen an Umsysteme Umfassende integrative Prozesse Fokus einerseits auf die korrekte technische Anbindung aber auch Korrektheit der Verarbeitung Customizing und Datenmigration Umfassende funktionale und integrative Tests Fokus auf die Korrektheit des konkreten kundenspezifischen Customizing von SAP SAP Basis nur rudimentäre funktionale Tests Fokus auf Last- und Performance sowie die korrekte Batch- und Online Verarbeitung

3 Testen kann optimiert werden und kostenoptimale Ansätze sind möglich
QCENTRIS Vergleich traditioneller Ansatz zu LinearQ™ Vorgehen QCENTRIS ist auf das Thema Testen und evolutionärer Change fokussiert. Die Firma verfügt über einen eigenen methodischen Ansatz LinearQ™, welcher eine Optimierung im Testen sicher stellt Testfälle werden systematisch mittels der linearen Expansion erarbeitet Design erfolgt in Kleingruppen Tosca wird als Testwerkzeug empfohlen 100 % Testcoverage Anzahl Testfälle 50 % 0 % LinearQ™-Test Traditionelle Ansätze Reduktions-potential (Bsp.: bei 50 % Coverage 60 – 70 %) Optimierungs-potential (mehr Abdeckung bei gleicher Anzahl Testfälle LinearQ™ Nutzen / Risiken LinearQ™ beinhaltet eine klare Ausrichtung auf: Fachlich- / funktionale Abdeckung Restrisiko und Finanzierbarkeit Bisherige Ansätze fokus-sieren vorwiegend auf Anzahl Testfälle /-objekte KonkreteTestfälle, welche auch von Nicht-Experten ausgeführt werden können Kostenoptimaler Ansatz Schonender Einbezug des Fachbereichs

4 LinearQ™ - eine intelligente Methode zum Testen
Um ein optimales (aus Sicht Testaufwand vs. Risikoabdeckung) Testfallportfolio zu erhalten, müssen zwei Voraussetzungen erfüllt werden: die Risiken müssen bekannt sein und die Testfälle müssen methodisch ermittelt werden. Risikobewertung Dient als Basis, um die Wichtigkeit eines Testfalles für die Risikoabdeckung des Vorhabens zu ermitteln. Lineare Expansion Dient als Methode, um die richtige und nicht maximale Anzahl von Testfällen zu ermitteln. Üblicherweise werden die Elemente ‘Häufigkeit’ und ‘Ausfallkosten’ bewertet und auf Basis derer ein Risikowert berechnet. Es wird ein Standardtestfall und je weiterer Varianz eines Attributes ein weiterer Testfall definiert. Häufigkeit Ausfallkosten RISKO-WERT 5 > Nutzung pro Woche Workaround > 1024 4 > Nutzung pro Woche 3 Workaround > 512 2 Workaround > 256 > 100 Nutzungen pro Woche

5 Zur Hochautomatisierung wird nebst LinearQ™ Tosca (als Tool) verwendet
Vergleich Automatisierung mit / ohne Tosca Vergleich der Kosten (Set-up und Maintenance) 100 % Testcoverage Anzahl Testfälle 50 % 0 % LinearQ™-Test Exploratives Testcasedesign - 60 % - 75 % Tosca Klass. Ansatz Erhebliche Vorteile in der Automa-tisierung mit Tosca und LinearQ™-Test; positiver ROI bereits nach 3-5 Retests

6 Zahlen und Fakten zum Testing
Testfall-Definition Klassischer Ansatz LinearQ™ Testfall-Design Min. 10 Min. Testfall-Spezifikation 30 Min. Testfallautomatisierung Automatisierung mit QTP oder eCATT Automatisierung mit TOSCA und LinearQ™ Framework / Konnektoren pro Applikation PT pauschal - Nachdokumen-tation pro TF 30 – 40 Min. - Aufbau pro Integrations-testfall 150 – 180 Min. 60 Min. Maintenance pro Integra-tionstestfall Min. Min.

7 Welche Ergebnisse wurden erzielt
Welche Ergebnisse wurden erzielt? Ist dies nur etwas für „Grosse“ oder auch für „Kleine“? Systematisches und methodische Vorgehen Kundenbeispiele Branche Herausforderung Ergebnis Dienst-leister (ca. 700 MA) SAP Releasewechsel FI/CO/MM/SD Aufbau von 800 man. und 200 autom. TF Coverage von¨über 90 % bei minimalen Kosten Industrie (> 25’000 MA) SAR HR/ FI/ CO/ SD Aufbau von 300 Regressions-TF für 3 Ländergesesellschaften Vollautom. Regr.tests Reduktion der Durchlaufzeit um über 50 % Sozialversiche-rung (5’000 MA) Aufbau eines vollautomatischen Regressionstests mit ca. 500 TF Reduktion der Testkosten um über 75 % Telekom (> 10’000 MA) Zusammenführung von zwei Altsystemen SAP (R/3, CRM, SRM, BW) 7000 Testfälle mit Abdeckung 85% neu erstellt 7

8 Lösungen mit «Zahlen und Fakten»
Testfall-Set mit einer Coverage von 35 % (ca. 200 – 300 TF)1) Komplette Solution (inkl. Tools) Beinhaltet Aufbau und Unterhalt der Lösung zu einem Fixpreis «Kleine Testlösung» als Managed Service Testfall-Set mit einer Coverage von 85 % (ca. 800 – 1000 TF) 1) Komplette Solution (inkl. Tools) Beinhaltet Aufbau und Unterhalt der Lösung zu einem Fixpreis «Grosse Testlösung» mit Managed Servide «Grosse oder kleine» Testlösung» I a) I b) Die Frage, ob eine «kleine» oder «grosse» Lösung Sinn macht, ist nicht abhängig von der Unternehmensgrösse Entscheidend ist der erforderliche und gewünschte Abdeckungsgrad im Testen bzw. die verfügbaren finanziellen Mittel (für das Testen) Testing: Fachbereich: Kosten pro 100 TF pro Jahr in (On-/ Offsite Modell) bei einem 4 Jahresvertrag Testing: Fachbereich: Kosten pro 100 TF pro Jahr (On- / Offsite Modell) bei einem 4 Jahresvertrag 28’000 CHF 8’000 CHF2) 25’000 CHF 8’000 CHF2) 1) Pro Modul, 5 vollständige Ausführungen pro Jahr, nur automatisierte Testfälle 2) Annahme: interner Kostensatz ist ca. 160 CHF

9 Unser Ansatz ist vollständig in die SAP Welt integriert und SAP zertifiziert
Roman

10 Danke

11 Anhang

12 Lineare Expansion Mittels der linearen Expansion werden im Rahmen des Test Case Design die Testfälle konkret aus Basis der Attribute und deren Ausprägungen entwickelt. Ausganglage Es soll getestet werden, ob einer Versicherungsprämie korrekt ermittelt wird. Dabei werden die folgenden Attribute und deren Ausprägung verwendet: Mathematische Kombinatorik In diesem Fall werden alle theoretisch möglichen Kombinationen getestet. Resultat: 256 konkrete Testfälle 100% fachliche Abdeckung Lineare Expansion Es wird ein Standardtestfall und pro weitere Ausprägung ein weiterer Testfall definiert, bei welchem die anderen Ausprägungen sich aber nicht verändern. Resultat: 11 konkrete Testfälle (95% Reduktion) ca. 80% fachliche Abdeckung Jetzt kommt noch Stadt / Land dazu Zeige wieviele TF wir hätten, wenn alle Attributwerte miteinander kombiniert werden würden: 4 mal 2 mal 2  16. Und wenn jetzt noch die Bonus Malus Stufe (18 werte) dazukommen würde? Wo wären wir dann: 288 TF. Wir haben nach dem Prinzip der größten Mächtigkeit weiterhin 4 TF Frage: Vergleich orthogonal mit nicht orthogonal: Was ist das Massenphänomen in der Praxis?  orthogonal

13 TOR | Testdaten-Objekt Register (Stateful) (I)
Eindeutige, logisch sprechende Namen zur Identifikation gleicher Objekte (Bsp: „K_Priv_AAA“ … für die genannte Person) Mitführung und Pflege der Status der Testdatenobjekte bei Veränderungen Automatisches Aufsuchen und dynamisches Einbinden passender (= richtiger logischer Name und Status) Testdatenobjekte TOR verbrauchen Verbrauch registrieren verwenden abholen Statusänderung registrieren erzeugen registrieren New

14 TOR | Testdaten-Objekt Register (Stateful) (II)
SuT Test Execution TOR getID C_Prv_AAA, New create C_Prv_AAA Kunde C_Prv_AAA existiert im SuT save register C_Prv_AAA, New Kunde C_Prv_AAA ist registriert Open Loan Account create AL_Std_200 save Konto AL_Std_200 existiert im SuT

15 TOR | Testdaten-Objekt Register (Stateful) (III)
SuT Test Execution TOR register AL_Std_200 , New Konto AL_Std_200 ist registriert register C_Prv_AAA, hasLoan Kunde C_Prv_AAA steht auf hasLoan create C_Prv_AAA Kunde C_Prv_AAA existiert im SuT save register C_Prv_AAA, New Kunde C_Prv_AAA ist registriert Open Loan Account getID C_Prv_AAA, New create AL_Std_200 save Konto AL_Std_200 existiert im SuT

16 Zeitlicher Aufwand und Einbezug der IT und des Fachbereichs
Die IT und der Fachbereich wird im Vergleich zu klassischen Ansätzen weniger belastet. Der Einbezug findet sehr komprimiert statt. Ges. Aufw. Test Tätigkeit Verantw. Aufwand im operativen Doing (in %) … IT / Fach bereich … Testteam 1 % Funkt. Struktur 9 % Testfall-Design Testfall-Spezifikation 30 % 60 % Test-ausführung 0 % 50 % 100 %

17 Kundenprojekte 2011/2012 - Auszug
Kunde: Branche Telekommunikation, Wien (5.000 – MA) SAP-Migrationsprojekt (R/3, CRM, SRM, BW) Aufbau eines Portfolios mit ca hauptsächlich manuellen TF nach LinearQTM Kunde: Dienstleistungen, Wiesbaden ( MA) SAP-Releasewechsel FI/CO/MM/SD Portfolio mit ca. 800 manuellen / 200 automatischen TF nach LinearQTM Kunde: Sozialversicherung, Österreich (14 Träger) SAP-Implementierungsprojekt (Apothekenabrechnung) Vollautomatisierter Fachtest nach LinearQTM, ca. 500 TF Kunde: Energieversorger, Wien ( – MA) SAP-Implementierungsprojekt Vollautomatisierter Fachtest nach LinearQTM , ca. 800 TF Kunde: Versicherungskonzern, Deutschland ( – MA) SAP Treasury, Vollautomatisierter Fachtest nach LinearQTM , ca. 700 TF Kunde: Versicherungskonzern, Österreich ( – MA) SAP for Insurance, Vollautomatisierter Fachtest nach LinearQTM , ca TF Kunde: Industriekonzern, Österreich ( – MA) SAP HR, FI/CO/SD, Vollautomatisierter Fachtest nach LinearQTM , ca. 300 TF Kunde: Branche Telekommunikation, Wien (5.000 – MA) SAP-Migrationsprojekt (R/3, CRM, SRM, BW) Aufbau eines Portfolios mit ca hauptsächlich manuellen TF nach LinearQTM Automatisierung der Glattläufer-Testfälle Erreichtes Ziel: Verdoppelung der Testabdeckung Roman