agile bi in der praxis - agiles testen

© OPITZ CONSULTING GmbH 2013 Seite 1Agile BI in der Praxis – Agiles Testen

Agiles Testen

Agile BI in der Praxis

Andreas Ballenthin, Solution Architect

Thomas Flecken, Senior Consultant

OPITZ CONSULTING Deutschland GmbH

DOAG Konferenz

Nürnberg, 19.11.2013


Agenda

1. Vorstellung OPITZ CONSULTING

2. Testgetriebene Entwicklung - TDD

3. Testvorbereitung

4. Deployment

5. Automatisierte Backendtests

6. Automatisierte Frontendtests

7. Testauswertung


1 Vorstellung OPITZ CONSULTING


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

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

LeistungsangebotBusiness IT AlignmentBusiness Information ManagementBusiness Process ManagementAnwendungsentwicklungSOA und System-Integration IT-Infrastruktur-Management

MärkteBranchenübergreifendÜber 600 Kunden

29%Industrie / Versorger /

Telekommunikation

29%Handel / Logistik / Dienstleistungen

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

EckdatenGründung 1990 400 Mitarbeiter9 Standorte


2 Test & Entwicklung


Automatisierte Tests sind Pflicht!

S1 S2 S3 S4 S5 S6 S7 S8 S9 S1005

101520253035404550

Alte Funktionalitäten (Regressionstests)Neue Funktionalitäten

Sprint

An

zah

l F

un

ktio

nal

ität

en

Aufwand für Regressionstests steigt stetigTestabdeckung darf nicht Zufall überlassen bleibenTestautomatisierung ist Pflicht!


Der tägliche Testzyklus

TDD

Testvorbereitung

Deployment

Verarbeitung 1..NTest Verarbeitung 1..N

Testauswertung

Frontendtests

TDD


Testgetriebene Entwicklung - TDD

Entwicklung / Erweiterung des Testfalls

Ausführung des Testfalls

Implementierung des Codes

schlägt fehl

erfolgreich

Fehler so früh wie möglich erkennenAuch: Fachliche Schärfung


Testfälle hängen am Taskboard!

Einen Testfall übernehmen wird sicht- und erlebbar!

Definition neuer und zu ändernder Testfälle im Planning II

• .


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


Werkzeuge und Stilmittel – Testfallkategorien

Datenabgleiche innerhalb einer Schicht

Datenabgleiche zwischen den Schichten

Datenabgleiche End-to-End

Einhaltung von Konventionen

Prüfungen auf das Data Dictionary

Inhalte von Fehlertabellen

Bereitstellen synthetischer Daten

Prüfung von Datenmigrationen

Kontextprüfberichte

Kennzahlentests

Performancetests

Anwenderberichte

Metadatentests


3 Testvorbereitung



TDD

Testvorbereitung

Deployment


Testauswertung

Frontendtests


Was testen wir heute?

Welche Verarbeitungen? Es können nicht alle Verarbeitungen täglich laufen

Wann?

In welchen Umfang?

19:00

20:00

Deployment

23:30

Call Data Records

Test Call Data Records

02:00

01:00

Netz-abgleich

Test Netz-

abgleich

Vertrags-management

Test Vertrags-

management

03:00

03:15 06:30 08:00


Wer testet denn heute?

F

K

J

J

A

T D

B

Es gibtund

Die Testverantwortlichen wer-den im Planning II bestimmt.

Testvorbereitungen 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!

Spezialistenrechte Hände


4 Deployment



TDD

Testvorbereitung

Deployment


Testauswertung

Frontendtests


Anforderungen an automatisierte Deployments

Deploymentergebnis muss richtig sein Vollständigkeit, Korrektheit, Nachvollziehbarkeit

vollständig automatisiertkeinerlei manuelle Eingriffe = innerhalb eines Testplans

Fehlerausschließende Bestückung des Deployments

Letztes erfolgreich getestetes Paket muss auslieferbar sein

Deltadeployment

Ausschluss von Objekten

Obligatorisch

Optional


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


Schema-verwaltung

Automatisiertes Deployment – DDL, DCL, Datenmigrationen

Entwicklung Test Abnahme Produktion

