Lederskap innen testing: Verktøy for testgjennomføring

Testautomatisering (testkjøring)

Testautomatisering (vanligvis gjennom et grafisk brukergrensesnitt) står høyt på agendaen til de fleste testere og testledere. Ved første øyekast ser disse verktøyene ut til å ha stort potensial, men mange organisasjoner som ønsker å automatisere deler av eller all sin funksjonelle testing, støter på problemer.

Vi går ikke inn i for mange tekniske detaljer i denne artikkelen, men vi kommer inn på noen av problemstillingene som er relevante for test- og prosjektledere som må utarbeide en forretningsbegrunnelse for automatisering. Vi skal se på:

• Hva du får og ikke får fra verktøy for testkjøring
• Testautomatisering av grafisk brukergrensesnitt (GUI)
• Testautomatisering av API-er og tjenester
• Regresjonstesting
• Rammeverk for testautomatisering

Det er viktig å ha realistiske forventninger til hva automatisering kan og ikke kan gjøre, så de neste delene kan virke noe pessimistiske.

Hva du får og ikke får fra verktøy for testkjøring

Enten du tester Windows-skrivebordsapplikasjoner, nettsteder eller mobile enheter, er prinsippene for testautomatisering, fordelene og fallgruvene de samme. Dette får du fra verktøyene:

• En utrettelig, angivelig feilfri robot som kjører hvilke skriptbaserte tester du ønsker, ved behov og så ofte du vil.
• En presis sammenligning mellom utdataene og/eller resultatene fra tester og forberedte forventede resultater, på det detaljnivået du er villig til å programmere inn i verktøyet.

Dette får du ikke:

• Fleksibilitet og smidige reaksjoner på avvik, feil eller tvilsom atferd.
• Øynene og tenkeevnen til en menneskelig tester som er i stand til å ta beslutninger om å utforske, stille spørsmål, eksperimentere med og utfordre atferden til systemet som testes.
• Tester uten kostnad. Du må for eksempel fortsatt utforme tester, klargjøre testdata og forventede resultater.
• Selv om verktøy for testkjøring tilbyr en rekke funksjoner, mangler de ofte avanserte funksjoner for datalagring. Hvis du ønsker en mer omfattende løsning, kan du utforske den beste tilgjengelige programvaren for databaseadministrasjon.

La oss se nærmere på betydningen av disse fordelene og problemene.

Hvis du er en rimelig kompetent programmerer, er det enkelt å implementere prosedyrebaserte tester som mennesker kjører, som automatiserte prosedyrer i skriptspråket til verktøyet, slik at verktøyet kan kjøre dem nøyaktig.

Så lenge miljøet og dataene som brukes av testapplikasjonen din, er konsistente, kan du forvente at testene kjører pålitelig om og om igjen. Dette er det åpenbare løftet ved automatisert testkjøring.

Men automatiserte tester simulerer ikke nøyaktig det (gode) testere gjør når de tester.

En test som kjøres av et verktøy, er IKKE det samme som den samme testen kjørt av et menneske.

En test kan, hvis den er skriptbasert, fortelle testeren hva som skal gjøres. Men testere kan se forbi den enkle sammenligningen mellom et forventet resultat og resultatet som vises på en skjerm.

Testere må navigere til stedet der testen skal utføres, og være oppmerksomme på unormal atferd – responsen på kommandoer, responshastigheten, hvordan skjermbildet ser ut og atferden til objekter som påvirkes av at applikasjonens tilstand endres.

Når den menneskelige testeren oppdager et avvik, kan vedkommende stanse opp, gå tilbake gjennom trinnene eller undersøke applikasjonen eller dataene nærmere før han eller hun konkluderer med om applikasjonen fungerer som den skal (eller ikke), og om den skriptbaserte testen skal fortsette, om testdataene og skriptet skal justeres, eller om testen skal fortsette som planlagt.

Mennesker er fleksible, mens verktøy bare gjør nøyaktig det du programmerer dem til å gjøre. I en skjermbasert transaksjon legger verktøyet inn data, klikker på en knapp og ser etter en melding eller et vist resultat – og det er alt. Med menneskelige testere får du så mye mer som vi tar for gitt. 

I prinsippet er det mulig å programmere et verktøy til å utføre alle kontrollene som et menneske gjør instinktivt – men du må skrive mye kode og bruke tid på å feilsøke testene dine. Selv da får du ikke menneskets evne til å avgjøre hva som skal gjøres videre – å sette på pause, fortsette, endre testen underveis eller undersøke et avvik grundigere.

