Create your own testing strategy to move towards Continuous Delivery.
•Download as PPTX, PDF•
2 likes•1,447 views
There are higher and higher demands on speed, mobility and quality in software development. To meet the demands quality needs to come naturally in the whole process and new technologies needs to be used, such as Continuous Delivery, to cover the entire flow from check to installed and tested software. This changes the testing strategy work and requires a change in culture for all employees in development and testing. Getting technology to support test work is not only to be seen as a tool but also as discipline and behavior. This can be difficult to change and competence, communication and incremental change are crucial factors for success. How to think in order to create a test strategy to meet the needs of today, get a cultural change and implement them as a natural part of everyday life is what this presentation is about
Recommended
Recommended
More Related Content
What's hot
What's hot (17)
Similar to Create your own testing strategy to move towards Continuous Delivery.
Similar to Create your own testing strategy to move towards Continuous Delivery. (20)
More from ADDQ
More from ADDQ (13)
Recently uploaded
Recently uploaded (20)
Create your own testing strategy to move towards Continuous Delivery.
- 4. Anna Almén Mail: anna.almen@addq.se Mob: 076-1139309
- 5. • Adaptive • Self-organized • Co-operation between agents • Interaction form patterns • Emerge • Non-linear 𝒇(𝒙 𝟐) • Fragile/Antifragile COMPLEX SYSTEMS
- 6. “the scientific study of control and communication in the animal and the machine” CYBERNETIC CONTROL
- 8. Cohns - Test Pyramid UAT Workflows Component Integration Business Rules API Service Layer Unit Level / Component Tests
- 9. Test Cadence Continuous builds with unit tests Continuous functional tests Code branch Commit Pas s Project continue s Release Build Release package Continuous builds with unit tests Continuous functional tests Continuous performance tests Code branch Fail
- 10. Nightly Builds/Tests Yearly Release Cycles Mainly Q2 Tests TDD was announced be implemented Services performed manual regression test No Performace Test Monolith (approx 4 millions lines of code) Full suite of tests approx 1 week Dependency on External Test Environments Ice Cone Pattern ? Automated Robot Tests
- 11. Too busy to start?
- 13. 13 1.1 Continuous Builds (OODA Loop) Decide ActObserve Orient
- 14. Continuous Integration Version Control, code, scripts, … Automated Build Agreement from team Degree of disipline
- 17. 17 What is Continuous Delivery? • Configuration Management • Version Control • Managing Dependencies • Committing and Building • Test Strategy
- 18. Push a Button Release
- 20. 20 3.3 Business Tests non Trivial Changes
- 23. • Keep it simple! • Make it incremental and celebrate success • Set a cadency and grow from there • Take care of the infrastructure • Use Cybernetic Control Summary
Editor's Notes
- Praktiskt Vi kommer att svara på frågor
- Lisa Crispin and Janet Gregory’s Agile Testing Quandrants Jag har gjort lite modifieringar. I botten ser vi teknologi perspektivet, och i toppen business perspektivet. Man kan säga delvis till hur stor del stödjer den testningen man gör design vs att göra rätt saker. Typiskt på unit nivån så är den största nyttan av testerna att vi tvingar fram en viss design av arkitekturen som i sin tur är bättre kvalitetsmässigt. Vi har också till väldigt stor del automatiska verktyg för att stödja den formen av testning. De övre dimensionerna fokuserar på vad vi löser för buisness problem. Från vänster till höger har vi dimensionerna hur mycket vi stämmer av mot vad vi vet mot hur mycket vi stämmer av nuläget för att anpassa vår styrning efter ny information. Gör man automatiska regressionstester funktionellt är de typiska i vänstra hörnet och gör man explorativ testning är det typiskt i högra hörnet. Av naturliga skäl är det svårare att tänka automatisk testning på högra sidan. Man kan använda verktyg men iom att du vill skapa dig en observation av nuläget så är det inte som ett verktyg för att repetera informationssökning. Resultat av olika delar var du än befinner dig bör flöda fritt mellan alla kvadranter relativt kontinuerligt. I mitten har jag lagt till allmän infrastruktur som hjälper alla areorna att jobbar mer effektivt. Det är både testbarheten på arkitekturen, vilken form av infrastruktur vi har för installation, byggen, versioner. Men även områden inom DevOps som stödjer feedback, loggning, möjligheter att analysera i produktion osv. Tittar vi på vilka typiska aktiviteter vi hittar i olika kvadranter så har vi exvis.... Test Results (reporting), Test Environments, Defect Tracking, Test Tools Why Bother? Who Cares? How Much? – Lessons Learned in Software Testing A good test strategy explain and justify the testing to be done. Test Strategy should be: Product-specific (your context), Risk-focues (things that matter), Diversified (varety of test techniques or approaches). Practical (capacity of what you have).
- Mike Cohn skapade vad han kallade en test pyramid, dock exemplifierad mer som en triangel. Detta skapar en slags ekonomiska restriktioner för att balansera kostnaderna som tillkommer vid testning. På översta nivån har vi end-to-end, tester från business fokus som går igenom hela systemet. I mitten har vi componentlagret, har vi ett serviceorienterat API exvis som trenden med Microservices, lägger vi tester som går mot det apiet. I botten har vi unit lagret de tester som testar en liten del, typiskt endast delar av koden. Vi vill att tester ska gå neråt, dvs om vi exvis får ett fel på den översta nivån och upptäcker var i koden detta inträffar så är det en fördel att skriva nya tester på lägre nivån och ta bort de på översta nivån. Fallgropen många går in på är att man i för hög utsträckning värderar informationen endast om de verkligen checkat av end-to-end, samt att man är rädd för att ta bort tester. Jag vill jämföra det med teknisk skuld, dvs att man över en längre tid får ett för dyrt system som är svårrörligt, och i för liten grad analyserar nuläget efter ny information. För att skapa en triangel så har jag lagt in dimensionerna vad vi testar och aktiviteterna på baksidan. Exvis har vi konfigurationstesting, boundary testning, load testning osv. Ska vi ta ett arkitekturellt tips så ser man till att även om vi befinner oss på samma nivå så betyder inte det att vi måste skapa en monolitisk testsvit. I synnerhet kan det vara bra att inte blanda funktionell feedback med stresstester. Ännu bättre om vi till och med kan stödja parallel exekvering, men här beror det mycket på vilken form av arkitektur test objektet har. På Orc evolverade vi system arkitekturen vilket möjliggjorde att bygga tester bättre i relation till pyramiden, en samsyn både från min och vår CTOs sida. Higher – Happy Path, Lower – Boundary, Corner, Unhappy-paths (Remeber to iterate and refactor where tests are) The automated tests form a specification of the behavior of the system. Catching Failures Lower Levels Refactoring with time, remove tests Avoid Monoliths
- Jag gillar att cykla, och en enkel regel i cykel är hög och samma kadens oavsett lutning sedan kompensera med en lagom låg växel för att orka hålla den kadensen. Samma sak gäller delvis för testningen. För att kunna guida utvecklingen vill vi ha hög kadens, men gärna med små portioner av input (låg växel). Det finns förvirring angående commit och branchning, vad som avses är den utveckling som görs här och nu så feedback ges på just denna del så tidigt som möjligt. Har man många parallellt levande brancher blir bilden komplexare varför många företag som jobbar seriöst med automatisk testing förespråkar få eller till och med endast en branch. Hög kadens på just denna del, fokus och disiplin snarare än kontextswitchning i många olika delar. Detta är en av de delarna man lätt tappar bort I agila principer och en övergång från något där feedback loopen inte var speciellt stark. Indiviuella effektiviteten kan kännas högre om man får jobba helt separate, man vill göra allt klart innan man lämnar över för feedback. Då vi vill snabbt kunna anpassa oss efter ny information är feedback loopen vår nyckel att få igång snabbare styrning. Så många små incheckningar och en feedback loop som startar direkt är önskvärt.
- När jag började på Orc såg min bild ut lite så här. Kallas även för Ice Cone Pattern, majoriteten var automatiska regressionstester som checkade av produkten på system nivå. Långa cykler ett år mellan feature releaser. En veckas automatisk testning bara för att få ut en bugg patch releaser. Ingen fokus på prestanda, och helt beroende av externa miljöer för att testa av komponenter samt en monolitiskt system. Så Q2 fokus, och låg kadens, men innan dess fanns ingen testning då skickade man ut trasiga binärer till kunder, så under den tidigare kontexten så hade man tagit ett steg framåt.
- I verkligheten kan det se ut så här. Man känner att det kanske går fortare men det är ändå svårt att få in tiden. Jag fick anställa några personer för att komma igång, men har även fått jobba med mycket inkrementell förändring. Alltså där vi betar av lite av delarna under en längre tid. Kommer man och berättar om ett för stort gap i relation till nuläget så är det svårt för många att ta till sig. De kanske känner att det är bra men helt orealistiskt. Så vad vi gjorde var inspirerade av Googles liknande program att skapa lite mer stegvis förändring, samt låta team själva styra sin utveckling, dvs sätta vad de skulle uppnå till nästa sprint osv. Då blir man lite mer nöjd med vad man lyckats komma till för delmål, samt att det är lättare att jobba mer parallellt med utvecklingen och kvalitetsförbättringar. Jag fick också stöd av mina managers för att göra detta.
- Steg för steg programmet som vi körde har ni i handouts, vi kommer gå igenom några inte alla för att ni ska förstå lite vad man vill uppnå.
- Krav 1.1 Colonel John Boyd, USAF. Skapade en modell för beslutsfattande när han upptäckte att trots vassare tekniska stridsplan förlorade ändå de mot motståndaren och han ville analysera varför, då upptäckte han att anledningen var OODA loopen var snabbare hos motståndaren. Continuous Builds är jätteenkla att sätta upp, alltså kan teamen klara målet snabbt och är en förutsättning för att få igång kadensen. Vad som är en viktig kulturell del är att få igång act, dvs att man inte bara har byggen men att man agerar på resultaten, vilket på nästa bild är exemplifierat med en teknad serie.
- ”Continuous Integration was introduce by Kent Beck´s Extreme Programming Explained 1999” För att lyckas med CI måste man ha allt versionshanterat, automatiska byggen, att teamet är med på att de jobbar så här samt displin. Med fördel lär man sig också att bryta upp arbete i mindre bitar. Att checka in månaders av arbete kommer garanterat ställa till problem, varför att jobba I många parallella brancher bör ske med försikt.
- Under 4.1 hade vi Guarded Commit, där i vårt fall använde vi Gerrit som verktyg. Med en guard så mellan lagras de delar man vill checka in och för att släppas igenom måste de passera vad man lagt in som beslut. Exvis passera alla unit tester. Vi la in unit tester och kodgranskning. En del kan uppfatta en guard som onödig, men många ser det också som extra skyddsnät. Jag behöver inte oroa mig för att ha sönder bygget då guarden kommer stoppa detta. Google som har många utanför företaget som leverar kod till deras open source projekt använder guarden för att granska ändringarna att följa designprinciper. Man måste ha kommit igenom disiplin och lärt sig att bygga saker i mindre bitar för att detta ska vara hjälpfullt i praktiken, annars är risken stor att någon kravställare/projektledare är stressad över att få en fix snabbt och man går förbi istället för att felsöka.
- Under 4.2 knyter vi ihop Q1 och Q2 från våra kvadranter till ett automatiskt flöde. Här är det viktigaste igen inte att ha massor med tester i Q2 som vi vill trycka in utan kulturen runt hanteringen av fel. Din funktionella test svit som är med i en delivery pipeline måste vara robust, dvs det får inte finnas så stora fluktationer från test resultaten. Så får man lägga till saker när de är robusta. Test sviter för funktionella tester körs ofta längre tid än de 15 min vi ville för unit nivån. Det är helt ok, så länge det inte blir orimligt länge. Kadensen man vill ha på dessa tester är i relation till antalet incheckningar som sker per tidsenhet. En bra princip för felhantering är att slänga ut den senaste incheckningen som strulade. Dvs max 10 min felsökning sedan släng ut. Att tillsätta någon som för tillfället har ansvar för resultaten är bra iom att de går lite längre tid och många jobbar med andra saker emellan. Att låta den rollen rotera i teamet är ännu bättre iom att de lär personer att försöka tänka till på hur de undviker att det blir rött.
- Förutsättningarna för CD är: Kontroll på sin configuration, versions hantering, men även dependency hantering mellan komponenter både externa och interna. Bygg steget och sedan dina tester, vilka tester kör du var, hur vill du dela upp dina olika tester i olika sviter, hur ofta vill du köra dem osv. Sedan bör man lära sig arkitekta sina tester till att bli robusta. Med fördel använda lite av samma principer som övrig kod, code review guards osv. Våra robot tester som vi hade var för sköra för att köra i CD, där kunde en rörelse med muspekaren få testerna att ramla. Så den nivå vi valde att jobba med har primärt varit service api tester. En liten vy kommer på nästa sida hur det praktiskt ser ut. Basically the chain of Commit, Compile, Configure, Test, Release, Deploy, Install... As much as possible in a predicted, automated, controlled way... Why? To have a process as efficient and reliable as possible Reduce the ”cycle” time, the time it takes from deciding to make a change, wheather a bugfix or a feature, to having it available to users.
- Pull vs Push Exploratory Testing – kompletterande testning exvis vår del från Q3 bör ske med hjälp av att man själv plockar det man vill ha istället för att kedjan pushar för att uppgradera testsystemet.
- Sedan har vi en rad för coverage, först bara att sätta upp vilken man har vi använde oss av SonarQube för detta. Som med alla former av mätningar, så är det viktigt att styrningen är lagom hård och inte polisiär. Sätter man exvis upp att lönen baseras på code coverage så kommer man se en väldigt hör coverage men till liten nytta, kanske saknas helt asserts som faktiskt kollar något. Syftet hos oss var att få flera sätt att instrumentera var vi befinner oss, och också svagheter. Så en lagom balans mellan för vem gör vi detta. Iom att jag som jag sa i mitt program hade allt som kriterier som sedan teamen själva fick styra mer över vad de jobbade med just nu så ökade motivationen till att inte försöka bara göra saker för att göra management glada. Det hade dock en effekt när olika team fick se sina olika komponenters resultat i sina egna tävlingsinstinkter. De som hade höga resultat var lite stolta och ville visa mig. Genomlysning i sig själv kan ha väldigt bra effekter.
- Swindon, Magic Round About – Google Maps 3.3 handlar om var vi vill prioritera våra tester. För att exemplifiera detta gillar jag denna bild. Det är Swindon i London sett från Google Maps, det är bara söka själva om ni vill se. Arkitekten där har löst rondell designen på ett annorlunda sätt, och för att vara ett så relativt enkelt problem skapat en komplicerad lösning. Kod som är lika kreativt lösta som Swindons rondell kommer garanterat när någon ändrar generera problem. Så ser vi detta tjänar vi på att lägga till tester. Allmänt i relation till ökningen av tester så kommer ni se när ni läser själva att den är prioriterad mycket i relation till vilka ändringar vi vill göra nu. Det är lättare att jobba upp coverage i relation till arbetet som sker nu än att tänka att vi ska avsätta ett stort projekt för att komma ikapp.
- Sista kriteriet jag tänkte gå igenom är 3.7 kod granskning. Vi införde det som en del av guarden. Kodgranskning jobbar också i Q1, den hjälper designen. Två andra fördelar med kodgranskning är att den hjälper att hålla nere antal incheckade rader. Din kollega blir inte glad om du kommer med 1000 raders kod som han eller hon ska gå igenom. Samt om man sparar kommentarer får man dokumentation som speglar saker som man kanske borde tänka på.