Testen in der Delivery Pipeline

CONTINUOUS TESTING

Continuous Testing – Testen in der Delivery Pipeline

HERZLICH WILLKOMMEN ZUM WEBINAR

Die Moderatoren

2

Jörg-Matthias Müller Client Relationship Manager

Rüdiger Lühr Senior Consultant

Fragen über Chat

Digital Strategy & Transformation

Customer Experience & Commerce

Digital Workplace & Collaboration

Digital Delivery Management & Services

Smart Life

1.600 Mitarbeiter weltweit

>300 Mitarbeiter in Deutschland

6 Standorte in Deutschland

34,7 Mio. Euro

NetSales in Deutschland

5 Länder mit

Acando-Standorten

Nasdaq Acando AB ist an der Stockholmer

Börse

240 Mio. Euro

Umsatz pro Jahr weltweit

A MORE CAPABLE WORLD “ Hamburg

Braunschweig

Düsseldorf

Frankfurt

Stuttgart

München

100% KUNDENNÄHE

INNOVATION IN DER DIGITALEN WELT

ERLEBEN

3

Continuous Testing

Organisation und Methodik

Technologie

Leistungsangebot

AGENDA

Fragen & Antworten

4

CONTINUOUS TESTING

5

DIGITALE TRANSFORMATION: WAS HEIßT DAS FÜR DIE IT?

6

Digitale Transformation • Innovative am Kunden ausgerichtete Geschäftsmodelle • Intelligente Software als Alleinstellungsmerkmal gegenüber Mitbewerbern • Minimierung Time-to-market: Geschwindigkeit von der Idee bis zum Go-Live • Aufbrechen der Daten- und Wissenssilos • Geschwindigkeit ohne Qualitätseinbußen

Komplexe verteilte IT-Landschaften • Mobile Endgeräte • Native Apps und Responsive Design • Cloud Integration • Systemübergreifende Tests

Agile Entwicklungsmethodiken • Häufige Releases = Kurze Entwicklungszyklen

• Weniger Spezifikation: Fokussierung auf das Softwareprodukt • Organisatorische Barrieren aufbrechen

Handlungsfelder in der IT

CONTINUOUS TESTING

7

“Testing is a cross-functional activity that involves the whole team, and should be done continuously from the beginning of the project. Building quality in means writing automated tests at multiple levels (unit, component, and acceptance) and running them as part of the deployment pipeline...”

Jez Humble, David Farley: Continuous Delivery (2010)

DEPLOYMENT PIPELINE

• Continuous Delivery: Automatisierter Prozess von der Entwicklung bis zum Deployment in Produktion

• Automatisiertes Testen in den Test Stages - frühes Feedback über fehlgeschlagene Tests

8

Source Code Repository

Artefakt Repository

Commit Stage

Build

Unit Test

Component Integration Test Stage

Acceptance Test Stage

Pre-Production

Stage

Produktion

Entwickler Tester

Automatisiertes Deployment

Artefakt Upload

Test Feedback

CONTINUOUS TESTING ALS TEIL VON CONTINUOUS DELIVERY

• Das Continuous Delivery Maturity Model formuliert Themenfelder und Reifegradstufen

• Strukturiert und priorisiert die nächsten Schritte zum Continuous Delivery

9

Continuous Delivery

Buildmanagement und Continuous Integration

Umgebungen und Deployment

Daten Management

Test- und Qualitätssicherung

Release Management und Compliance

Maturity Modell nach Jez Humble & David Farley

-1

3

2

1

Ständige Optimierung

Messbar

Automatisiert

0 Wiederholbar

Ad-hoc

Reifegradstufen

ORGANISATION UND METHODIK

10

TEST IN AGILEN PROJEKTEN • Der fundamentale Testprozess nach ISTQB ist vom Ansatz her nicht agil. Er beschreibt jedoch grundsätzlich die

Schritte, die auch für den agilen Test benötigt werden.

