Qualitätssicherung im BI Lifecycle [Session D1] Uetliberg,

Transkript

1 [Session D1] Uetliberg,

2 Das erwartet Sie in den kommenden 45 Minuten: AGENDA Warum Testing? Wo stehen wir heute? Arten von Tests Testing im BI/DWH Bereich Testing in Real Life Vorstellung TOSCA Testsuite TOSCA Commander Oberfläche/Bereiche Frontend-Testing mit TOSCA Ausblick Testing DWH / DB / ETL mit TOSCA Slide 2

3 Slide 3

4 WARUM TESTING?

5 Wenn man einer Software zu 100% vertraut, gibt es zwei Ausgänge: 1. Man bekommt einen Freund fürs Leben 2. Man bekommt eine Lektion fürs Leben Slide 5

6 Integriertes Testing führt zu schnellerer Time-To-Production. MOVE TO PRODUCTION Entwicklung Abnahme Produktion Getestet? Getestet? Getestet? Slide 6

7 Integriertes Testing führt zu vollständiger Compliance. AUDIT / LEGAL / COMPLIANCE Entwicklung Abnahme Produktion Getestet? Getestet? Getestet? Slide 7

8 Integriertes Testing erhöht die Sicherheit. DATENSICHERHEIT / DATENSCHUTZ Entwicklung Abnahme Produktion Getestet? Getestet? Getestet? Slide 8

9 Slide 9

10 Würden Sie eine Software ungetestet in die Produktion lassen? MOVE TO PRODUCTION Entwicklung Produktion Analyse Fix Produktion Getestet? Getestet? Systemverwendung Rückmeldung Systemverwendung Getestet? Slide 10

11 Wird die Einhaltung von Richtlinien nicht gewährleistet, folgen Konsequenzen! AUDIT / LEGAL / COMPLIANCE Entwicklung Produktion Analyse Fix Produktion Getestet? Getestet? Systemverwendung Rückmeldung Systemverwendung Getestet? Slide 11

12 Datensicherheit und Datenschutz sind kritische Bereiche welche nicht ungetestet bleiben dürfen! DATENSICHERHEIT / DATENSCHUTZ Entwicklung Produktion Analyse Fix Produktion Getestet? Getestet? Systemverwendung Rückmeldung Systemverwendung Getestet? Slide 12

13 Slide 13

14 WO STEHEN WIR HEUTE?

15 Softwaredevelopement kennt Testing als fixen Bestandteil schon länger. SOFTWAREDEVELOPEMENT Tests als integrativer (Qualitäts-)Bestandteil der Softwareentwicklung Entwicklung von Tests analog/bevor der zu testenden Komponente (Test Driven Developement) Wasserfall-Modell seit 1956, V-Modell seit 1979, Spiralmodell seit Slide 15

16 Testing und SCRUM gehören einfach zusammen. SCRUM Testing als wichtiger Bestandteil jeder Phase/Sprint Entwicklung und Abgrenzung Testfälle je Sprint Konstante Regressionstests für alle Sprints Testcases Testcases Testing Slide 16

17 (Integrierte) Testing-Prozesse und Test-Automatisierung tragen zur Agilität bei. WAS KÖNNEN WIR VON AGILEM VORGEHEN LERNEN? Testing als integrativer Bestandteil eines Projekts, nicht in erster Linie nur als eigene Phase oder Teilschritt Rolle «Tester» vs. «Testing» als Aufgabe für jedes Projektmitglied «GETESTET» soll nicht einfach ein abschliessendes «OK» sein, sondern ein Gütesigel für die Qualität des Projekt-Outcomes Eine Vielzahl von Tests bedingt einen hohen Automatisierungsgrad Slide 17

18 Manuelles Testing ist oft mit hohem Zeit-, Kosten- und Personalaufwand verbunden. TESTER TESTEN Slide 18

19 Toolunterstützung und ein hohes Mass an Automatisierungsmöglichkeiten sparen Zeit, Geld und die Bindung von Personal-Ressourcen. TESTER DEFINIEREN TESTFÄLLE Slide 19

20 ARTEN VON TESTS

