Post on 22-Jan-2018
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
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!