Målet for enhver tester er å ha tillit til programvaren gjennom kontinuerlig testing. Vi kan sove bedre om natten når vi vet at brukerne vil oppleve færre feil i produktene fordi det finnes en omfattende testprosess. Å velge riktige teststrategier er minst like viktig som å teste nok.
En gang fikk jeg i oppgave å lage en testplan for en kompleks nettverksenhet. Målet var å oppnå 100 % dekning av ulike tilkoblinger og kombinasjonene av dem. En rask beregning viste at det ville ta mer enn 40 000 år å sette opp og gjennomføre slike tester.
Jo mer komplekse systemene dine er, desto viktigere er det å finne en teststrategi som både er gjennomførbar og vellykket.
To testperspektiver og tilnærminger til testing som nylig har dukket opp ofte, er kjent som ende-til-ende-testing og regresjonstesting.
Formålet med regresjonstesting er å bekrefte at det som fungerte i går, fortsatt fungerer i dag etter eventuelle endringer.
Ved ende-til-ende-testing tester man en forretningsprosess som helhet, derav «ende til ende».
Det er en vanlig misforståelse å betrakte disse to strategiene som det samme, fordi regresjonstesting ofte også innebærer ende-til-ende-testing. Det ville imidlertid være en feil å anta at ende-til-ende-testing bare er regresjonstesting.
Regresjonstesting bør foregå på alle testnivåer, med utgangspunkt i enhetstestene. Ende-til-ende-testing omfatter regresjonstesting, men det er sjelden mulig å teste ende til ende på de lavere testnivåene fordi alle involverte deler av prosessen må være på plass for at den skal kunne testes som en helhet.
Hver testtype har et tydelig og forskjellig formål. Hver av dem har sitt eget sett med fordeler, utfordringer og egenskaper som gjør dem unike for ulike programvaremål.
Når vi først snakker om enhetstesting, kan du se anbefalingene våre for de 10 beste verktøyene for enhetstesting.
Ende-til-ende-testing: Hva det er – og hva det ikke er
Ende-til-ende-testing betyr å teste en arbeidsflyt fra start til slutt. Mange arbeidsflyter eller forretningsprosesser går i dag på tvers av flere applikasjoner og systemer. Derfor er det ikke sikkert at de tradisjonelle konseptene for applikasjonstesting eller systemtesting alene er tilstrekkelige lenger.
Ende-til-ende-testing måler funksjonaliteten og ytelsen til forretningsprosessen. På grunn av testens natur er det ikke alltid mulig å gjennomføre ende-til-ende-testing i et vanlig testmiljø. I stedet er det ofte nødvendig med et simulert miljø eller et reelt miljø etter lansering.
Ende-til-ende-tester identifiserer hovedsakelig problemer, avhengigheter og integrasjonsproblemer.
Denne typen testing kan høres ut som brukergodkjenningstesting (UAT), fordi den gjør det mulig for testere å gjenskape sluttbrukeratferd, for eksempel ved å speile en transaksjon gjennom et nettsted, en vanlig forretningsprosess for forbrukere. I moderne utvikling med raske sykluser må imidlertid ende-til-ende-testing være en kontinuerlig aktivitet, ikke bare en innsats for brukergodkjenning.
Når man gjennomfører ende-til-ende-testing, er det avgjørende å simulere et miljø fra den virkelige verden, noe som ofte inkluderer interaksjoner med databaser. For en sømløs opplevelse bør du vurdere å bruke førsteklasses programvare for databaseadministrasjon.
Have an account? Log In
Fordelene og utfordringene ved ende-til-ende-testing
De fleste virksomheter i dag kjører både i og utenfor skyen, noe som gir gode grunner til å overvåke integrasjoner nøye. Vanligvis egner ende-til-ende-testing seg godt for heterogene systemer, fordi den gjør det mulig å kontrollere hvert enkelt system og lag, fra applikasjonens front-end og back-end til databasen.
Likevel er det her vi møter utfordringen: Testere må opprette og kjøre mange langvarige og repetitive tester, noe som er svært arbeidskrevende. En større testpakke betyr at vedlikehold krever mer tid og innsats. Testere som arbeider med ende-til-ende-testing, bruker ofte svært mye tid på å opprette og vedlikeholde testmiljøer.
Siden ende-til-ende-testing har som mål å etterligne brukerinteraksjoner, kan den ikke utføres utelukkende i utviklingsmiljøet. Produksjonsmiljøet er imidlertid ikke alltid tilgjengelig og kan være utsatt for avbrudd i testingen, for eksempel på grunn av programvareoppdateringer.
Storskala testautomatisering blir nødvendig for ordentlig ende-til-ende-testing. Testerne bør konsentrere innsatsen om å utforme tester og analysere testresultatene, i stedet for å vedlikeholde eksisterende tester og konfigurere verktøy og miljøer. En plattform for testautomatisering som reduserer vedlikeholdsbelastningen, automatiserer testoppsettet og støtter parallell testkjøring, kan spare mye arbeid og enda mer tid.
Regresjonstesting
Regresjonstesting tas i bruk når systemet har gjennomgått endringer. Alle som har jobbet med programvaretesting, vet at endringer på ett sted kan føre til funksjonsfeil et annet sted.
Du vil se regresjonstesting utført i praksis etter alle disse scenariene: tillegg av nye funksjoner, feilrettinger, oppdateringer eller nye versjoner. Testere kan utføre et delvis eller fullstendig utvalg av eksisterende testtilfeller.
Se for deg dette eksempelet:
Se for deg en forretningsprosess som starter med at en forbruker kjøper noe ved hjelp av en mobilapp. Forretningsprosessen kan være styrt av en Salesforce-applikasjon, betalingen kan gjennomføres av et eksternt betalingsbehandlingssystem, og selve bestillingen kan behandles i en SAP-applikasjon. Noen trinn i prosessen kan involvere mennesker.
Utviklerne av de involverte applikasjonene kan utvikle sine deler uavhengig av hverandre, kanskje til og med uten å kjenne til hverandre. En forbedring i én applikasjon kan føre til et inkompatibilitetsproblem i en annen. Det er her ende-til-ende-testing og regresjonstesting møtes på en svært meningsfull måte.
More Articles
Automatisering av regresjonstester i leveransepipen
Regresjonstesting gjør en CI/CD-pipeline komplett fordi den evaluerer systemets stabilitet ved hver endring. Ingen liker å måtte gjøre om arbeid og oppdage at noe er gjort feil etter at programvaren allerede er lansert.
Men disse fordelene kommer med utfordringer, spesielt når programvaren vokser sammen med virksomheten din. Gamle testtilfeller vil bli kjørt sammen med nye testtilfeller, noe som fører til at testseriene vokser og testsyklusene blir lengre. Automatisering, og etter hvert AI vil bidra til testkjøring, vedlikehold og analyse.
Ende-til-ende-testing vs. regresjonstesting: Hva er riktig for virksomheten din?
Svaret er begge deler. Du må ikke velge mellom ende-til-ende-testing og regresjonstesting.
I stedet må du avgjøre hvor mye ende-til-ende-testing du trenger å utføre, hvor mye av dette som bør være regresjonstesting, og hvor mye som bør være testing av nye funksjoner.
Som nevnt ovenfor har ende-til-ende-testing en tendens til å være treg og kreve komplekse testoppsett. Det er avgjørende å bruke automatisering for å redusere gjennomføringstidene.
Men på grunn av ende-til-ende-testingens komplekse natur må automatiseringen bygges slik at tiden og innsatsen som kreves for å vedlikeholde den, ikke spiser opp fordelene som oppnås.
Et stort problem testere har stått overfor, er at repetitiv testing med store testserier i et heterogent miljø betyr lange testsykluser og en arbeidskrevende prosess. Men det finnes ingen vei rundt det.
Digitale forretningsprosesser fortsetter å vokse både i omfang og kompleksitet. Et godt testteam med riktige, moderne automatiseringsverktøy kan virkelig bidra til virksomhetens suksess. Vi hører også at team opplever at de trenger å bruke ulike verktøy for å teste forskjellige apper, så det kan være nyttig å finne ett som tester flere scenarier.
Du vil kanskje også like: De 10 beste verktøyene for visuell regresjonstesting for QA-team
