Testnet Presentatie: Testen = Monitoren
•Télécharger en tant que PPTX, PDF•
0 j'aime•469 vues
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.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (12)
En vedette
En vedette (20)
Similaire à Testnet Presentatie: Testen = Monitoren
Similaire à Testnet Presentatie: Testen = Monitoren (20)
Testnet Presentatie: Testen = Monitoren
- 1. 1 Testen = Monitoren Hoe de werkzaamhedenvan de ‘boodschapper van de koning’gaanveranderen. Spreker: IdeKoops Datum: 30April 2015
- 2. 2
- 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
- 6. ● Breed publiek ● Veel inhoud ● Momentopname Inhoud Rapportage 6
- 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
- 9. Impact Agile/Scrum ● Testuitvoer vaak onderdeel van Definition of Done ● Testvoorbereiding meestal ook ● Testafronding echter… 9
- 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
- 18. Bijvoorbeeld: ● Unittesten Monitoren Kwaliteit Software 18 ● Functionele paden ● Scannen op Errors ● Performance
- 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
- 22. ● Welke informatie voor wie? Informatie op de monitoring 22
- 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
Notes de l'éditeur
- 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!