21 Je nach Bereich ist das Testing schwieriger vorzunehmen jedoch nicht weniger wichtig! NACH FUNKTIONS-BEREICHEN Funktional spezifische Softwarefunktionen Login BI System Report editieren Client-Software starten Nicht-Funktional nicht direkt zuordenbare Funktionen Performance Usability (Security) Slide 21

22 Viele Testingprozesse sind in Stufen aufgebaut einzelne Stufen werden nach Bedarf vorgezogen oder übersprungen. NACH STUFEN UND ZEITPUNKT Modul-Test/ Unit-Test Test einer einzelnen Funktion / eines Moduls / einer Unit Z.B. Test einer Formel in einer Variable im Report Integration-Tests / System-Test Test einer Gruppe von Modulen Test von ETL-Ladeprozess in Kombination mit aufgerufenem Report (Login & DB-Abfrage) UserAcceptance-Tests / Abnahme-Tests Test der von den End-Benutzern erwarteten Anforderungen an die BI-Lösung Erstmalige Tests Testen neuer oder explizit geänderter Funktionalitäten Funktioniert die Weiterleitung auf HTTPS? Regressionstests Funktionalität des Systems aufgrund einer oder mehrere Änderungen Funktioniert SSO nach einem Patch-Update weiterhin für alle User? Können alle Reports aktualisiert werden? Slide 23

23 Nicht immer ist sichtbar, was im Hintergrund passiert, wenn getestet wird. NACH SICHTBARKEIT Whitebox-Tests: input internal system output Testen eines Reports im Entwurfsmodus Blackbox-Tests: input Blackbox output Testen eines Reports im Ansichtsmodus Slide 24

24 TESTING IM BI / DWH BEREICH

25 Qualität in allen Bereichen des BI-Lifecycle bedeutet auch Testing in allen Bereichen. TESTING IM BI / DWH BEREICH Quellsystem Marts Cubes Semantic Layer Staging ETL Data Warehouse Reports Testing Testing Testing Testing Testing Testing Intra-System-Tests Slide 26

26 Ein toter Mann schreit nicht externe Testing-Tools können unabhängig vom System (und dessen Eigenheiten/Fehlern) agieren. TESTING IM BI / DWH BEREICH Quellsystem Marts Cubes Semantic Layer Staging ETL Data Warehouse Reports Testing Inter-System-Tests Slide 27

27 Backend-Tests sind meist einfacher zu automatisieren jedoch zt. schwerer wartbar. TESTING IM BI / DWH BEREICH - BACKEND (Quellsystem) Test im Rahmen der Quellsystem-Entwicklung Staging Test der bezogenen Daten / Files aus dem Quell-System ETL Meist direkt im ETL-Workflow, evtl. Funktionstest ETL-Tool Core DataWarehouse Datenbankperformance, Daten- Szenarios(Queries), Datawarehouse-Tool-Funktionen Plattform Funktionstests, End-To-End-Testing / Probes (BO Plattform) Slide 28

28 Frontend-Tests sind oft schwieriger zu automatisieren, jedoch einfacher zu warten und durchzuführen. TESTING IM BI / DWH BEREICH - FRONTEND Universen Strukturtests auf Basis der Metadaten Datentests auf Basis von Testdaten & Reports Reports Strukturtests auf Basis der Metadaten Datentests auf Basis von Testdaten & Reports Layoutvergleich Frontend-Tools Funktionstest der Benutzeroberfläche Slide 29

29 Ein Testfall ist ein greifbares Konstrukt. TESTCASE DESIGN Testfälle sind logisch, nachvollziehbar, eindeutig, strukturiert, haben ein Resultat und sind dokumentiert Testfälle besitzen ein oder mehrere Testobjekte Jedes Testobjekt benötigt ein Referenzobjekt Datengrundlagen für Referenz- und Testobjekte müssen kongurent sein, d.h. entweder stabil oder sich gleichartig weiterentwickeln Beispiel Report Testing: Gleiche Datenbank und / oder gleicher Ladestand, Gleiches Set an Parameter-Infos etc Slide 30