• Scope ist die einzelne User Story bzw. eines Sprints

11

Planung

Analyse und Entwurf

Realisierung und Durchführung

Auswertung und Bericht

Abschluss

Test

steu

erun

g

Fundamentaler ISTQB Testprozess

• Aufgabe des gesamten Teams • Durchführung in der Sprint Planng

• User Story spezifiziert Anforderungen nur grob • Abnahmekrit. und Testfälle werden gemeinsam erarbeitet

• Testautomatisierung ist ein Muss auf jeder Ebene • Aufgabenteilung zwischen Entwickler und Tester

• Reduzierung auf das Wesentliche • Ziel ist die Fehlerfreiheit in der gesamten Pipeline

• Kein echter Abschluss, da mit neuem Sprint auch ein neuer Testzyklus startet

Unterschiede zum fund. Testprozess im agilen Test 11

DIE ROLLE DES TESTERS IM CONTINUOUS TESTING

• Das komplette Team ist für die Qualität verantwortlich und testet

• Der agile Tester ist fokussiert auf das Produkt aus Benutzersicht

12

Entwickler

• Entwicklung • Testautomatisierung auf Unit-

und Komponentenebene

Agiler Tester

Product Owner/Fachbereich

• Formuliert Akzeptanzkriterien • Manuelle Akzeptanztests • Explorative Tests

• Formuliert Testfälle • Aufbau von Testdaten • Methodikcoach • Testautomatisierung

Testautomatisierer

• Entwicklung von autom. Akzeptanztests

• Unterstützt Entwickler • Testtoolexperte

Testaktivitäten der verschiedenen Projektrollen

Auslieferungs-fähiges Produkt

12

DIE ROLLE EINES ZENTRALEN TESTTEAMS

• Tester transportieren Testmethodik, Automatisierungs-Know-How und den Qualitäts-Mindset in die Projektteams

13

Projektteam 2

Projektteam 1

Tester entsenden

Erfahrungen sammeln

Erfahrungen sammeln

Zentrales Testteam

Agile Tester

Technische Testautomatisierer Testspezialisten: Last,

Performance, Sicherheit

Testmanager

TESTEN EINER USER STORY (1) – AKZEPTANZKRITERIEN UND TESTFÄLLE • Akzeptanzkriterien detaillieren die Anforderung und sind Basis für die Testfallerstellung

14

User Story: Validierung Kundenadressdaten Bei der Pflege der Kundenadressdaten in der WebApp benötige ich als Vertriebsleiter eine Validierung der eingegebenen Adressdaten, um sicherzustellen, dass Pakete und Schreiben den Kunden erreichen. Akzeptanzkriterien: 1. Bei der Eingabe der Ortsanfangsbuchstaben wird eine Auswahlliste angezeigt. 2. Bei der Eingabe der Strassenanfangsbuchstaben wird eine Auswahlliste angezeigt. 3. Die PLZ wird bei einer korrekten Adresse automatisch ermittelt. 4. Ist die Adresse valide, wird dies visualisiert (Grüner Haken).

Wireframe

Testfälle: 1. Wenn der Ort Ham eingegeben wird, dann enthält die Liste Hamburg, Hamm, Hameln. 2. Wenn eine Straße ohne vorherigen Ort eingegeben wird, dann ist die Straßenliste leer. 3. Wenn als Ort Hamburg und Millerntorplatz als Straße eingegeben wird, dann wird die PLZ 20359 ermittelt und alle 3 Felder sind abgehakt.

TESTEN EINER USER STORY (2) – TESTQUADRANTEN

• Test Quadranten zeigen die Automatisierbarkeit der verschiedenen Testarten

• 2. und 3. Quadrant: Fachliche Tests sind häufig die großen Testaufwandstreiber

15

Crispin/Gregory: Agile Test Quadrants technisch

fachlich

team

unte

rstü

tzen

d

prod

ukth

inte

rfra

gend

