Fail Fast Fail Cheap

Fail Forward

Agile Development, Testing & Delivery Léon Tebbens - Lead IT - Alliander - @leontebbens - http://leontebbens.eu

Als developer wil ik zo snel mogelijk

falen

Zodat ik elke twee weken werkende software live kan brengen

in 10 minuten

Continuous Delivery

Business/klant: - Wil kortere time-to-market - Volgen van de standaard in de markt - Meer klantwaarde (lagere kosten)

Bovendien: - Beste mensen (inhuur en intern) krijg je als je innoveert

Waarom Continuous Delivery

Voorheen Nu

Development: 8 dagen 10 dagen

Integreren: 1 week Continu automatisch

Testen & rework: 2 weken 2 dagen

Time-to-market: 5 weken 2 weken

Vermeden kosten: 150 K p.j.

Klantwaarde

Continuous Delivery in 2 minuten

https://www.youtube.com/watch?v=SIaVsG7m8n4

Pipeline / lopende band:

- Multi skilled teams - Alles geautomatiseerd - Korte fix-tijden - Altijd klaar voor live-gang

Continuous Delivery

Pipeline / lopende band:

- Multi skilled teams - Alles geautomatiseerd (ook testen)

- Korte fix-tijden - Altijd klaar voor live-gang

Continuous Delivery

Pipeline / lopende band:

- Multi skilled teams - Alles geautomatiseerd - Korte fix-tijden - Altijd klaar voor live-gang

Continuous Delivery

Pipeline / lopende band:

- Multi skilled teams - Alles geautomatiseerd - Korte fix-tijden - Altijd klaar voor live-gang

Continuous Delivery

Continuous Delivery @ Alliander

Continuous Delivery @ Alliander

Continuous Delivery

2. Integrate & deploy

3. Test

Make sprint-ready

Release1. Coding &

feedback

2. Integrate & deploy

3. Test

Make Sprint-ready

Release1. Coding &

feedback

= Continue stroom user stories die live kunnen!

Continuous Delivery

2. Integrate & deploy

3. Test

4. Release1. Coding &

feedback

Make sprint-ready

Make Sprint-ready

Agile Development, Testing & Delivery - Léon Tebbens - Alliander

Continuous Delivery

2. Integrate & deploy

3. Test

4. Release

Make sprint-ready

Make Sprint-ready

Daarover later meer…

1. Coding & feedback

Eerst: continuous delivery cyclus

Continuous Delivery

2. Integrate & deploy

3. Test

Make Sprint-ready

4. Release1. Coding &

feedback

1. Coding & feedback Developer & tester werken samen

Wat is het duurste aan development?

Wat is het duurste aan development?En ook het meest onvoorspelbaar?

Fixen!

Daarom: 1. Test Driven Development

TDD minimaliseert repareren

Omdat je eerst je test schrijft. En daarna precies die productiecode die de test laat slagen. Niet pas “later testen”

-> Fail Fast en Fail Cheap

Daarom: 2. Laptop sneak preview

Tester bekijkt de gebouwde User Story op laptop van de developer

Niet oke? Direct aan te passen.

Pas hierna wordt de code geupload naar versiebeheer.

-> Fail Fast en Fail Cheap

2. Integrate & DeployNa elke code upload

Continuous Delivery

2. Integrate & deploy

3. Test

4. Release

Make Sprint-ready

1. Coding & feedback

Jenkins is onze “lopende band”

De lopende band gaat draaien na elke code-upload in Git versiebeheer

Code compileren & integreren

Code analyse en unittests (kwaliteit)

Package & store

Deploy op server

ROOD in een stap betekent een fout - je krijgt direct een email (fail fast) - je kan direct fixen (fail forward)

Net als in het filmpje van de lopende band

Jenkins pipeline demo

3. Test

Continuous Delivery

2. Integrate & deploy

3. Test

4. Release

Make Sprint-ready

1. Coding & feedback

Browser testing

Selenium GridTwist

Cucumber

Website

Browser testing Demo

Wie schrijft dan die testen?

Daarover later meer…nu eerst verder met de continuous delivery cyclus

Continuous Delivery

1. Code

2. Integrate & deploy

3. Test

Discover & design

4. Release

4. Release

Via druk op de knop

- Uit artifactory store - De oké-geteste versie - 100% geautomatiseerd - zorgeloos live gaan

Releasen naar Acc en Prod

server

De Analist & Tester & Continuous Delivery