Schema-verwaltung

(Ant-Scripte, Subversion)

Schema-verwaltungs-

package

Schema-verwaltungs-

package

Schema-verwaltungs-

steuertabellen

DB-Schema(DWH_SA…)


Mindestens täglich

Mindestens pro Release


Schema-verwaltungs-

package

Schema-verwaltungs-

package



Objekt-skripte

deltarelevante Objektskripte


Automatisiertes Deployment – Informatica


pmrep ObjectExport

pmprepObjectImport

InformaticaClient

Informatica Repository


Mindestens täglich



pmprepObjectImport

pmprepObjectImport



Objektlistepmrep ExecuteQuery

Subversion


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 …


Automatisiertes Deployment – ODI

Marker Group


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"


Automatisiertes Deployment – Business Objects


lcm.jaraction=export

lcm.jaraction=import

Business ObjectsClient

Business Objects

Repository

Business Objects

Repository

Mindestens täglich





Business Objects

Repository

Business Objects

Repository

Objektlisteper

Objektbeschreibung

sFTP-Server

.properties


5 Automatisierte Backendtests



TDD

Testvorbereitung

Deployment


Testauswertung

Frontendtests


DWH-DB-Host

Werkzeuge und Stilmittel – Test-Suite

Entwicklung Test

DWH-DB

ETL-Repository

ETL-Entwickler-Clients

Testserver

DB-Entwickler-Clients

DWH-DB

Testfallentwicklung (TDD)

Deployment (DDL,ETL)

ETL-Repository

ETL-Verarbeitung

Testplan

Testfall 1

Testfall NTestfallverarbeitung

ProtokollierungProtokollversandSVN

Baselinedumps


Werkzeugpalette einfach halten

Shellscripte

ssh / scp zur Kommunikation

Cron

Linux

Batchfiles

WinSCP-Scripts oder ssh / scp mit SSH-Server

Windows-Aufgabenplanung

Windows

Betriebsystemunabhängig

Oracle-Bordmittel: Data Pump, SQL*Plus für SQL-Scripte, SQL-Loader, Polling auf

Statusänderungen (Warten)

Dedizierter Testserver

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


Werkzeuge und Stilmittel – Baselinedumps

Baselinedumps exportieren

Baselinedumps importieren

Nächtliche Testläufe

Iterative EntwicklungNach Produktiv-setzung eines

neuen Software-oder Datenstandes

TDD

Ziele:ProduktivstellungssimulationFallback


6 Automatisierte Frontendtests



TDD

Testvorbereitung

Deployment


Testauswertung

Frontendtests


Automatisierte Frontendtests

1:00-2:00

BO-Deployment

8:00-8:20

Testlauf Gruppe 1

Backend-Test

Vertrags-management

9:0006:30 08:00FS FS

8:20-8:40

TestlaufGruppe 2

FS8:40-9:00

TestlaufGruppe 3

Auslesen BO-AuditErstellung

Testprotokoll

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


7 Testauswertung



TDD

Testvorbereitung

Deployment


Testauswertung

Frontendtests


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!


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 S 11.03.2013 07:47:46 0 fehlende Kommentare01020_DDL E 11.03.2013 07:47:55 1 fehlende Kommentare01030_DDL S 11.03.2013 07:48:02 0 Fehler gefunden01060_DDL S 11.03.2013 07:48:09 0 nicht aktuelle Matviews


Der tägliche Testzyklus - Zusammenfassung

TDD

Testvorbereitung

Deployment


Testauswertung

Frontendtests


Kontakt

Andreas Ballenthin Bild durch Klicken auf Symbol hinzufügen

OPITZ CONSULTING Deutschland GmbHKirchstr. 6 | 51647 GummersbachTel. +49 (2261) 60 [email protected]

Thomas Flecken

OPITZ CONSULTING Deutschland GmbHKirchstr. 6 | 51647 GummersbachTel. +49 (2261) 60 [email protected]

Bild durch Klicken auf Symbol hinzufügen

youtube.com/opitzconsulting

@OC_WIRE

slideshare.net/opitzconsulting

xing.com/net/opitzconsulting


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;

agile bi in der praxis - agiles testen

Technology