Exploratives Testen Szenarien Akzeptanztest Benutzbarkeitstest

Funktionstests Beispiele Story-Tests Prototypen

Unittest Komponententest

Last & Performancetests Sicherheitstests Zuverlässigkeitstests

Automatisiert

Manuell

Q1

Q2

Q4

Q3

TECHNOLOGIE

16

TESTAUTOMATISIERUNG

Test Pyramide: Auf die richtige Mischung kommt es an!

Typische Ausgangssituation

• Unit Tests sind in den Entwicklungsprozessen etabliert

• Automatische und manuelle UI-Tests werden häufig mit großem Aufwand betrieben

• Ergebnis ist eine große Lücke in der Testabdeckung

Akzeptanztests werden häufig auf UI-Ebene automatisiert, weil es

• der benutzerzentrierten Sicht entspricht

• scheinbar einfache Werkzeuge zur Automatisierung gibt

• kein Entwickler-Know-How benötigt

• schon immer so gemacht wurde

17

Manuelle Tests

Anzahl Testfälle

Wartungsaufwand Ausführungsdauer Abhängigkeiten

Herausforderungen • Schwierige Ansteuerung der UI-Elemente

• Schwer verständliche Testskripte

Unsere Empfehlungen

• Manuelles exploratives Testen auf UI-Ebene

• Automatisierung der Akzeptanztests auf Serviceebene

• Hoher Wartungsaufwand wegen häufiger Änderungen

• Langsam in der Ausführung

AKZEPTANZTESTS AUF USER INTERFACE EBENE

18

Aufgezeichneter Selenium Testcase für hvv.de

Beispiel hvv.de

Lösungsansatz UI-Services

• Moderne WebApps bieten UI-Funktionen als http-Services an

• UI-Services sind gute Aufsetzpunkte für den Akzeptanztest

AKZEPTANZTESTS AUF SERVICE EBENE

19

http://<server>/PlzSuche? autocomplete=street& plz_city=Hamburg& &plz_street=Mill

{ "rows": [ { "street": "Millerntordamm" }, { "street": "Millerntorplatz" }, { "street": "Millöckerweg" } ] }

Request Response

Beispiel UI-Service AutocompleteAdresse

System

GetBankverbindungen GetAdressen

HTTP UI-Services Schicht

AutoCompleteAdresse SetAdresse

Testtool z.B. SOAPUI

Testcase Autocomplete

Rufe Autocomplete

Validiere Straße

Testdaten

JSON over http

Testen von UI-Services

SERVICE EBENE: BEHANDLUNG VON ABHÄNGIGKEITEN

Herausforderungen

• Testsystem ist eine Black Box: Code Abhängigkeiten nur schwer für den Test steuerbar

• Spezifische Datenkonstellationen sind über die fachlichen Schnittstellen nicht steuerbar

• Integration mit Fremdsystemen: Verfügbarkeit, Konsistenz der Daten…

Lösungsansatz Mocking

• Ein Mock Objekt ist ein Platzhalter, welches die Stelle eines Fremdsystems oder einer anderen abhängigen Funktionalität einnimmt

• Mock Objekt ist durch den Test Code bzw. Testdaten steuerbar

• Mocking ist einfacher auf Codeebene als auf Systemebene

Unsere Empfehlungen

• Ersetzen von Abhängigkeiten durch Mock Objekte

• Tests auf Codeebene implementieren und nicht auf Systemebene 20

Test Code

Code Under Test

Code Abhängigkeiten

Mock Objekt SAP

Daten

Mock Objekt DB

Einsatz von Mock Objekten

AKZEPTANZTESTS: DER ÜBERGANG VOM TESTFALL ZUM TESTSKRIPT

Herausforderungen

• Übergang vom fachlichen Testfall in das technische Testskript ist wenig transparent

• Schwieriges Prüfen der Akzeptanzkriterien

Lösungsansatz Behaviour driven development (BDD)