Fail Fast Fail Cheap

Fail Forward

Hoe kunnen Analisten & testers het team helpen sneller te falen?

Terug naar het begin

Continuous Delivery

2. Integrate & deploy

3. Test

4. Release

Make sprint-ready

Make Sprint-ready

1. Coding & feedback

Hoe maken we de User Stories klaar voor de sprint? Wat is de rol van de analist en tester?

?

User Stories worden ready gemaakt door op te schrijven:

- How to demo

- How to test

“Begin with the end in mind” Stephen R Covey

How to demo is beschrijving in business scenario’s

How to Demo

Functionaliteit: Login

Als MijnLiander gebruiker, Wil ik kunnen inloggen in de beveiligde omgeving op liander.nl zo dat de voor mij specifieke gegevens zichtbaar worden

Analist & Product Owner legt de user story uit aan het developerteam

Het team stelt vragen en schrijft de story op als business scenario’s in de How to Demo

Resultaat: het team snapt de story vóórdat de sprint begint -> Fail fast, Fail Cheap

How to Demo

Testscenario’s in Gherkin stijl:

Given… When… Then…

mét voorbeelden (specification by example)

How to Test

Agile Development, Testing & Delivery - Léon Tebbens - Lead IT

How to TestFunctionaliteit: Login

Als MijnLiander gebruiker, Wil ik kunnen inloggen in de beveiligde omgeving op liander.nl zo dat de voor mij specifieke gegevens zichtbaar worden

How to Test

Scenario: Login to MijnLiander

Gegeven Ik heb de Liander site geopend

Als Ik inlog als gebruiker "ml.39@test.nl" met wachtwoord “*******”

Dan Zie ik dat ik ben ingelogd

Functionaliteit: Login

Als MijnLiander gebruiker, Wil ik kunnen inloggen in de beveiligde omgeving op liander.nl zo dat de voor mij specifieke gegevens zichtbaar worden

How to Test

Scenario: Login to MijnLiander

Gegeven Ik heb de Liander site geopend

Als Ik inlog als gebruiker "ml.39@test.nl" met wachtwoord “*******”

Dan Zie ik dat ik ben ingelogd

Functionaliteit: Login

Als MijnLiander gebruiker, Wil ik kunnen inloggen in de beveiligde omgeving op liander.nl zo dat de voor mij specifieke gegevens zichtbaar worden

Scenario: Login zonder gebruikersnaam en wachtwoord

Gegeven Ik heb de Liander site geopend

Als Ik inlog zonder gebruikersnaam en wachtwoord

Dan Zie ik de loginpagina met een foutmelding

Tester met developer & Analist/PO (“Three amigo’s”)

Story uitwerken in testscenario’s in Gherkin (given-when-then)

= Acceptatie-criteria van de story = Acceptance Test Driven Design

Resultaat: Geen onduidelijkheden bij bouw -> Fail fast, fail cheap

How to Test

David Farley: The people that can break the test, should write the test… developers!

Agile tester: bedenkt test-scenario’s (Gherkin) Agile developer: bouwt de test-code (Cucumber)

Developer bouwt de test in stap 1 “Coding”

Afsluiter: Wie schrijft dan die testen?

Samengevat

Fail Fast Deliver Fast Automatiseer zoveel mogelijk Automatisch testen Team-effort / alle disciplines / Samen! Stroom van user stories Altijd met druk op knop live kunnen User Story, How to Demo en How to Test zijn specs

Vragen?

@leontebbens - leontebbens.eu

Fail Fast Fail Cheap

Fail Forward

Vorige kennissessie: “use cases nodig als documentatie voor later”

Vraag: zouden de How to Demo en How to test de actuele functionele documentatie kunnen zijn?

Simpel voorbeeld van beiden in Serenity BDD for Cucumber: Functionaliteit: Login Als MijnLiander gebruiker, Wil ik kunnen inloggen in de beveiligde omgeving op liander.nl zo dat de voor mij specifieke gegevens zichtbaar worden Scenario: Login to MijnLiander Gegeven Ik heb de Liander site geopend Als Ik inlog als gebruiker "ml.39@test.nl" met wachtwoord “*********” Dan Zie ik dat ik ben ingelogd Scenario: Login zonder gebruikersnaam en wachtwoord Gegeven Ik heb de Liander site geopend Als Ik inlog zonder gebruikersnaam en wachtwoord Dan Zie ik de loginpagina

Vraag aan jullie!