CONTINUOUS TESTING. Testen in der Delivery Pipeline

CONTINUOUS TESTING Testen in der Delivery Pipeline HERZLICH WILLKOMMEN ZUM WEBINAR Continuous Testing – Testen in der Delivery Pipeline Die Moderat...
6 downloads 0 Views 790KB Size
CONTINUOUS TESTING Testen in der Delivery Pipeline

HERZLICH WILLKOMMEN ZUM WEBINAR Continuous Testing – Testen in der Delivery Pipeline

Die Moderatoren

Fragen über Chat

Rüdiger Lühr

Senior Consultant

Jörg-Matthias Müller

Client Relationship Manager

2



A MORE CAPABLE WORLD Digital Strategy & Transformation

Hamburg Braunschweig

Customer Experience & Commerce

100%

Düsseldorf

Digital Workplace & Collaboration

KUNDENNÄHE Frankfurt

INNOVATION IN DER DIGITALEN WELT ERLEBEN

Digital Delivery Management & Services Stuttgart München

Smart Life

1.600

240

5

Nasdaq

>300

34,7

6

Mitarbeiter weltweit

Mio. Euro Umsatz pro Jahr weltweit

Länder mit AcandoStandorten

Acando AB ist an der Stockholmer Börse

Mitarbeiter in Deutschland

Mio. Euro NetSales in Deutschland

Standorte in Deutschland 3

AGENDA

Continuous Testing Organisation und Methodik

Technologie

Leistungsangebot Fragen & Antworten

4

CONTINUOUS TESTING

5

DIGITALE TRANSFORMATION: WAS HEIßT DAS FÜR DIE IT? 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

Handlungsfelder in der IT

Agile Entwicklungsmethodiken

Komplexe verteilte IT-Landschaften • • • •

Mobile Endgeräte Native Apps und Responsive Design Cloud Integration Systemübergreifende Tests

• • •

Häufige Releases = Kurze Entwicklungszyklen Weniger Spezifikation: Fokussierung auf das Softwareprodukt Organisatorische Barrieren aufbrechen

6

CONTINUOUS TESTING

“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)

7

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

Artefakt Upload

Source Code Repository

Artefakt Repository

Automatisiertes Deployment

Commit Stage Entwickler Tester

Build Unit Test

Component Integration Test Stage

Test Feedback

Acceptance Test Stage

PreProduction Stage

Produktion

8

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

Buildmanagement und Continuous Integration

Test- und Qualitätssicherung

Umgebungen und Deployment

Continuous Delivery Daten Management

Maturity Modell nach Jez Humble & David Farley

Release Management und Compliance

3

Ständige Optimierung

2

Messbar

1

Automatisiert

0

Wiederholbar

-1

Ad-hoc

Reifegradstufen

9

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

Teststeuerung



Planung

• •

Aufgabe des gesamten Teams Durchführung in der Sprint Planng

Analyse und Entwurf

• •

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

Realisierung und Durchführung

• •

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

Auswertung und Bericht

• •

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

Abschluss



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

Fundamentaler ISTQB Testprozess

Unterschiede zum fund. Testprozess im agilen Test

11 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

Product Owner/Fachbereich

Entwickler • •

Entwicklung Testautomatisierung auf Unitund Komponentenebene

Agiler Tester • • • •

Formuliert Testfälle Aufbau von Testdaten Methodikcoach Testautomatisierung

Testaktivitäten der verschiedenen Projektrollen

Formuliert Akzeptanzkriterien Manuelle Akzeptanztests Explorative Tests

• • •

Auslieferungsfähiges Produkt

Testautomatisierer • • •

Entwicklung von autom. Akzeptanztests Unterstützt Entwickler Testtoolexperte

12

DIE ROLLE EINES ZENTRALEN TESTTEAMS •

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

Erfahrungen sammeln Zentrales Testteam

Projektteam 1

Agile Tester Testspezialisten: Last, Performance, Sicherheit

Technische Testautomatisierer

Tester entsenden

Testmanager

Projektteam 2 Erfahrungen sammeln 13

TESTEN EINER USER STORY (1) – AKZEPTANZKRITERIEN UND TESTFÄLLE •

Akzeptanzkriterien detaillieren die Anforderung und sind Basis für die Testfallerstellung 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.