• Tester beschreibt Testfälle in Given/When/Then-Notation

• Mittels Frameworks wie Cucumber oder Jbehave direkt auf Implementierung abbildbar

• Testautomatisierer implementiert den automatisierten Test

Unsere Empfehlungen

• BDD schafft Transparenz in Testfälle und Testskripte

• BDD ermöglicht sehr flexible Teststeuerung durch den agilen Tester

21

Given1: Kunde befindet sich in der WebApp auf dem Formular Kundenadresse

When1:Kunde gibt den Wert <anfangOrt> ein.

Then1: Liste enthält die Werte <ort> |anfangOrt|Ort |ham|Hamburg, Hamm, Hameln |mü|München, Münster |y|Yach

Testklasse

Given1-Methode

When1-Methode

Then1-Methode

Testfall in Given/When/Then-Notation

QUALITÄTSSICHERUNG: READY FOR RELEASE?

Herausforderungen

• Das große Ziel: Releasefähigkeit zu jeder Zeit

• Garantierte Fehlerfreiheit ist nicht möglich

• Nicht genug Zeit, um alle Testfälle durchzuführen

Lösungsansätze

• Risikobasiertes Testen: Fokussierung auf die kritischen Tests

− Bewertung der User Stories hinsichtlich Schaden und Wahrscheinlichkeit

• Metriken zur Messung von Produkt- , Prozess- und Codequalität

Unsere Empfehlungen

• Im Team Kriterien für Ready for Release erarbeiten

• Zu Beginn über Reviews Qualität sichern, danach Metriken unterstützend einsetzen

22

Produkt

Prozess Code

• Akzeptanzkriterien erfüllt • Kompletter Regressionstest

erfolgreich • 0 oder nur akzeptierte Fehler

• Ziel-Testabdeckung erreicht • Technische Schulden nicht

vorhanden oder akzeptiert

• Durch Product Owner abgenommen

• Entwickler Peer-Review durchgeführt

• Erfolgeiches Deployment in allen Stages

Ready for Release?

Beispielhafte Kriterien für die Ready for Release-Entscheidung

WIE WIR SIE UNTERSTÜTZEN KÖNNEN

23

ACANDO LEISTUNGSANGEBOT – SCHRITTE ZUM CONTINUOUS TESTING

24

Analyse und Bewertung der Testmethodik auf methodischer und technischer Ebene

Erarbeitung der Continuous Testing Strategie

Assessment

Konzeption

Umsetzung

Agile Tester, zertifizierte Testmanager und spezialisierte Testautomatisierer

Training & Coaching

Training von Entwicklungs- und Testmethodiken Projektbegleitendes Coaching

ZUSAMMENFASSUNG

Continuous Testing ist der Test in der Continuous Delivery Pipeline!

• Agiles Testen

• Umfassende Testautomatisierung auf allen Ebenen der Service Pyramide

• Integration in die Continuous Delivery Pipeline

• Metriken zur Messung von Produkt-, Prozess- und Codequalität

Unsere Empfehlungen

• Ausgehend vom Continuous Delivery Maturity Model die nächste Schritte identifizieren

• Tester transportieren Testmethodik, Automatisierungs-Know-How und den Qualitäts-Mindset in die Projektteams

• Automatische Akzeptanztests auf Serviceebene implementieren (nicht auf UI Ebene)

• Ready for Release: Test ist sehr wichtig, aber immer im Zusammenspiel mit dem Entwicklungsprozess und der Codequalität zu betrachten.

25

VIELEN DANK FÜR IHRE AUFMERKSAMKEIT!

26

Jörg - Matthias Müller Client Relationship Manager Business Area Nord Phone: +49 40 822259-327 Mobile: +49 172 5395921 joerg-matthias.mueller@acando.de

Rüdiger Lühr Senior Consultant Business Area Nord Phone: +49 40 822259-0 ruediger luehr@acando.de

Folgen Sie uns