Sådan designes og opbygges en Hyper-Fast Test Automation Stack

Hvorfor du har brug for real-time testautomatisering og rådgivning til de bedste produkter til at skabe den.

Robotløber, der starter en sprint

Som konsulent, træner, forfatter og udvikler, der er specialiseret i softwarekvalitet og automatiseret test, bliver jeg ofte spurgt om mine meninger og råd om, hvordan man nærmer sig at designe en testautomatiseringsstabel.

Så i dag tænkte jeg, at jeg ville prioritere at dele nogle uddrag fra min kommende guide, der angiver mine meninger om, hvad der udgør en god testautomationsstabel, og hvordan du kan nærme dig at oprette en til dig selv.

Hvad skaber en god testautomationsstabel?

Min mening om individuelle produkter og leverandører ændrer sig med tiden, ligesom produkterne selv. Men hvad der aldrig vil ændre er mine fire gyldne regler om testautomation, som er:

1. Formålet med testautomation er at give hyper-hurtig feedback til udviklere.

"Feedback" betyder både bekræftelse af succes og anmeldelse af et problem. For eksempel er en bug en type feedback, der signaliserer et problem, der typisk rapporteres godt efter, at udvikleren mener, at deres arbejde er afsluttet. Tilsvarende er en testfejl en anden form for feedback, og dette sker på kodningstidspunktet.

Hvorfor er dette så vigtigt?

På grund af min anden gyldne regel, der vedrører feedback selv, som siger:

2. Jo længere feedback lever i et system, jo ​​dyrere er det at håndtere det.

Tænk på en fejl, der løses hurtigt, når udvikleren, der skrev koden, stadig har kontekst versus når fejlen opdages uger senere og rettes af en person, der skal genlæse koden. Hvilket ville være hurtigere og derfor billigere at løse?

Desuden,

3. Jo mere uløste feedback, der akkumuleres i et produkt, jo lavere er kvaliteten af ​​selve produktet.

For eksempel, hvis kunderne giver feedback om, at produktet ikke leverer deres behov, og denne feedback indfanges, men ikke behandles, opfylder produktet ikke den potentielle værdi for brugerne og er derfor af lav kvalitet.

Alle ovenstående beløb til min fjerde regel, som er:

4. Jo hurtigere du kan registrere og håndtere feedback, jo lavere udviklingsomkostninger og jo højere kvalitet på dit produkt.

Du kan øge kvaliteten, hvis du fokuserer din indsats på at opdage og håndtere feedback. Det er så enkelt. Derfor skal enhver beslutning, du træffer i design og implementering af en teststabel, være i tjeneste for at optimere hastigheden for at registrere feedback, da det er det første skridt til at tackle den.

Hvem skal designe din testautomationsstabel?

Ethvert medlem af dit team kan bidrage til design og implementering af din teststabel. Naturlige ledere for indsatsen ville typisk være de tekniske arkitekter, en stærk fuldstakkenudvikler eller måske lederen for QA-teamet. Men vigtigst af alt,

Udviklerne SKAL selv eje teststakken.

For at forstå hvorfor, skal du tænke tilbage på den tidligere nævnte gyldne regel - "Den første prioritering af testautomation er at give hyper-hurtig feedback til udviklere."

Denne gyldne regel gælder på alle aspekter af din leveringscyklus, men især i det lokale udviklingsmiljø. Så for at en testautomationsstabel skal lykkes i praksis, er den nødt til at komplementere udviklingsarbejdets arbejdsgang og levere feedback i realtid, når der skrives kode. Ikke efter, men under.

Alt for ofte ser jeg QA-teamet eje testautomatisering, men QA-teamet fungerer efter udvikling, og det er for sent! I mere avancerede teams ser jeg udviklere udelukkende stole på deres kontinuerlige integrationsservere til at køre deres automatiserede test. Selvom dette er let år foran QA-teamet, der ejer testautomatiseringen, er det stadig suboptimalt.

Tænk på det på denne måde: Hvis du kører et sted ved hjælp af et GPS-system og tager en forkert drejning, vil du foretrække at blive fortalt det med det samme, eller vil du hellere vente, indtil du ankommer til den forkerte destination?

Beskyt kvalitet på hvert trin

Så hvordan kan du opbygge en hyper-hurtig feedback loop?

Du øger feedback på alle byggetrin.

