Effiziente Qualitätssicherung im Datawarehouse

Transkript

1 Effiziente Qualitätssicherung im Datawarehouse DOAG 2011 Eckhard Beisswenger irix Software Engineering AG Basel (CH)

2 Agenda Motivation Warum dieser Beitrag? Zielsetzung und Abgrenzung Datawarehouse-Projekte Besondere Herausforderungen und Beispielszenario Der Lösungsansatz Einfache, aber effiziente Regressionstests Ausbau in Stufen Testzyklen, Automatisierung, V-Modell Fazit Schlussbemerkungen und Diskussion 2

3 Motivation Enstanden aus realem DWH-Projekt irix AG (Basel/CH): 10-jährige Erfahrung in DWH/BI-Projekten (Beratung, Konzeption, Realisierung) Verschiedene Kunden, Branchen und Grössendimensionen Technologische Schwerpunkte: Oracle, ETL, BI, Applikationentwicklung Und der Referent selbst? Certified Software Tester (ISTQB) Schwerpunktverschiebung vom Entwickler zum Qualitätssicherer kein seltener Fall? 3

4 Zielsetzung Praxisnaher Ansatz Leichter Einstieg ins Testing mit SQL-Bordmitteln Ausbaufähigkeit zu integriertem QS-Konzept Qualitätsorientierten Projektablauf fördern durch Senken von Hemmschwellen 4

5 Abgrenzung Keine out-of-the-box Lösung Keine Verwendung von Testtools und frameworks: Fokus auf Methode, nicht auf Testtechnik Kein Ansatz für Unit Testing oder test driven development, sondern für unabhängiges, releasebasiertes Testen 5

6 Agenda Motivation Warum dieser Beitrag? Zielsetzung und Abgrenzung Datawarehouse-Projekte Besondere Herausforderungen und Beispielszenario Der Lösungsansatz Einfache, aber effiziente Regressionstests Ausbau in Stufen Testzyklen, Automatisierung, V-Modell Fazit Schlussbemerkungen und Diskussion 6

7 DWH als Herausforderung Ein Datawarehouse ist ein zentrales strategisches Unternehmensinstrument Hohe Erwartungen an Kennzahlen, Qualität und Investitionsschutz Die Vertrauensbildung in die IT-Lösung kann projektentscheidend sein Trend: Gesteigerter Fokus auf Qualitätssicherung auch im DWH/BI-Bereich Auch DWH- und DB-Entwickler müssen sich diesen steigenden Qualitätsansprüchen stellen 7

8 Technische Herausforderung Große Datenmengen und komplexe Fachregeln Datenverarbeitung nicht durch Anwender getrieben, sondern durch automatisierte Prozesse (ETL) Fehlen einer einfach zu bedienenden Testoberfläche Domänenfremde Testmethoden stoßen an Grenzen. Oft sind nur Entwickler in der Lage, Tests effizient durchzuführen. 8

9 Quellsysteme Schnittstellen Reporting Ein Beispielszenario Oracle ETL-Prozess SAP Kassensystem «Interface» Staging Area DWH Anwender Flat Files FTP- Server ORACLE Datenverarbeitungsprozess 9

10 Ein Beispielszenario Anforderungsanalyse Spezifikation Realisierung Tests Produktivsetzung 10

11 Kosten Strategisches Ziel: Kosten! Optimum Qualitätskosten Fehlerkosten Gesamtkosten Anteil Qualitätssicherung 11

12 Agenda Motivation Warum dieser Beitrag? Zielsetzung und Abgrenzung Datawarehouse-Projekte Besondere Herausforderungen und Beispielszenario Der Lösungsansatz Einfache, aber effiziente Regressionstests Ausbau in Stufen Testzyklen, Automatisierung, V-Modell Fazit Schlussbemerkungen und Diskussion 12

13 Regressionstests - Grundprinzip SOLL Quelldaten Testlauf 1 Testlauf 2 Systemzustand 1 Systemzustand 2 Ergebnis1 IST? Ergebnis 2 Abweichung 13

14 Regressionstests Aussagekraft Vorteil: Zuverlässiges Testen der alten Funktionalität (Rückwärtskompatibilität zum Zustand 1) Nachteil: Keine Aussage über neue Funktionalität (Korrektheit im Zustand 2) 14

15 Regressionstests als Einstieg Rückwärtskompatibilität hat große Bedeutung für Vertrauensbildung und Investitionsschutz Standardisierungs- und Automatisierungsgrad ist entscheidend Primär technische (nicht fachliche) Herausforderung Für Entwickler leicht zu realisieren Große Wirkung bei geringer Komplexität 15

16 Quellsysteme Schnittstellen Reporting Black Box: Teststrecken Teststrecke C Oracle Teststrecke A Teststrecke B Teststrecke D ETL-Prozess SAP Kassensystem «Interface» Staging Area DWH Anwender Flat Files FTP- Server ORACLE Datenverarbeitungsprozess 16

17 Erstellung der Quelldaten Methode A Explizite Testfälle: Manuelles Erstellen oder Ermitteln von Testdatensätzen (explizite Funktionsabdeckung). Methode B Testsets aus Realdaten: Produktive Datensets (mehr oder weniger unbekannte Inhalte) 17

18 Erstellung der Quelldaten Methode 1 - Explizite Testsets Methode 2 - Testsets aus Realdaten Plus Exakte funktionale Abdeckung. Erwartetes Ergebnis genau bekannt. Geringer Aufwand. Breite Abdeckung auch unerwarteter Situationen. Aussagen über Performance und Stabilität. Minus Hoher manueller Aufwand. Geringer Umfang des Testsets. Keine Abdeckung unerwarteter Situationen. Keine explizite Abdeckung. Testsets muss häufiger neu erstellt werden. 18