30 Testdaten geben den Tesfällen die notwendigen Inhalte. TESTEN MIT TESTDATEN ABER WOHER? Variante 1: Es gibt ein Testquellsystem, auf welchem im Idealfall beliebige Testfälle simuliert werden können Variante 2: Fiktive Quelldaten werden im DWH generiert, z.b. auf dem Staging-Layer Testdaten müssen stabil sein: Während der Entwicklung: Eigenes Testsystem, wo immer das gleiche Set an Referenz-Quelldaten geladen wird Während Produktion: Bestimmen eines Datensets, welches nicht mehr oder nur noch sehr selten ändert, z.b. abgeschlossene Zeitperiode Während der Tests: Testdaten verbrauchen sich nicht d.h. sie verändern sich nicht durch die Tests Slide 31

31 TESTING IN REAL LIFE

32 Wo begonnen wird ist weniger prioritär wichtig ist, dass überhaupt begonnen wird! TESTING IN REAL LIFE WO / WIE BEGINNE ICH? Quellsystem Marts Cubes Semantic Layer Staging ETL Data Warehouse Reports Top down Testing Buttom up Testing Slide 33

33 Korrekte Daten sind die Grundlage der Qualität im BI-System von der Entstehung bis zur Auswertung. TESTING IN REAL LIFE BOTTOM-UP Vorteile: Data Quality ab Datengrundlage Integration im ETL-Prozess Testdriven Developement / (Whitebox-Tests) Nachteile: Manuelles Testing schwierig Hoher Wartungsaufwand DWH / ETL-Experten Slide 34

34 Durch schnellere und einfachere Einführung von Tests können Fehler schneller gefunden und behoben werden. TESTING IN REAL LIFE TOP-DOWN Vorteile: Testing durch Business / IT / unabhängig Implementierung Testing Manuelles Testing Nachteile: Fehler bereits im Endprodukt / in der Produktion(?) Rückverfolgung entlang DWH-Lifecycle Blackbox-Tests Slide 35

35 Komplexe und dynamische Systeme können eine große Empfindlichkeit auf kleine Abweichungen in den Anfangsbedingungen zeigen (Butterfly-Effect). TESTING IN REAL LIFE WANN TESTE ICH? Testdriven Developement Report-Developement Universe-Developement DB/DWH/ETL-Developement Tool Migration / Patching Slide 36

36 TOSCA TESTSUITE < > BUSINESS INTELLIGENCE

37 TOSCA Testsuite zur effektiven Umsetzung von End-To-End Testing-Vorhaben. TOSCA TESTSUITE Software für Testautomatisierung und Testmanagement Zahlreiche Adaptoren / Engines (.NET, HTML, Java, VB, SAP, Siebel, Excel,.) GUI- und non-gui-tests Intuitive Grafikoberfläche - kein Scripten oder Coden Flexible API Slide 38

38 Erfolgreich automatisiert testen im BI/DWH Bereich mit TOSCA Testsuite. BI-SPEZIFISCH TESTEN MIT TOSCA Slide 39

39 Erfolgreich automatisiert testen im BI/DWH Bereich mit TOSCA Testsuite. TRICENTIS TRICENTIS Technology & Consulting GmbH mit Sitz in Wien Softwareunternehmen mit Hauptprodukt TOSCA Testsuite Ca. 180 Mitarbeiter mit Standorten in EMEA, APAC, Australien, USA Ca. 400 Kunden weltweit 2014: Visionary Leader in Gartners Magic Quadrant for Integrated Software Quality Suites Report Slide 40

40 TRICENTIS KUNDEN Slide 41

41 TOSCA COMMANDER OBERFLÄCHE / BEREICHE

42 Die TOSCA-Commander-Oberfläche ist strukturiert und intuitiv bedienbar. ÜBERSICHT Slide 43

43 Anforderungen werden zu Beginn eines jeden Testingprojekts angelegt. GELBER BEREICH - REQUIREMENTS Organisation, Aufbau, Verwaltung und Visualisierung verschiedener funktionaler Bereiche und Anforderungen von Softwaretestprojekten Slide 44