Ingen steder er verktøyenes manglende fleksibilitet tydeligere enn når de reagerer på at skriptet mister synkroniseringen med systemet som testes. Kanskje samsvarer ikke et forventet resultat, systemet krasjer, eller brukergrensesnittets oppførsel (for eksempel en endret rekkefølge på felter eller et nytt felt) avviker fra det skriptet forventer. Hva gjør verktøyet? Det forsøker å fortsette, og en strøm av skriptfeil eller krasj følger. 

Ja, du kan og bør ha hendelseshåndterere for uplanlagte hendelser i skriptet ditt, slik at testfeil fanges opp. Tap av synkronisering, uoverensstemmelser mellom systemtilstand og testdata, endringer i rekkefølgen på felter, nye felter eller fjernede felter er ting testeren kan gjenkjenne og håndtere uten at testingen stopper opp. Verktøy kan ikke gjøre dette uten betydelig programmeringsinnsats fra din side.

Det finnes også ulemper ved å bruke mennesker til å følge skriptede tester. Testere kan bli besatt av å følge skriptet og glemme å bruke observasjonsevnen sin. De kan overse åpenbare avvik fordi de konsentrerer seg om å følge skriptet. Denne mindre enn optimale tilnærmingen er nøyaktig det vi får fra automatisering av testkjøring.

Blind lydighet mot testskript er en dårlig idé for menneskelige testere, men det er det beste vi kan oppnå med testautomatisering.

I denne sammenligningen av testere som følger skript, og verktøy som kjører tester, har vi ikke vurdert hva utforskende testere gjør. Den utforskende tilnærmingen gir testere frihet til å undersøke og teste hvor og hvordan de vil. 

Det er tydelig at verktøy ikke kan simulere denne aktiviteten. Enda viktigere er det at verktøy ikke kan avgrense, prioritere og modellere et systems funksjonalitet og risikoer, og utforme tester i samsvar med dette.

Testanalyse og testdesign er nødvendig uavhengig av om en test kjøres av et menneske eller et verktøy.

Det finnes flere begrensninger for hva verktøy for testkjøring kan gjøre:

• Verktøy for testkjøring gjør nøyaktig det du programmerer dem til å gjøre – verken mer eller mindre
• Verktøy utfører vanligvis ikke bygging og konfigurering av miljøer og applikasjoner eller innlasting av testdata
• Verktøy utformer ikke testtilfeller eller skript, og forbereder ikke testdata og forventede resultater
• Verktøy kan ikke ta veloverveide beslutninger når uventede hendelser oppstår.

For å optimalisere prosessene for testkjøring kan integrering med robust programvare for teststyring gi mer effektive arbeidsflyter og forbedret rapportering.

Testautomatisering av grafisk brukergrensesnitt (GUI)

Det er rundt tjuefem år siden verktøy for testautomatisering av grafiske brukergrensesnitt kom på markedet, men antallet mislykkede implementeringer av GUI-testverktøy er fortsatt høyt. Dette skyldes hovedsakelig at forventningene til automatisering settes for høyt – og verktøy som brukes uten disiplin, vil aldri innfri dem.

Verktøy for GUI-testautomatisering har rykte på seg for å være enkle å bruke som produkter, men vanskelige å administrere når applikasjonene som testes (og dermed testskriptene) må endres. Disse verktøyene er svært følsomme for endringer i brukergrensesnittet. Endringer i plassering, rekkefølge og størrelse, samt tillegg eller fjerning av skjermelementer, kan alle påvirke skriptene. Mer tekniske endringer, som å gi skjermelementer nye navn eller endre «usynlige» innebygde GUI-biblioteker, skaper også problemer.

GUI-testautomatisering fungerer best når det er disiplin rundt:

• Utviklingsprosessen og endringer og utgivelser håndteres nøye. For eksempel analyseres konsekvensene av endringer, og testere varsles. 
• Tilnærmingen til utvikling av testskript. Erfarne testautomatiseringsingeniører bruker systematiske navnekonvensjoner, katalogstrukturer, modulære og gjenbrukbare komponenter, defensive programmeringsteknikker og så videre.

Skripting for testautomatisering er en oppgave som krever mer enn grunnleggende programmeringsferdigheter og, fremfor alt, erfaring med automatisering og verktøyet som brukes. Når tester automatiseres i stor skala, er det også behov for designferdigheter. 

Uansett hvordan leverandører beskriver verktøyene – «uten skripting», «kan brukes av ikke-programmerere» eller «brukere kan også automatisere» – trenger du fortsatt en programmerers tankesett, designferdigheter og en systematisk tilnærming.

