Agile BI in der Praxis - Agiles Testen

Agile BI in der Praxis
Agiles Testen
Andreas Ballenthin, Solution Architect
Thomas Flecken, Senior Consultant
OPITZ CONSULTING Deutschland GmbH

DOAG Konferenz
Nürnberg, 19.11.2013
Agile BI in der Praxis – Agiles Testen

© OPITZ CONSULTING GmbH 2013

Seite 1

Agenda

1.

Vorstellung OPITZ CONSULTING

2.

Testgetriebene Entwicklung - TDD

3.

Testvorbereitung

4.

Deployment

5.

Automatisierte Backendtests

6.

Automatisierte Frontendtests

7.

Testauswertung



Seite 2

1

Vorstellung OPITZ CONSULTING



Seite 3

Mission

Märkte

Wir entwickeln gemeinsam mit allen
Branchen Lösungen, die dazu führen, dass
sich diese Organisationen besser entwickeln
als ihr Wettbewerb.

 Branchenübergreifend
 Über 600 Kunden

Unsere Dienstleistung erfolgt
partnerschaftlich und ist auf eine langjährige
Zusammenarbeit angelegt.

29%
Handel / Logistik /
Dienstleistungen

29%
Industrie / Versorger /
Telekommunikation

42%
Öffentliche Auftraggeber / Banken und
Versicherungen / Vereine und Verbände

Leistungsangebot

Eckdaten

 Business IT Alignment
 Business Information Management
 Business Process Management
 Anwendungsentwicklung
 SOA und System-Integration
 IT-Infrastruktur-Management

 Gründung 1990
 400 Mitarbeiter
 9 Standorte



Seite 4

2

Test & Entwicklung



Seite 5

Anzahl Funktionalitäten

Automatisierte Tests sind Pflicht!
50
45
40
35
30
25
20
15
10
5
0

Alte Funktionalitäten
(Regressionstests)
Neue Funktionalitäten

S1 S2 S3 S4 S5 S6 S7 S8 S9 S10
Sprint

Aufwand für Regressionstests steigt stetig
Testabdeckung darf nicht Zufall überlassen bleiben
Testautomatisierung ist Pflicht!


Seite 6

Der tägliche Testzyklus
TDD

Testauswertung

Testvorbereitung

Frontendtests

Deployment

Verarbeitung 1..N
Test Verarbeitung 1..N



Seite 7

Testgetriebene Entwicklung - TDD
Entwicklung /
Erweiterung des Testfalls

erfolgreich

Ausführung des Testfalls

schlägt
fehl

Implementierung des
Codes
Fehler so früh wie möglich erkennen
Auch: Fachliche Schärfung


Seite 8

Testfälle hängen am Taskboard!

• .
 Einen Testfall übernehmen wird sicht- und erlebbar!
 Definition neuer und zu ändernder Testfälle im Planning II



Seite 9

Testgetriebene Entwicklung – TDD
 Erhöhte Testabdeckung
 Fachliche Schärfung
 Dokumentation
 Funktionsumfang des Codes
 Mögliche Fehlersituationen

 Grey-Box-Tests
 Kombination von Black-Box- und White-Box-Tests

 Software enthält ausschließlich getesteten Code
 Erfolgreiches Coding und erfolgreiche Testfälle sind
Eingangsbedingung für das Testsystem.
 Exploratives Testen rundet das Vorgehen ab


Seite 10

Werkzeuge und Stilmittel – Testfallkategorien

Kontextprüfberichte

Datenabgleiche innerhalb einer Schicht

Kennzahlentests

Datenabgleiche zwischen den Schichten

Performancetests

Datenabgleiche End-to-End

Anwenderberichte

Einhaltung von Konventionen

Metadatentests

Prüfungen auf das Data Dictionary
Inhalte von Fehlertabellen
Bereitstellen synthetischer Daten
Prüfung von Datenmigrationen



Seite 11

3

Testvorbereitung



Seite 12

TDD

Testauswertung

Testvorbereitung

Frontendtests

Deployment

Verarbeitung 1..N



Seite 13

Was testen wir heute?
 Welche Verarbeitungen?
 Es können nicht alle Verarbeitungen täglich laufen

 Wann?
 In welchen Umfang?
Test
NetzNetzabgleich abgleich

Deployment

19:00

01:00
20:00

23:30

Call Data
Records

03:00
02:00

Test
Call Data Records


03:15

06:30

Vertragsmanagement

08:00

Test
Vertragsmanagement


Seite 14

Wer testet denn heute?
 Es gibt Spezialisten
und rechte Hände
 Die Testverantwortlichen werden im Planning II bestimmt.
 Testvorbereitungen

A

J

J

K

F

B

T