44 Ein Testfall kann je nach Anzahl von Attributen und Daten viele Kombinationsmöglichkeiten haben grundsätzlich gilt: Minimale Testfall-Anzahl bei maximaler Testabdeckung. ROTER BEREICH - DESIGN Testdaten getrennt von den Testfällen festlegen und alle benötigten Kombinationen möglicher Testfälle zur Erreichung der Testabdeckung festlegen Slide 45

45 Testfälle sollten stets strukturiert und geordnet angelegt werden für verschiedene Testfallkombinationen gibt es Templates. BLAUER BEREICH - TESTCASES Strukturierung von Testfällen und Testschritten, Zuordnung von Daten und TestCaseDesign Slide 46

46 Strukturierter Überblick über ausgeführte Testfälle und den Ergebnissen. GRÜNER BEREICH - EXECUTION Ausführungslisten strukturieren die Testfälle und zeigen die Ergebnisse an Slide 47

47 FRONTEND-TESTING MIT TOSCA

48 Vor der Migration ist nach der Migration oder etwa doch nicht? SZENARIO1: REPORT-VERGLEICH Plattform Migration BO 3.1 auf BO 4.1 DB Migration Oracle auf Teradata 1. Export Dokumente Reference 2. Export Dokumente Current 3. Testfälle in TOSCA erstellen 4. Testfälle mit TOSCA ausführen 5. Ergebnis-Analyse Slide 49

49 Funktioniert noch alles? SZENARIO2: FUNKTIONALITÄTSTEST BI-LAUNCHPAD Plattform Migration BO 4.1 SP 5 auf BO 4.1 SP6 1. Testfälle in TOSCA erstellen 2. Testfälle mit TOSCA ausführen 3. Ergebnis-Analyse Slide 50

50 Der Server läuft wie steht es mit den Clients? SZENARIO3: FUNKTIONALITÄTSTEST CLIENTTOOLS Plattform Migration BO 4.1 SP 5 auf BO 4.1 SP 6 Clienttools Migration 4.1 SP 5 auf 4.1 SP 6 1. Testfälle in TOSCA erstellen 2. Testfälle mit TOSCA ausführen 3. Ergebnis-Analyse Slide 51

51 AUSBLICK TESTING DWH / DB / ETL MIT TOSCA

52 Backend-Testing at it s best mit TOSCA VITAL-CHECKS. TESTING ETL TOSCA VITAL-CHECKS TRICENTIS GmbH Slide 53

53 Bekannte Tests zusammengefasst in einem Add-In. TESTING ETL TOSCA VITAL-CHECKS Infrastructure & Delivery Alle Tabellen sind vorhanden und vollsändig geladen Record & Relation profiling Completeness (C), Uniqueness (U), Referential Integrity (R), DataType(D) Single column profiling KPI checks (Summe, Durchschnitt, ) Spalten-Analyse (Feld-Länge, max, min, ) Zahlenverteilung innerhalb der Spalte Slide 54

54 Multicolumn-Testing mittels Szenarien und Profilen den Fehlern im DWH auf der Spur. TESTING CORE DATA WAREHOUSE TOSCA-IQ TRICENTIS GmbH Slide 55

55 Erfolgreich automatisiert testen im BI/DWH Bereich mit TOSCA Testsuite. TESTING CORE DATA WAREHOUSE TOSCA-IQ Abweichungs-Tests zur Überprüfung von «Ausreissern» Datenprofile zur Überprüfung der Businesslogik oder dessen Änderung(en) TRICENTIS GmbH Slide 56

56 Die Vorteile von integriertem, umfassenden und toolgestütztem Testing liegen auf der Hand. ZUM MITNEHMEN Testing ist ein wichtiger Faktor für die Qualität jedes BI/DWH-Systems Testing ist stets als integrierter Bestandteil jeder DWH-Architektur zu verstehen Testing dient zur Vermeidung von unnötiger Zeit- und Geldverschwendung Testautomatisierung spart Zeit, Geld und die Bindung von Personal Agilität TOSCA Testsuite ist DIE umfassende & einfache Lösung um in allen Bereichen des BI-Lifecycle Testing durchzuführen Slide 57

57 Slide 58

58 Wir freuen uns auf angeregte Gespräche mit Ihnen Alexander Pröm BI Consultant Follow Follow