Testautomatisering av API-er og tjenester

Når komponenter eller funksjonalitet er distribuert som tjenester som kalles av tynne klienter eller mobilklienter, utføres testingen ved hjelp av et API eller via tjenestekall. Denne testformen utføres enten ved hjelp av egendefinert kode skrevet av utviklere eller ved hjelp av dedikerte verktøy for API- eller tjenestetesting. Uansett er den vanlige tilnærmingen å automatisere testingen på den ene eller andre måten.

Fordi API-et er «nærmere» koden som skal testes, kan testene være mye mer fokuserte på funksjonaliteten som skal testes. Kompleksiteten ved navigering gjennom brukergrensesnittet og selve testingen gjennom brukergrensesnittet kan naturligvis omgås. Derfor er den generelle regelen:

Hvis funksjonaliteten som testes (på kode- eller komponentnivå) kan testes med et funksjonskall, et API-kall eller et tjenestekall, blir automatisering enklere – og anbefales.

Testing gjennom API-et har klare fordeler.

• Selv om du må bruke eller skrive kode, blir selve testene mye enklere å gjennomføre (det er ikke noe brukergrensesnitt å ta hensyn til).
• Når et API-kall er skriptet, er det bare å sette opp en oversikt over testtilfellene du ønsker å bruke. Det er ingen grense for hvor mange tester du kan gjennomføre.
• API-baserte tester kjøres vanligvis mye raskere, noe som gjør denne testformen godt egnet for tilnærminger basert på kontinuerlig levering, der distribusjonsprosessen er sterkt automatisert og må reagere raskt.

«Pyramiden for testautomatisering» (et Google-søk vil vise hundrevis av eksempler på illustrasjonen) er nesten universelt tatt i bruk for å presentere anbefalingen om at arbeidet med testautomatisering bør fokusere mer på utvikler- eller API-testing enn testing gjennom det grafiske brukergrensesnittet.

• Bruk tester av brukergrensesnittet når brukerflyten må gjennomgås, men i begrenset omfang fordi testene er kostbare og kan ta lang tid å kjøre.
• Bruk API- eller tjenestekall når funksjonaliteten som testes kan isoleres, og når hastighet og enkel automatisering er avgjørende.

Regresjonstesting

Den klassiske bruken av automatiserte verktøy er gjennomføring av regresjonstester. Disse testene kjøres én gang og anses som nøyaktige representasjoner av forventet atferd. Når enten applikasjonskoden som testes, tilknyttede gjenbrukbare biblioteker eller testmiljøet endres, gir disse testene en viss trygghet for at den nødvendige funksjonaliteten ikke er blitt negativt påvirket av endringen.

Du kan se for deg de automatiserte testene som en form som systemet som testes skal passe inn i. Testene bør naturligvis «bestå» alle kontrollene som tidligere ble gjennomført. Ved å kjøre dem på nytt forsøker du å vise funksjonell ekvivalens mellom den nye programvareversjonen og den forrige. Det er noen enkle prinsipper du må følge:

• For det første må testene og kontrollene som gjennomføres, velges slik at du får tillit til at uønskede endringer i atferd ikke er til stede. Disse testene fungerer som en «snubletråd» som oppdager forskjeller i atferd.
• Når feil rettes eller andre programvareendringer gjøres, kan det finnes tilfeller der atferd er endret (på riktig måte), men som vil føre til at en kontroll mislykkes når de oppdages av testene dine. Du må enten endre testene på forhånd eller la dem mislykkes og korrigere dem etterpå. Noen ganger går det raskere å fjerne mislykkede tester helt og opprette nye tester fra grunnen av for å erstatte dem. Uansett må disse endrede testene deretter kjøres til de er fullført og består.
• Hvis systemet som testes ikke er stabilt, har mange feil eller gjennomgår omfattende endringer mellom utgivelser, er det kanskje ikke økonomisk gjennomførbart å vedlikeholde et sett med automatiserte tester. Selv om systemfunksjonaliteten ikke endres, kan det hende at brukergrensesnittet fortsatt er under utvikling – et ustabilt brukergrensesnitt gjør også automatisering vanskeligere å vedlikeholde. Kostnadene ved å undersøke testfeil og vedlikeholde testene kan overstige nytten. Det kan være klokt å teste de mindre stabile delene av systemet manuelt til de stabiliserer seg.

Testing gjennom brukergrensesnittet kan noen ganger være tungvint, kostbar og tidkrevende å gjennomføre. Før du setter i gang med testautomatisering av det grafiske brukergrensesnittet, eller automatiserer et enkelt skript, bør du vurdere om det ville være enklere, raskere og mer kostnadseffektivt å teste nøkkelfunksjonaliteten ved hjelp av et API.

Den klassiske bruken av automatiserte verktøy er gjennomføring av regresjonstester. For å sikre at du bruker de mest effektive verktøyene til dette, kan du se vår liste over de beste verktøyene for programvaretesting

Rammeverk for testautomatisering

Test-rammeverk er en viktig del av enhver vellykket automatisert testprosess. Se på dem som et sett med retningslinjer for oppretting og utforming av testtilfeller. Bruk av dem kan øke testteamets hastighet og effektivitet, forbedre testnøyaktigheten, redusere risiko og senke kostnadene ved testvedlikehold. Nå skal vi se nærmere på to av dem.

Når man diskuterer rammeverk for testautomatisering, er det viktig å ta hensyn til rollen til verktøy for QA-automatisering i utformingen av en effektiv teststrategi.

Rammeverk for enhetstesting

Rammeverk for enhetstesting har eksistert i flere år og brukes i stor utstrekning av programmerere til å teste koden sin. Utviklertester har en tendens til å være ganske avgrensede – de tester tross alt vanligvis én enkelt komponent, mens grensesnitt mot andre komponenter eller databaser simuleres eller erstattes med stubber. Selv om enhetstester derfor trenger oppsett og opprydding før og etter at testene kjøres, er disse oppgavene vanligvis begrenset til testing av én enkelt komponent. Det finnes separate testpakker for hver komponent.

Enhetstester som utviklere oppretter, er vanligvis versjonskontrollerte og håndteres parallelt med komponentkoden. Vanligvis tar verktøy for kontinuerlig integrasjon kildekoden og alle enhetstestene og kjører dem etter hver innlasting av ny kode og/eller nye tester. Alle utviklere ser resultatet av disse testene, så en testfeil i CI blir svært synlig. Å rette feilende tester og kode har høy prioritet i team som bruker CI på denne måten, slik at den nyeste versjonen av systemet alltid består alle CI-testene.

Rammeverk for automatisering av integrasjons- og systemtester

De siste årene har GUI-testverktøy blitt integrert med CI-verktøy ved hjelp av virtualiserte testenheter, miljøer og kjøring gjennom kommandolinjegrensesnitt. Mange organisasjoner har klart å integrere kjøringen av enhets-, API-tester og GUI-tester fullstendig gjennom CI-tjenester.

Mange testteam drifter imidlertid fortsatt sine egne testmiljøer separat fra utviklings- eller CI-tjenester. Disse teamene har en tendens til å bygge sine egne rammeverk for testautomatisering fordi CI-verktøy er for utviklerorienterte, eller fordi proprietære verktøy er utilstrekkelige.

GUI-tester implementerer ofte ende-til-ende-tester eller brukerreiser ved hjelp av ulike applikasjoner, maskinvareenheter og miljøer. Disse testene må sømløst sette opp integrerte testmiljøer og klargjorte testdata på forskjellige plattformer, og dette krever privilegerte, komplekse prosedyrer og varierte tekniske miljøer for å kunne kjøre. Det store flertallet av team som bruker GUI-testautomatisering, bygger sine egne unike, men effektive, rammeverk for automatisering.

Rammeverk for GUI-automatisering varierer i sofistikering fra verktøy som ligner enhetstestverktøy, til komplekse og omfattende løsninger som kreves for å håndtere miljøer, applikasjonsbygginger, enorme mengder testdata, meldinger og synkronisering på tvers av plattformer og miljøer, samt meldinger og varsler til teammedlemmer.

Noen proprietære verktøy leveres med verktøy eller testkjøringsrammeverk for å håndtere, kjøre og rapportere fra suiter med automatiserte tester. Disse har varierende verdi, så mange organisasjoner skriver sine egne rammeverk for testautomatisering for å utvide funksjonaliteten. De siste årene har omfanget av rammeverk for automatisering vokst, og det finnes ikke lenger én enkelt eller enkel definisjon. Derfor skal vi nå se på hva rammeverk for testautomatisering kan gjøre for programvareteam.

Et rammeverk for testautomatisering utvider funksjonaliteten til motorer for testkjøring.

Konfigurering av testpakker

Rammeverket integrerer automatiserte tester i meningsfulle samlinger eller klynger av tester. Disse samlingene kan konfigureres slik at tester kan kjøres i et hierarki av sekvenser, grupper eller vilkårlige utvalg. Disse verktøyene kan inneholde funksjoner for datadrevne tester ved hjelp av klargjorte tabeller med testdata. Dette er den enkleste typen rammeverk — populære verktøy tilbyr vanligvis en form for konfigurering av testpakker.

Oppsett og nedrigging

Rammeverket håndterer alle oppsetts- og nedriggingsaktiviteter for én enkelt test, en samling eller en hel testpakke. Oppsett kan innebære å opprette testmiljøer fra grunnen av, fullstendige konfigurasjoner og forhåndslaste testdatabaser og andre datakilder fra grunnen av. Nedrigging kan innebære opprydding i testdata eller tilbakestilling eller sletting av delvise eller fullstendige miljøer. Rammeverket kan integreres med, og være underlagt kontroll av, verktøy for orkestrering av prosesser.

Håndtering av unntak

En feil i en hvilken som helst test – enten i systemet som testes eller som følge av manglende synkronisering – kan håndteres konsekvent ved å rapportere hendelsen og vanligvis tillate at de resterende testene i samlingen fortsetter å kjøre. Rammeverket kan programmeres til å håndtere feil i testsjekker, manglende synkronisering, tidsavbrudd under kjøring og andre utvalgte testresultater – hvert med tilpassede prosedyrer.

Logging og meldinger

Rammeverket logger testkjøring og kjøringsstatus konsekvent på tvers av alle testsamlinger. Rammeverket utløser enten rapporter fra verktøyene som kjører testene, eller tilbyr en konsekvent rapporteringsjournal for alt testoppsett, all testkjøring og all nedriggingsaktivitet. Rammeverket kan samhandle med ChatOps-boter for å informere teamet om unntak og la teammedlemmer sette testpakker på pause, stoppe dem, gjenta dem eller starte dem på nytt.

Testabstraksjon med domenespesifikt språk

To ulike typer rammeverk som abstraherer testkjøringskode til modeller eller menneskelesbar eller ikke-teknisk tekst, har vokst frem i markedet:

• Nøkkelorddrevne rammeverk gjør det mulig å definere tester ved hjelp av nøkkelord. Kall til funksjonene i kjøringsmotoren implementeres som engelsklignende kommandoer med plassholdere for parametere eller data. Brukerdefinerte, gjenbrukbare moduler kan defineres og kalles ved hjelp av tekstkommandoer på samme måte. Det finnes rammeverk for alle slags grensesnitt, inkludert GUI, tjenester, API-er, kommandolinjetolker og så videre. Skript kan teste funksjonalitet på tvers av ulike operativsystem- og enhetsplattformer.
• Rammeverk for atferdsdrevet utvikling (BDD) gjør det mulig å registrere historier og scenarier (eksempler) som beskriver funksjonsatferd, ved hjelp av et domenespesifikt språk (DSL). Det mest populære språket er det såkalte Gherkin, som bruker språkstrukturen «gitt … når … så …» til å registrere eksempler. Gitt/når/så representerer effektivt forhåndsbetingelser, trinn og etterbetingelser for testtilfeller. BDD-verktøy konverterer gitt/når/så-teksten til «trinnkall» i et programmeringsspråk. Utvikleren (eller testeren) må implementere «testfiksturene» eller koden som foretar kall til en testkjøringsmotor. På denne måten kan språket i et krav (historien) kobles direkte til tekstkjøringskoden.

Modellbaserte rammeverk

I dette tilfellet gjør verktøy det mulig å opprette en modell av systemet som testes. Dette kan utledes automatisk fra en nettside, der verktøyet skanner HTML-en, oppdager skjemaer og felt og bygger en modell som testeren enten kan bruke til å generere stier gjennom skjemaene automatisk eller velge manuelt. Objektkart for mobilapper eller andre smarte enheter kan også bygges manuelt. Ved å bruke stiene gjennom objektkartet utføres kall til funksjonene i testkjøringsmotoren på en lignende måte som med BDD- og nøkkelordstyrte verktøy. I prinsippet kan tester bygges grafisk uten kode. Verktøy på dette området er relativt nye og forbedres raskt. Forvent at bruken av dem vil øke i fremtiden.

Meld deg på nyhetsbrevet fra The QA Lead for å få beskjed når nye deler av serien publiseres. Disse innleggene er utdrag fra Pauls kurs i ledelse innen testing, som vi på det sterkeste anbefaler hvis du ønsker å gå dypere inn i dette og andre emner. Hvis du gjør det, kan du bruke vår eksklusive kupongkode QALEADOFFER og få $60 rabatt på full kurspris!

Relatert lesning: 10 BESTE VERKTØY FOR OVERVÅKING AV NETTSERVERE