Og det betyder, at man fjerner muligheden for, at defekter kommer ind i systemet på alle faser i softwareudviklingscyklussen. Lad os gennemgå et eksempel.
For at bruge en metafor i den virkelige verden, lad os sige, at vi bygger et klimaanlæg.

  1. Ren
    Det første trin er at fjerne alle filer, der er genereret fra tidligere builds, såsom kompilerede filer, og starte build-livscyklus fra en ny baseline.
    Dette er som at rydde din arbejdsbænk af alle bit og stykker, før du begynder at bygge noget nyt.
  2. Udarbejd kode
    Dette trin tager kildekodefiler og omdanner dem til eksekverbar kode. Produktet fra dette trin er at oprette koden for en given komponent.
    Dette trin er ækvivalent med at fremstille de komponenter, der er nødvendige for at opbygge vekselstrømmen, såsom den ventilator, der er nødvendig for at drive luft og den motor, der drejer ventilatoren.
  3. Kør enhedstest
    Enhedstest er bare et andet navn på eksekverbare specifikationer for komponenter, der fortæller os, om komponenterne fungerer som specificeret. Hvis der ikke er komponenter, er der ingen grund til at fortsætte med at opbygge systemet. Husk, at værdien oprettes ved hjælp af komponenter, så en defekt komponent vil resultere i defekt værdi.
    I AC-eksemplet ville en enhedstest sikre, at ventilatorbladene er i stand til at drive luft, når de drejes. Hvis ventilatorbladene ikke fungerer, er det bedre at først fikse ventilatorbladene og derefter genstarte byggeprocessen.
  4. Kør integrationstests
    Når vi ved, at komponenterne fungerer individuelt, kan vi sammensætte dem og kontrollere, om de skaber værdi unisont. Dette er formålet med integrationstest. Disse test kombinerer lige nok enheder til at skabe værdi, og som det foregående trin, hvis vi finder, at komponenterne ikke fungerer sammen som specificeret, er der ingen grund til at fortsætte med at opbygge systemet, da værdien er defekt.
    Tilbage til AC-eksemplet, hvis vi samler ventilatoren og motoren og opdager, at der ikke fremmes luft på grund af, at spindlen ikke passer, er det ikke noget formål at sætte enheden sammen med resten af ​​AC.
  5. Distribuer app
    Hvis vi kommer til dette punkt, og vi har stor testdækning, betyder det, at alle komponenter arbejder individuelt og unisont for at skabe værdi. Dette giver os stor tillid til at samle det fulde system. Men vi er stadig ikke 100% sikre på, at det fungerer, da noget andet kan gå galt i ende-til-ende-montageprocessen. Derfor er vi nødt til at udføre yderligere test, når vi implementerer appen.
    Med vekselstrømsmetaforen handler dette trin om at sætte det alle komponenter og samlinger sammen og forbinde det til netspændingen.
  6. Kør ende-til-ende-test
    Med systemet fuldt ud implementeret, kan vi nu sikre dig, at det giver den tilsigtede værdi til forbrugeren. Disse test sikrer, at værdispecifikationerne overholdes.
    Tryk på on-knappen, drej temperaturkontrolknappen til de kolde indstillinger, og sørg for, at der køres luft.

På dette tidspunkt har vi meget stor tillid til, at den nye kode giver den tilsigtede værdi, og vi kan sende AC til kunden.

Imidlertid…

Hvis disse trin udføres i rækkefølge i slutningen af ​​hver funktion (som normalt er tilfældet), får udvikleren ikke reel feedback, før hele denne proces er afsluttet. Og det tager alt for lang tid, og derfor er det for dyrt.

Men med en hyper-hurtig teststabel får du stor selvtillid, mens du faktisk skriver kode!

Ja! Det er absolut muligt at give udviklere ende-til-ende feedback i realtid under udviklingen. Læs videre for at finde ud af hvordan.

Match din teststabel til din teknologiske stabel

I betragtning af at teststakke nøje skal følge udviklingsfunktionerne, er det fornuftigt at betragte din tekniske stak som et udgangspunkt for valg af en teststabel.

Denne artikel er fokuseret på en Node.js tech stack. Jeg elsker Node.js, fordi det er så forbandet hurtigt at udføre opgaver som build, test og implementering, og fordi teknikker som at køre test, når filer ændres, er normen.

Hvis du ikke bruger Node.js

Denne artikel skal stadig være nyttig, da koncepterne er de samme. Bare søg på Google efter det tilsvarende værktøj til din tech-stack, og lad mig vide, hvad du finder enten i kommentarerne nedenfor eller på Twitter.