D

 Konfiguration Cron-Jobs
 Parameteränderungen
 Auswahl zu verarbeitender Files, Anonymisierung dieser Files

 Testnachbereitungen
 Testprotokolle sichten
 Arbeit vorbereiten und verteilen

 Die Testverantwortlichen übernehmen nicht die
Gesamtverantwortung!


Seite 15

4

Deployment



Seite 16

TDD

Testauswertung

Testvorbereitung

Frontendtests

Deployment

Verarbeitung 1..N



Seite 17

Anforderungen an automatisierte Deployments
Obligatorisch
 Deploymentergebnis muss richtig sein
 Vollständigkeit, Korrektheit, Nachvollziehbarkeit

 vollständig automatisiert
keinerlei manuelle Eingriffe = innerhalb eines Testplans
 Fehlerausschließende Bestückung des Deployments
 Letztes erfolgreich getestetes Paket muss auslieferbar sein

Optional
 Deltadeployment
 Ausschluss von Objekten



Seite 18

Automatisches Deployment – DB-Inhalte
 Neuentwicklungen und Modifikationen müssen auf dem
Testsystem verfügbar sein





Tabellen
Views, Packages
Parametern zur Steuerung der ETL-Prozesse setzen
Berechtigungen

 OC Schemaverwaltung + Oracle-Bordmittel
 Basierend auf Ant und PL/SQL
 Stellt Sollzustand aus Istzustand des Zielsystems her
 Kann Datenmigrationen durchführen



Seite 19

Automatisiertes Deployment –
DDL, DCL, Datenmigrationen
Entwicklung

Objektskripte
Schemaverwaltungssteuertabellen

Abnahme

Produktion

DB-Schema
(DWH_SA…)
Schemaverwaltung

Test
DB-Schema
(DWH_SA…)

DB-Schema
(DWH_SA…)

DB-Schema
(DWH_SA…)

Schemaverwaltungspackage




deltarelevante
Objektskripte
Mindestens
täglich

Schemaverwaltung
(AntScripte, Subv
ersion)

Mindestens pro Mindestens pro
Release
Release


Seite 20

Automatisiertes Deployment – Informatica
Entwicklung
Informatica
Client

Informatica
Repository

Test

Abnahme

Produktion

Informatica
Repository

Informatica
Repository

Informatica
Repository

pmprep
ObjectImport

pmprep
ObjectImport

pmprep
ObjectImport

Objektliste
pmrep ExecuteQuery

pmrep
ObjectExport

Subversion

Mindestens
täglich


Release
Release


Seite 21

Automatisiertes Deployment – OWB
 Workflowexport mit maximaler Abhängigkeitstiefe
 nicht ausführbarer „Deploymentworkflow“

OMBEXPORT MDL_FILE … FROM PROJECT 'DEPLOYMENT' COMPONENTS
(PROCESS_FLOW_MODULE 'DEPLOYMENT') DEPENDEE_DEPTH MAX …



Seite 22

Automatisiertes Deployment – ODI
 Marker Group



Seite 23

Automatisiertes Deployment – ODI (II)
 Szenarien regenerieren mit OdiGenerateAllScen
 Generierung Export- und Importscript aus ODI-Repository
 Export
startcmd OdiExportScen
"-SCEN_NAME=PCK_MASTERDATA"
"-SCEN_VERSION=-1"
"-FILE_NAME=SCEN_PCK_MASTERDATA.xml"
"-FORCE_OVERWRITE=YES" "-RECURSIVE_EXPORT=YES" ...

 Import
startcmd OdiImportScen
"-FILE_NAME=SCEN_PCK_MASTERDATA.xml"
"-IMPORT_MODE=SYNONYM_INSERT_UPDATE"



Seite 24

Automatisiertes Deployment – Business Objects
Entwicklung

Business
Objects
Client

Business
Objects
Repository

Test

Abnahme

Produktion

Business
Objects
Repository

Business
Objects
Repository

Business
Objects
Repository

lcm.jar
action=import

lcm.jar
action=import

lcm.jar
action=import

Objektliste
per
Objektbeschreibung

.properties

lcm.jar
action=export

Mindestens
täglich

sFTP-Server


Release
Release


Seite 25

5

Automatisierte Backendtests



Seite 26

TDD

Testauswertung

Testvorbereitung

Frontendtests

Deployment

Verarbeitung 1..N



Seite 27

Werkzeuge und Stilmittel – Test-Suite
Entwicklung

Test
ETL-Repository

ETL-Entwickler-Clients
Testserver

ETL-Verarbeitung

Deployment (DDL,ETL)

ETL-Repository

Testplan
Testfall 1

Testfall N

DWH-DB
Testfallverarbeitung

DWH-DB

SVN

DB-Entwickler-Clients
Testfallentwicklung (TDD)

