Dutch presentation given on the TestNet Voorjaarsevent on the 30th of April. A story about how TestReporting is going to change to Realtime Monitoring to keep up with changes in IT landscapes, development processes and ways of working within IT teams and still give stakeholders and the team the information they need.
3. ● Testrapportages in het verleden
● Impact nieuwe ontwikkelingen
● Testrapportages nu
● Monitoring als toekomst?
● Toegevoegde waarde testers
● Vragen
Agenda
3
4. IK
4
Ide Koops
30 jaar, trotse vader
• Sinds 2008 werkzaam bij KZA
• Test Expert
• Complexe omgevingen en ketens
• Scrum, Agile, DevOps
• Test Automatisering & Continuous Delivery
• Finance, Overheid, Nuts en Zorg
5. Rapportages bij het V-model
5
Testrapport
Testrapport
Testrapport
Testrapport
Testrapport
Testrapport
Eindrapportage
Vrijgaveadvies?Voortgangsrapportage
Risicorapport
7. Rapportages in de knel
7
● In een traditioneel project
zit testen snel op het
kritische pad.
● En binnen de testfase, waar
vindt de rapportage dan
vooral plaats?
8. Als je testrapportage (feedback naar opdrachtgever) al vaak in
de knel zit in traditionele langdurige projecten,
Hoe gaat dat dan nu bij kort cyclische
ontwikkelmethodieken?
8
10. Impact Continuous Delivery
10
● Kwaliteit ontwikkelstraat
nog belangrijker
● Downtime testomgeving
heeft dus direct impact
● Feedback op
beschikbaarheid en
kwaliteit ontwikkelstraat
wenselijk
11. Impact DevOps
11
● Team verantwoordelijk voor
ontwikkelen en beheren.
● Ops down is hold the line
on Dev
● Grip op Ops met behulp van
monitoring essentieel
12. Bestaande manier van rapporteren
over testen ongeschikt want:
● Ontwikkelcyclussen korter:
Eerder en direct feedback
● Fasering verdwijnt
● Acceptanten binnen het team
12
13. Maar hoe communiceren we dan
nu over de voortgang en kwaliteit
van een team wat werkt met
Agile/Scrum of een DevOps
aanpak?
13
14. ● Afleiden van scrumboard:
o Grote bevindingen zijn impediments
o Testen nog bezig is taak nog niet done
● Dagelijkse rapportages
o Zijn we al klaar?
o Hoever zijn we?
o Waarom zijn we nog niet klaar?
Testrapportages nu
14
15. ● Focus op continuïteit
productie
● Veelal beperkt tot een
technisch niveau
● Soms performance
● En binnen de business soms
monitoring op klachten of
bijvoorbeeld social media
Monitoring nu?
15
16. Testen
● Geeft feedback over
kwaliteit bouw tov
requirements
● Op diverse niveau’s:
o Unit
o Functioneel
o Performance
o Keten
● Momentopname op een
testomgeving
Testen ≠ Monitoring?
Monitoring
● Geeft feedback over
werking systeem
● Meestal alleen
Productiesystemen
● Veelal alleen technisch en
gericht op foutsituaties en
performance
● Realtime
16
Overeenkomst!
17. Hoe gaan we in de toekomst, met kortcyclische
ontwikkelmethodieken continu feedback krijgen over:
● De kwaliteit van de software?
● En de benodigde omgevingen?
● En ons ontwikkelproces?
17
19. ● Technische stabiliteit
● Externe afhankelijkheden
o If service down,
then deploy stub
● Consistentie Testdata
Monitoren Kwaliteit Omgevingen
19
20. ● Monitoren succesvolle
deploys
● Monitoren testen en
bevindingen op
verschillende niveaus
● Monitoren Velocity
● Impediments
Let op: Draagvlak team!
Monitoren Kwaliteit Ontwikkelproces
20
Bron: Steve Denning
21. ● Waardevol hulpmiddel in je
ontwikkelproces
● Expertise opbouwen in hele
team
● Vraagt soms om
aanpassingen in
design/bouw
● Borgt afronding en creëert
draagvlak vanuit
stakeholders
● Keuze PO / Team
Monitoren in de DoD
21
23. ● De belangrijkste dingen
eerst doen (Risk Based)
● Voorspellen verwachte
resultaat
● Resultaten en informatie
vaak met bestaande
testtooling te triggeren
● Testen van de monitoring,
ook daar zitten risico’s en
aannames!
De testachtergrond bij inrichten van
monitoring
23
24. ● Meer automatisering!
o A fool with a tool…
● Testen als losse fase
verdwijnt
o Klopt, wordt onderdeel van
elke fase, onderdeel van je
Definition of Done.
Continu en realtime.
Is monitoring een risico voor testers?
24
Het vraagt wel om een aanpassing!
25. Conclusie
25
● Testrapportages verliezen hun toegevoegde waarde onder
invloed van diverse ontwikkelingen
● Realtime monitoring van productkwaliteit, omgeving en
proces is de toekomst.
● Afgestemd op degene die om informatie verlegen zit
● Ide Koops
● Twitter: @djidee
● KZA Stand
Hinweis der Redaktion
Leer van het verleden, kijk naar de toekomst en ga vooral nu aan de slag, doe en ervaar!
Aanstippen opbouw
Ruimte aan het eind voor vragen/discussie
Voor elke fase een testrapport als afsluiting. ‘Borging’ voor overdracht bij Waterval. Als het goed is, met een link naar bijbehorende requirements
Voor elk project een eindrapportage. Input werd vaak gehaald vanuit de verschillende testrapporten.
Op basis daarvan vaak een vrijgave advies
Wou je eerder feedback? Dan een voortgangsrapportage
En als we zaken niet zeker wisten, dan nog een additioneel Risicorapport.
1) Er was vaak 1 testrapportage, bedoeld voor alle stakeholders. Intern als naslagwerk (wat hebben we nou exact gedaan en met welke resultaten), voor het project vaak ook als soort van bewijslast (wat hebben we allemaal getest/welke risico’s hebben we afgedekt) en voor de business en management vaak een beeld van de algemene stand van zaken
2) Door de vele stakeholders, met elk hun informatiebehoefte zijn het vaak lijvige documenten. Templates die je vind op het web zijn vaak al 10+ pagina’s, en dan moet de inhoud nog komen. Verdeeld in hoofdstukken en vaak voorzien van een managementsamenvatting aan het begin waar de meest essentiële zaken in benoemd zijn
3) Maar het is altijd een moment opname, wat hebben wij gedaan op testomgeving x. Bij een volgende wijziging is hij per definitie verouderd.
In traditioneel waterval zit testen meestal op het kritische pad. Eerdere fases lopen uit, requirements wijzigen, we kunnen allemaal wel gebeurtenissen noemen waarom projecten vertragen. Testen komt altijd aan het eind, en zit ook vaak per definitie in de kreukelzone. Gaan we sneller testen (opschalen), gaan we zaken niet testen?
Maar binnen het testen hebben we ook vaak een fasering. En omdat de afronding aan het eind zit, en budget vaak al overschreden is worden er nogal eens concessies gedaan aan de inhoud en kwaliteit van de testrapportage. Immers, heeft men vaak al op basis van adhoc feedback besloten om door te gaan, om de deadlines niet nog verder te hoeven schuiven.
Maar bij lange waterval trajecten zit de rapportage al vaak in de knel, hoe gaat het dan als we in enkele weken dingen werkend moeten opleveren. Hoe ga ik elke 3 weken rapporteren?
Bij Agile/Scrum zit het uitvoeren van testen vaak wel geborgd.
De voorbereiding (wat gaan we testen, en hoe) komen ook vaak wel als taken terug op de scrumborden
Maar de afronding van testen, nee, meestal is dat niet belangrijk genoeg. We bewaren testcases zodat we die in een volgende sprint kunnen hergebruiken, en als de stakeholder het goed vind, gaan we klaar. Dan is een document verder overbodig.
Wanneer je als organisatie meer gaat doen met Continuous Delivery worden je ontwikkelstraten belangrijker. Immers, automatiseer je veel handelingen die je doet gedurende je ontwikkelproces, en automatiseren kun je alleen maar doen als je omgevingen betrouwbaar en voorspelbaar zijn.
Downtime van je testomgeving heeft direct impact, het voorkomt dat je software automatisch kan doorschuiven en testen, zodat je ontwikkelcyclus niet kan worden afgerond. Veelal is het niet kunnen deployen op een testomgeving en het niet succesvol uitvoeren van je geautomatiseerde testen reden voor het terugsturen van je software.
Daarom zou directe feedback over de stand van zaken in je ontwikkelstraat waardevol. Je wilt proactief weten of er iets uitligt zodat je alvast acties kan uitzetten.
Bij een DevOps werkwijze wordt de verantwoordelijkheid van het team nog verder uitgebreid
Indien verstoringen/incidenten in productie, is het vaak alle hens aan dek, met bijhorende impact op het ontwikkelwerk
Grip op operations, zo snel mogelijk incidenten signaleren, of liever nog, mogelijke knelpunten voorspellen zijn erg waardevol
Samengevat is de oude manier van rapporteren ongeschikt
De kortere cyclussen vragen om eerdere en sneller feedback.
Doordat de fasering en overdrachten verdwijnen, verdwijnt ook veel noodzaak. Bevindingen bespreek je team breed, feedback krijgen van de acceptanten krijg je in de demo
En acceptanten aan IT zijde (vaak ‘beheer’) zitten bij DevOps inmiddels ook in je team. Een overdracht op papier heeft daarbij vaak ook weinig toegevoegde waarde meer, omdat je naast elkaar zit en samen de verantwoordelijkheid deelt
Maar hoe rapporteert men dan nu binnen de nieuwe ontwikkelmethodieken over de resultaten/voortgang van het testen (en dus de kwaliteit van de software)?
We verwijzen naar het scrumboard. Grote bevindingen zijn impediments, of soms nieuwe taken. Kleine bevindingen worden veelal direct opgelost
En voortgang kun je zien aan de status van de taken. Zolang testen nog in progress is, is men nog niet klaar. En indien opgeknipt in verschillende taken (bv uitvoeren testcase a, b etc), is het op meer detail niveau te volgen
2) En er worden vaak detailrapportages verstuurt naar stakeholders buiten het team. Een mailtje met een samenvatting en de status. Soms voorzien van een dashboardje of een template (vrijgave advies). En de belangrijkste impediments.
Focus is nu puur gericht op productie, dat deze blijft draaien
Aandacht met name voor techniek. Draaien de servers nog, is de applicatie nog in de lucht. Zit de database nog niet vol?
Soms aandacht voor performance, zijn de responstijden nog binnen
Maar dat is erg reactief en zonder verdere informatie over oorzaak/richting
Spreekt voor zich
Intro naar toekomst
Unittesten, goed te monitoren. Dekking, aantal succes/failed, maar zorg ervoor dat je ze op een omgeving doet die representatief is voor je uiteindelijke productieomgeving
Testen op functionele paden. Bij een testgeval, heb je je verwachte resultaat, op het moment dat je die ‘aftrapt’ weet je op welke punten je moet gaan monitoren en terug koppelen of ze correct zijn. Uitbreiding op soms al bestaande testautomatisering. En in productie kun je op basis van verleden monitoren op functionele paden. Als er normaliter 80% goed gaat, 10% uitvalt in stap 1, 5% uitvalt in stap 2 en 5% uiteindelijk handmatig gaat, kun je daar op afwijkingen monitoren. Als er ineens veel meer fout gaat, dat je al preventief een signaal krijgt.
Scannen op errors, kijken of er niet onverwachte errors in loggings verschijnen, deze kunnen informatie geven over waar in je keten mogelijk toch iets niet goed zit
Performancemonitoring, kijk op je testomgevingen, maar ook op productie of je performance nog acceptabel is, op de diverse facetten (responstijden, proces doorlooptijd, aantal tegelijke threads)
Omgevingen zijn vitaal om je kort cyclische ontwikkelmethodiek niet te veel te verstoren. Daarom wil je graag weten als
De technische stabiliteit niet in orde is. Belangrijke servers of databases die niet beschikbaar zijn bijvoorbeeld
Afhankelijkheden van derden die je zelf niet kan controleren monitoren. Zodat je als iets niet beschikbaar is, direct daarop actie kan ondernemen, of wellicht nog beter, een alternatief gaat inzetten
Consistentie van je testdata controleren. Is testdata waar jij van afhankelijk bent door bepaalde testen (zeker indien andere partijen gebruik maken van de zelfde omgeving) omzeep geholpen. Liever controleer je dat vooraf (of continu) dan dat je pas na het uitvoeren van je test merkt dat er iets niet klopte.
Ook metrieken bijhouden van je ontwikkelproces kan je helpen om meer waarde te leveren in dezelfde tijd (bij een agile/scrum aanpak)
Het aantal succesvolle deploys, die in 1 keer de hele straat door gaan. First time right en geen rework. Naarmate het team volwassener wordt vaak een stijgende lijn
Bijhouden waar je welk soort bevindingen doet. Zijn het zaken die je eerder (bv in je Unit test) al had kunnen vinden. Is het wellicht al vanuit je requirements/refining gekomen. Een monitor helpt inzicht geven
Je velocity van het team monitoren. Als er ineens een aantal dagen geen voortgang is, of er een dalende lijn in zaken die opleverd worden, dan kun je je als team gaan afvragen waar dat door komt. Maar signaleren is 1
Impediments monitoren. Wanneer deze rap oplopen en niet snel worden opgelost, is het goed om stakeholders hier pro actief over te informeren, en zo ook de mensen die impediments kunnen wegnemen (vaak management) aan het werk te zetten
Let op: Dit soort monitoring moet altijd door het team gewenst en gedragen worden. Het opleggen aan een team heeft vaak een averechts effect. En de meeste high performance teams worden gevonden in omgeving waar zij zichzelf kunnen organiseren. Biedt ze hulpmiddelen aan, maar dring ze niet op.
Wil je monitoring goed oppakken, neem het dan op in je Definition of Done want:
Waardevolle hulp in je ontwikkelproces
Je bouwt de expertise breed op in je team, kennis delen en tijdens standups/demo’s komt het voorbij
Om zaken goed te kunnen monitoren zijn soms extra acties nodig, bijvoorbeeld het ontsluiten van data
Je borgt de afronding (we zijn niet klaar voordat we ook de monitoring goed hebben staan) en ook stakeholders zijn zich er continu van bewust
Altijd een keuze (zoals elke DoD) van ProductOwner en team.
Testers weten vaak goed welke dingen het meest risicovol zijn. Dat zijn ook de zaken waar je als eerste effort in stopt om monitoring op te tuigen
Het bepalen van het verwachte resultaat, en waar dat gechecked moet worden is iets wat nu vaak ook in onze way of work zit
Voor het doorvoeren van testgevallen, of het ophalen van de resultaten kun je veel bestaande testtooling gebruiken als onderliggende bron voor je monitor
En test ook de monitoring zelf. Immers, als je gaat vertrouwen op de informatie die op de monitor staat, is het essentieel dat de informatie juist is!
Meer automatisering, kost ons een hoop uitvoerend werk. Iemand zonder verstand van zaken maakt er nog steeds een potje van. En automatiseer de standaard zaken (monitor deze), zodat je de aandacht weer op andere dingen kan richten. Meer doen in minder tijd!
Testen als losse fase verdwijnt. Ja, in Agile/Scrum projecten is dat soms al het geval, en in DevOps omgevingen helemaal. Het blijft een specialisme welke noodzakelijk blijft, maar hij wordt veel breder ingezet, zodat kwaliteit onderdeel wordt van de way of work. En continu! Niet alleen in de testfase en op je testomgeving!