De bedste produkter til en Hyper-Fast Test Stack

Med henvisning til processen defineret ovenfor, her er en liste over mine anbefalinger til testkvalitet på hvert af disse store trin.

Til realtidsenhedstest lokalt

Jeg anbefaler Wallaby.js
Wallaby.js fortæller dig, om NOGEN test passerer eller mislykkes i realtid på hver tastetryk!

Med hver enkelt tast, jeg trykker, fortæller Wallaby mig, om noget brød eller gik forbi. Det anvender en meget smart teknik for at vide nøjagtigt hvilke test der skal køres, og det kører dem alle parallelt. Resultatet får dig til at sige "wow!"

En video maler en million ord (fra webstedet Wallaby.js):

Mere info: https://wallabyjs.com

Til realtidsintegrationstest lokalt

Jeg anbefaler Chimp.js
Chimp validerer din virksomheds domænelogik, hver gang du gemmer en fil.

Jeg bruger Chimp's domænetestningstilstand. Det er et værktøj, som vi skrev hos mit firma, der ser filsystemet og kører servicetestene med hver ændring igen. Resultatet er hurtig feedback på status for domænelogikken for Node.js-apps.

Mere info: http://chimpjs.com

Til realtids-ende-til-ende-tests lokalt

Jeg anbefaler også Chimp.js
Chimp validerer den ende til ende-funktion, du arbejder med, hver gang du gemmer en fil.

Jeg bruger Chimp's ende-til-ende-testtilstand. I stedet for at køre alle ende-til-ende-tests på alle gemte filer (hvilket vil tage alt for lang tid), ser Chimp efter et specifikt mærke og kører de mærkede tests igen. Dette enkle trick holder dig meget fokuseret på den opgave, der er ved hånden, samtidig med at du giver super hurtig ende til ende feedback.

Chimp fungerer også til enhver webapplikation - uanset backend.

Mere info: http://chimpjs.com

Til orkestrering

Jeg anbefaler Gulp.js
Gulp er dirigent for orkesteret.

At få alle brikkerne til at arbejde problemfrit kan være en udfordring, og du har brug for et værktøj, der kan arbejde lige så hurtigt som dig. Det er her Gulp.js kommer ind.

Gulp.js er et streaming build-system, der er fantastisk til orkestrering. Jeg bruger den til at køre komplekse opgaver lokalt - for eksempel: starte appserveren, vente på en meddelelse og derefter starte Chimp. På den kontinuerlige integrationsserver kører den enhedstest ved hjælp af Mocha & Karma, indsamler kodedækning og kører røgprøver.

Du kan også bruge Gulp med ikke Node.js-teknologier også. Jeg har for nylig brugt Gulp til at kontrollere Maven-opgaver til et Java-projekt på grund af Gulp's overlegne filovervågningsevne.

Mere info: http://gulpjs.com

Vil du vide mere?

Denne information er et forkortet uddrag fra min snart frigivne vidensbase og vejledning "Kvalitet hurtigere." I det beskriver jeg detaljeret, hvordan jeg implementerer disse og andre teknologier som en del af et helhedsorienteret, fuldt team-tilgang til højere softwarekvalitet.

Den detaljerede skriftlige guide er ledsaget af kodeeksempler på GitHub og kommer også med adgang til et dedikeret samfund af udviklere, QA-ledere og produktledere, der diskuterer og deler om alle aspekter af test og kvalitet.

Kom og tjek det nu.

I mit næste indlæg

Jeg viser dig, hvordan du kan udvide den hurtige feedbackfilosofi, der er oprettet i dev-miljøet, til det bredere team, og jeg vil også vise dig, hvordan du opretter en holistisk kvalitetsproces, der er bygget til hurtigere feedback på hvert trin.

Er du enig eller uenig?

Hvis du er uenig i mine anbefalinger om værktøjer, eller kender et andet værktøj eller teknik, som du synes er endnu bedre til hyper-hurtig feedback, vil jeg altid høre om det! Så lad mig det vide via kommentarfeltet her, eller ved at oprette forbindelse på twitter på @sam_hatoum

Og hvis du kan lide det, du læser, skal du hjælpe med at dele dette med andre ved at klikke på knappen anbefaling.

Tak, og jeg ser frem til at hjælpe dig med at levere software af højere kvalitet hurtigere.

Sam.

Andre artikler, jeg har skrevet: