Moderne programvare er i stadig endring. Dette gjelder spesielt når man arbeider i et smidig miljø, der lanseringer skjer svært ofte, noen ganger til og med som kontinuerlig levering. Nye funksjoner legges stadig til, eksisterende funksjoner endres, og feil rettes. Og dette er selvfølgelig en god ting.
Men samtidig er risikoen for å ødelegge eksisterende funksjonalitet som fungerer, relativt høy. Derfor trenger vi regresjonstesting. Kort sagt er regresjonstesting en teknikk som validerer at nye endringer i koden ikke har introdusert nye feil.
Jeg skal diskutere regresjonstesting, en kritisk praksis innen kvalitetssikring, mer detaljert nedenfor.
Hva er regresjonstesting?
Regresjonstesting er en viktig del av programvareutviklingens livssyklus. Det er en type testing som utføres for å sikre at kodeendringer ikke har påvirket eksisterende funksjonalitet, og at det som fungerte før endringene, fortsatt fungerer. Eventuelle problemer som oppdages under denne prosessen, regnes som regresjonsfeil og bør behandles med høy prioritet.
Regresjonstesting kan utføres både manuelt og gjennom automatiserte tester. Det er en god idé å automatisere regresjonstestpakken, spesielt når man arbeider med store applikasjoner, der hele regresjonsprosessen kan være svært tidkrevende.
Hvorfor er regresjonstesting viktig i programvareutvikling?
Når ny kode legges til i kodebasen, enten det gjelder en feilretting eller ny funksjonalitet, kan den påvirke kode som allerede fungerer, ved å introdusere nye feil eller påvirke ikke-funksjonelle aspekter ved applikasjonen, for eksempel ytelse eller brukervennlighet.
Dette kan føre til ulemper for sluttbrukeren, som sannsynligvis ikke blir særlig fornøyd med at noe som pleide å fungere, ikke fungerer lenger. Dette kan igjen føre til inntektstap og ha stor innvirkning på selskapets omdømme.
Regresjonstesting bidrar til å oppdage disse feilene tidlig og til at en løsning er på plass før man går over til produksjon. Dette betyr at kundene får se en mer stabil versjon av applikasjonen, uten at den gamle funksjonaliteten de allerede brukte, påvirkes.
Have an account? Log In
Valg av testtilfeller
Det første testerne må gjøre før regresjonen starter, er å identifisere regresjonstesttilfellene som skal utføres. Det finnes to hovedmetoder for valg av testtilfeller: reaktiv og proaktiv.
Reaktiv
Ved reaktivt valg av testtilfeller iverksetter kvalitetssikringsteamet tiltak etter endringen. Dette betyr at testtilfellene som skal utføres, velges etter at utviklingsteamet har gjort endringene i koden.
Proaktiv
Ved en proaktiv tilnærming forutser testerne mulige endringer før utviklingsendringene gjøres, og utarbeider testplanen deretter. Valget mellom disse to metodene avhenger av bestemte faktorer, blant annet kostnad, kompleksitet, dekning og tidsbegrensninger.
Prioritering av testtilfeller
Prioritering av testtilfeller er sannsynligvis et av de viktigste trinnene i utformingen av en regresjonsplan. Det bidrar til effektiv tidsstyring og forbedrer feildeteksjonsraten. Det første man må gjøre, er å forstå hvilke områder som er mest berørt av de siste endringene, samt avgjøre hvor mye tid teamet har til å utføre regresjonstestingen. Som et av de kjente testingsprinsippene sier: «Uttømmende testing er umulig», noe som betyr at vi ikke kan dekke alle eksisterende testscenarier og grensetilfeller, men vi kan sikte mot den beste testdekningen vi er i stand til å oppnå.
Med dette i tankene må testerne foreta en risikovurdering – avgjøre hvilke områder som er mest kritiske å teste, og hvilke som mest sannsynlig vil føre til problemer. Når det gjelder testingsprinsipper, bør man huske at feil har en tendens til å samle seg, det vil si at et område med problemer har større sannsynlighet for å avdekke flest feil. Når det gjelder regresjonstesting, vil dette være områdene som er endret.
En annen ting man bør vurdere, er om vi bruker testautomatisering eller ikke. Den automatiserte testkjøringen kan kjøres uavhengig, og testerne kan konsentrere seg mer om erfaringsbasert testing, som utforskende testing og ad hoc-testing, samt om deler som ikke kan automatiseres, for eksempel å sikre at brukeropplevelsen ikke har blitt forringet på noen måte.
Etter hvert som programvaren endres, er det også viktig å oppdatere eksisterende testtilfeller slik at de gjenspeiler de nye endringene, eller merke utdaterte testtilfeller tilsvarende, slik at de ikke utføres ved en feil.
Teknikker og verktøy for effektiv regresjonstesting
| Teknikken med full retesting | Selektiv teknikk | Prioriteringsteknikk |
|---|---|---|
| Teknikken med full retestingOgså kjent som fullstendig regresjonstesting er dette den mest grundige teknikken for regresjonstesting. Den innebærer at alle funksjoner i programvaren testes på nytt etter enhver endring. Målet er 100 % testdekning, og det krever at alle eksisterende tester kjøres på nytt, samt at nye testtilfeller utføres. Denne teknikken egner seg hovedsakelig for automatisert regresjonstesting dersom det meste av testpakken er automatisert. Det er den sikreste teknikken, men den er ikke særlig effektiv ved manuell testing, siden det kan ta lang tid å gå gjennom hele regresjonstestpakken. | Selektiv teknikk Dette er en delvis teknikk for regresjonstesting, der teamet bare tester funksjonene som påvirkes av de endrede delene av koden, på nytt. Dette er nært knyttet til utvelgelse av regresjonstester. Et regresjonstestsett opprettes ved å velge eksisterende og nye tester som er relatert til områdene der det er lagt til rettelser og forbedringer. Disse testtilfellene prioriteres også basert på risikoen og viktigheten av funksjonalitetene. | PrioriteringsteknikkDette er en testtilnærming der funksjonene testes basert på deres betydning og innvirkning på programvarens samlede funksjonalitet. Testteamet gjennomgår programvarens kjernefunksjoner og sørger for at de testes grundig. Ideen bak denne teknikken er å sikre at de viktigste delene av applikasjonen ikke har blitt påvirket. Det er likevel ikke en særlig effektiv teknikk, fordi den ikke fokuserer på områder som har blitt endret, og krever mye retesting av ting som vanligvis ikke kan ha blitt endret siden de sist ble testet. |
Rollen til automatisering i regresjonstesting
Når det gjelder testautomatisering, er det viktig å ta hensyn til pyramiden for testautomatisering. Denne viser at størstedelen av testene bør være enhetstester, som er raskere å kjøre og derfor kan identifisere feil raskere. Deretter kommer integrasjonstestene (eller API-testene), som er færre i antall, men som likevel utgjør et stort antall tester som skal kjøres.
På det øverste laget tar UI-testene fra ende til ende lengst tid å kjøre, og det bør være færre av dem enn på de andre nivåene.
Ved å bruke automatiserte testskript kan hele regresjonsprosessen optimaliseres. Testtilfeller kjøres raskere, og feil identifiseres raskt, med svært lite menneskelig innblanding. De automatiserte testene kan kjøres hver gang det gjøres endringer i kildekoden, og basert på testresultatene kan testerne finne ut hvilke områder som er mest berørt, og undersøke disse områdene grundigere gjennom manuell testing.
Eksplorativ testing er alltid en god måte å komplettere automatisering på, fordi det er en type testing som ikke kan automatiseres, og testernes erfaring kan tilføre mye verdi ved å identifisere mer uvanlige scenarioer.
Verktøy for regresjonstesting
Utviklingsteamet håndterer vanligvis de to første lagene i pyramiden, så i denne delen skal vi se nærmere på noen av de mest populære verktøyene for UI-automatisering som kan bidra til å automatisere testprosessen.
| Selenium | Appium | JMeter | Katalon |
|---|---|---|---|
| SeleniumEt åpen kildekode-verktøy for automatisering av nettlesere, som vanligvis brukes til testautomatisering av nettapplikasjoner. Det er tilgjengelig i flere programmeringsspråk, blant annet Java, Python, JavaScript og C#, og fungerer på alle operativsystemer og vanlige nettlesere. Testerne som oppretter skriptene, må imidlertid ha kunnskap om programmering. | AppiumAppium er mobilmotsvarigheten til Selenium – et testrammeverk utviklet for testing av mobilapper. Det er også tilgjengelig i flere programmeringsspråk og fungerer på både Android og iOS. | JMeterJMeter er også et åpen kildekode-verktøy og kan brukes til funksjonstesting, men det er spesielt kraftig når det gjelder funksjoner for ytelsestesting. Det er et godt verktøy når du trenger å utføre belastnings- eller stresstesting av applikasjonen din og sammenligne resultatene (med resultatene fra før kodeendringene) for å se om ytelsen har blitt påvirket på noen måte. | KatalonKatalon er et verktøy for programvaretesting av nett-, mobil-, API- og skrivebordsapplikasjoner. Det tilbyr også funksjoner for opptak og avspilling, så det fungerer godt i team der testerne ikke nødvendigvis også er programmerere |
Listen kan selvsagt utvides, siden det finnes mange tilgjengelige verktøy for automatisert testing på markedet, og valget ditt vil avhenge av prosjektets og teamets spesifikke behov.
Utfordringer ved implementering
Selv om regresjonstestprosessen er en integrert del av utviklingssyklusen, medfører den også utfordringer.
- Tidsbegrensninger: Tid er sannsynligvis den vanligste utfordringen med regresjonstesting. Fordi regresjonstestpakken blir større og større etter hvert som nye moduler legges til i koden, kan den ta mye tid, noe teamet ikke alltid har tilgjengelig. Mer tid brukt på regresjonstesting kan også øke kostnadene.
- Vedlikehold: Når den eksisterende koden endres for å legge til ny funksjonalitet og forbedringer, bør også testtilfellene vedlikeholdes. Dette gjelder manuelle og automatiserte tester, fordi alle eksisterende testscenarioer bør gjenspeile de nye kravene.
- Prioritering: Et av de viktigste trinnene i regresjonstesting. Teamet må sørge for at de, med tanke på tiden som er tilgjengelig for å gjennomføre regresjonstesting, velger riktige testtilfeller og skript for å maksimere testdekningen samtidig som størrelsen på testpakken minimeres.
More Articles
Effekten av effektiv regresjonstesting på produktkvaliteten
Til tross for utfordringene har regresjonstesting, når den utføres riktig, stor innvirkning på programvarekvaliteten.
For det første sørger teamet for at nye feil ikke introduseres etter at ny funksjonalitet er lagt til i applikasjonen, ved hjelp av regresjonstesting.
Dette har en kaskadeeffekt på kodekvaliteten og den overordnede kvaliteten på systemet som testes.
Færre feil i produksjon betyr også større kundetilfredshet og en bedre kundeopplevelse.
Viktige punkter
Regresjonstesting er en integrert del av teststrategien i enhver vellykket utviklingsprosess. Den bidrar til å sikre at nylig tilføyde funksjoner og feilrettinger ikke påvirker den eksisterende fungerende koden, og at systemet oppfyller standardene for å bli satt i produksjon.
Med riktig prioritering av testtilfeller og hjelp fra automatiseringsverktøy kan regresjonsprosessen være en svært effektiv måte å minimere risikoen for å ødelegge noe som tidligere fungerte. Dette bidrar igjen til å gi sluttbrukeren en god brukeropplevelse.
Hvis du vil lese mer om regresjonstesting og alt som gjelder testing, kan du abonnere på QA-leder-nyhetsbrevet!