19 Erstellung der Zieldaten (Soll) Das Prinzip von Henne und Ei : Zieldaten (Sollergebnisse) basieren immer auf vorhergehendem Testlauf Testergebnisse müssen verifiziert sein Testergebnisse müssen in wiederverwendbarer Form vorliegen 19

20 Verwaltung der Testsets ID Kasse Zeit Verkaeufer Artikel Anzahl Summe :23: :24: :25:13 muellerb B1 2 CHF muellerb A9 1 CHF 0.99 maieru X 1 CHF Originaltabelle: Bewegungsdaten BUCHUNGEN TESTID Kasse Zeit Verkaeufer Artikel Anzahl Summe TESTSET QS_COMMENT :00: :01: :02:00 testuser A1 2 CHF Regression Release 1.5 testuser A2 1 CHF 0.99 Regression Release 1.5 testuser E0 1 CHF Regression Release 1.5 MUST_SUCCCEED MUST_SUCCCEED MUST_FAIL: Falscher Artikel! Testtabelle: Bewegungsdaten BUCHUNGEN_TEST (mit Metainformationen) 20

21 Verwaltung der Testsets ID (Primary Key) Tag Filiale (Foreign Key) Sparte (Foreign Key) Umsatz (CHF) Umsatzziel Zielerreichung Ziel-Facttabelle: UMSATZ ID (Primary Key) Tag Filiale (Foreign Key) Sparte (Foreign Key) Umsatz (CHF) Umsatzziel Zielerreichung TESTSET Regression Release Regression Release Regression Release 1.5 Soll-Facttabelle: UMSATZ_TEST (mit Metainformationen) 21

22 Testsets (inaktiv) Quelldaten TEST Testumgebung (Oracle) DWH TEST Factdaten (SOLL) 1. Aktivierung 3. Abgleich Quelldaten (aktiv) Quelldaten DWH Factdaten (IST) Tester 4. Analyse Abweichungen ( Delta-Report ) 2. Ausführung 5. Aktualisieren Ladeprozess Testumgebung (ETL) 22

23 Aktivieren setup.sql Abgleich analyze.sql Aktualisieren update.sql 23

24 Abweichungen analysieren Zeitpunkt Testlauf Testergebnis IST Testergebnis SOLL Zieltabelle Anzahl IST Anzahl SOLL Abweichende Records :39 Regressionstests Rel. 2.0 Sollergebnis Rel. 1.9 UMSATZ :39 Regressionstests Rel. 2.0 Sollergebnis Rel. 1.9 ARBEITSZEIT :39 Regressionstests Rel. 2.0 Sollergebnis Rel. 1.9 BUCHUNGEN

25 Agenda Motivation Warum dieser Beitrag? Zielsetzung und Abgrenzung Datawarehouse-Projekte Besondere Herausforderungen und Beispielszenario Der Lösungsansatz Einfache, aber effiziente Regressionstests Ausbau in Stufen Testzyklen, Automatisierung, V-Modell Fazit Schlussbemerkungen und Diskussion 25

26 Testlauf Testlauf Testlauf Tester Fach Entwickler Gemeinsame Verifizierung + Fehlerbehebung? Delta 1.x >> 2.1? Delta 2.1 >> 2.2? Delta 2.2 >> 3.0 SOLL Rel. 1.x SOLL Rel. 2.1 SOLL Rel. 2.2 SOLL Rel. 3.0 Abgleich Abgleich Abgleich? Ergebnis Rel. 2.1 Ergebnis Rel. 2.2 Ergebnis Rel. 3.0 Aktualisierung Aktualisierung Aktualisierung Testset Rel. 2.1 Testset Rel. 2.2 Testset Rel. 3.0 Testset Rel. 3.x Release 1.x Release 2.1 Release 2.2 Release 3.0 Release 3.x Projektverlauf 26

27 Ausbaupotential Aufsetzen kontinuierlicher Testzyklen Testfortführung von Release zu Release Besonders effizient bei produktiven Patches Automatisierung durch PL/SQL und Scheduled Jobs Aufbau eines leichtgewichtigen Frameworks Tägliche Testläufe Integrierte Qualitätssicherung Stufenweiser Ausbau zum V-Modell 27

28 V-Modell Anforderungsanalyse Abnahmetests Funktionale Spezifikation Systemtests Technische Spezifikation Integrationstests Komponentenspezifikation Komponententests Implementation 28

29 Agenda Motivation Warum dieser Beitrag? Zielsetzung und Abgrenzung Datawarehouse-Projekte Besondere Herausforderungen und Beispielszenario Der Lösungsansatz Einfache, aber effiziente Regressionstests Ausbau in Stufen Testzyklen, Automatisierung, V-Modell Fazit Schlussbemerkungen und Diskussion 29

30 Schlussgedanken Keine blaue Theorie, sondern in der Praxis erfolgreich umgesetzt Erfolgsentscheidend ist nicht die richtige Technik, sondern die richtige Denkweise Kein Plädoyer gegen Einsatz von Testframeworks und Testwerkzeugen, sondern komplementär! Senkung der Hemmschwelle fördert qualitätsorientiertes Projektvorgehen (und damit auch den effizienten Tooleinsatz) 30

31 Diskussion & Kontakt Eckhard Beisswenger irix Software Engineering AG 31