Protokollversand

Protokollierung
Baselinedumps
DWH-DB-Host

Seite 28

Werkzeugpalette einfach halten
Betriebsystemunabhängig
Oracle-Bordmittel: Data Pump, SQL*Plus für SQL-Scripte, SQL-Loader, Polling auf
Statusänderungen (Warten)
Dedizierter Testserver
Linux

Windows

Shellscripte

Batchfiles

ssh / scp zur Kommunikation

WinSCP-Scripts oder ssh / scp mit SSH-Server

Cron

Windows-Aufgabenplanung

Maßgeblich ist, was dem Team hilft und was von
jedem Teammitglied nutzbar ist


Seite 29

Werkzeuge und Stilmittel – Baselinedumps
Baselinedumps
exportieren
Nach Produktivsetzung eines
neuen Softwareoder Datenstandes

Iterative Entwicklung
TDD

Baselinedumps
importieren

Nächtliche
Testläufe

Ziele:
Produktivstellungssimulation
Fallback


Seite 30

6




Seite 31

TDD

Testauswertung

Testvorbereitung

Frontendtests

Deployment

Verarbeitung 1..N



Seite 32

 Backend-Testverarbeitung erzeugt Datei-Semaphor als BOSystemereignis
 Nach Beendigung der Backend-Tests
 Möglichkeit für mehrere, zeitlich versetzte Datei-Semaphore

Testlauf
Gruppe 1

BODeployment

1:00-2:00

Testlauf
Gruppe 3

8:00-8:20
FS

06:30

08:00

Backend-Test
Vertragsmanagement

8:40-9:00
FS

FS

8:20-8:40

9:00

Testlauf
Gruppe 2

Auslesen BO-Audit
Erstellung
Testprotokoll


Seite 33

7

Testauswertung



Seite 34

TDD

Testauswertung

Testvorbereitung

Frontendtests

Deployment

Verarbeitung 1..N



Seite 35

Testauswertung
 Alle Testprotokolle sollen 08:30 Uhr vorliegen
 Beide Testverantwortliche





Prüfen Verarbeitungen
Sondieren die Testprotokolle und bringen die Ergebnisse ins Daily ein
Starten ggf. Testpläne oder Testfälle neu
Übernehmen nicht die Gesamtverantwortung!



Seite 36

Werkzeuge und Stilmittel – Testergebnisse
 Testprotokolltabelle zum Persistieren von Ergebnissen
 S für Success: Testfall konnte keinen Fehler feststellen
 E für Error: Testfall hat Abweichungen festgestellt
 R für Registered: Testfall wurde nicht ausgeführt oder lief
syntaktisch falsch
01010_DDL
01020_DDL
01030_DDL
01060_DDL

S
E
S
S

11.03.2013 07:47:46
11.03.2013 07:47:55
11.03.2013 07:48:02
11.03.2013 07:48:09


0 fehlende Kommentare
1 fehlende Kommentare
0 Fehler gefunden
0 nicht aktuelle Matviews


Seite 37

Der tägliche Testzyklus - Zusammenfassung
TDD

Testauswertung

Testvorbereitung

Frontendtests

Deployment

Verarbeitung 1..N



Seite 38

Kontakt
Andreas Ballenthin
Kirchstr. 6 | 51647 Gummersbach
Tel. +49 (2261) 60 01-0
andreas.ballenthin@opitz-consulting.com

Thomas Flecken
Kirchstr. 6 | 51647 Gummersbach
Tel. +49 (2261) 60 01-0
thomas.flecken@opitz-consulting.com

youtube.com/opitzconsulting
@OC_WIRE
slideshare.net/opitzconsulting
xing.com/net/opitzconsulting



Seite 39

Automatisiertes Deployment – ODI
SELECT scen_name AS pack_name
FROM
(SELECT LAST_VALUE(d.scen_name)
OVER (PARTITION BY c.pack_name
ORDER BY scen_version) AS scen_name,
MAX(scen_version)
OVER (PARTITION BY c.pack_name) max_scen_version,
scen_version,
c.pack_name
FROM snp_obj_state a
JOIN snp_state2 b on (a.i_state = b.i_state)
JOIN snp_package c ON (a.i_instance = c.i_package)
JOIN snp_scen d ON (c.i_package = d.i_package)
WHERE state_code = 'PRODUCT_RELEVANT')
WHERE scen_version = max_scen_version;



Seite 40

Agile BI in der Praxis - Agiles Testen

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (9)

Similaire à Agile BI in der Praxis - Agiles Testen

Similaire à Agile BI in der Praxis - Agiles Testen (20)

Plus de OPITZ CONSULTING Deutschland

Plus de OPITZ CONSULTING Deutschland (20)

Agile BI in der Praxis - Agiles Testen