14

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

Funktionstests Beispiele Story-Tests Prototypen

Unittest Komponententest

Crispin/Gregory: Agile Test Quadrants

Q2

Q3

Q1

Q4

Exploratives Testen Szenarien Akzeptanztest Benutzbarkeitstest Last & Performancetests Sicherheitstests Zuverlässigkeitstests

produkthinterfragend

teamunterstützend

fachlich

technisch

Automatisiert Manuell

15

TECHNOLOGIE

16

TESTAUTOMATISIERUNG Test Pyramide: Auf die richtige Mischung kommt es an! Typische Ausgangssituation • Unit Tests sind in den Entwicklungsprozessen etabliert

Manuelle Tests Wartungsaufwand Ausführungsdauer Abhängigkeiten

• 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

Anzahl Testfälle

• kein Entwickler-Know-How benötigt • schon immer so gemacht wurde

17

AKZEPTANZTESTS AUF USER INTERFACE EBENE Herausforderungen • Schwierige Ansteuerung der UI-Elemente

• Hoher Wartungsaufwand wegen häufiger Änderungen

• Schwer verständliche Testskripte

• Langsam in der Ausführung

Beispiel hvv.de

Aufgezeichneter Selenium Testcase für hvv.de

Unsere Empfehlungen • Manuelles exploratives Testen auf UI-Ebene • Automatisierung der Akzeptanztests auf Serviceebene 18

AKZEPTANZTESTS AUF SERVICE EBENE Lösungsansatz UI-Services •

Moderne WebApps bieten UI-Funktionen als http-Services an Testtool z.B. SOAPUI Testcase Autocomplete Testdaten

Rufe Autocomplete Validiere Straße



UI-Services sind gute Aufsetzpunkte für den Akzeptanztest

http:///PlzSuche? autocomplete=street& plz_city=Hamburg& &plz_street=Mill Request

Response

JSON over http

{ System HTTP UI-Services Schicht SetAdresse

AutoCompleteAdresse

GetAdressen

GetBankverbindungen

Testen von UI-Services

}

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

Beispiel UI-Service AutocompleteAdresse 19

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

Test Code Daten Code Under Test

Code Abhängigkeiten Mock Objekt SAP Mock Objekt DB

• Mocking ist einfacher auf Codeebene als auf Systemebene

Unsere Empfehlungen • Ersetzen von Abhängigkeiten durch Mock Objekte

Einsatz von Mock Objekten

• Tests auf Codeebene implementieren und nicht auf Systemebene 20

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

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

Given1-Methode

When1:Kunde gibt den Wert ein.

• 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

Testklasse

When1-Methode Then1-Methode

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

Testfall in Given/When/Then-Notation

21

QUALITÄTSSICHERUNG: READY FOR RELEASE? Herausforderungen

Produkt

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

• Akzeptanzkriterien erfüllt • Kompletter Regressionstest erfolgreich • 0 oder nur akzeptierte Fehler

• 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

Code

Ready for Release?

• Ziel-Testabdeckung erreicht • Technische Schulden nicht vorhanden oder akzeptiert

Prozess

• Durch Product Owner abgenommen • Entwickler Peer-Review durchgeführt • Erfolgeiches Deployment in allen Stages

• Zu Beginn über Reviews Qualität sichern, danach Metriken unterstützend einsetzen Beispielhafte Kriterien für die Ready for Release-Entscheidung 22

WIE WIR SIE UNTERSTÜTZEN KÖNNEN 23

ACANDO LEISTUNGSANGEBOT – SCHRITTE ZUM CONTINUOUS TESTING

Assessment

Analyse und Bewertung der Testmethodik auf methodischer und technischer Ebene

Konzeption

Umsetzung

Erarbeitung der Continuous Testing Strategie

Agile Tester, zertifizierte Testmanager und spezialisierte Testautomatisierer

Training & Coaching

Training von Entwicklungs- und Testmethodiken Projektbegleitendes Coaching

24

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!

Rüdiger Lühr

Senior Consultant Business Area Nord Phone: +49 40 822259-0 ruediger [email protected]

Jörg - Matthias Müller

Client Relationship Manager Business Area Nord Phone: +49 40 822259-327 Mobile: +49 172 5395921 [email protected]

Folgen Sie uns

26