Programvaretesting er et håndverk. En programvaretester skal, i likhet med en håndverker, ha en grundig forståelse av verktøyene for programvaretesting som er tilgjengelige. Vi har satt sammen en liste over 9 ulike typer programvaretesting og verktøyene som brukes til hver type, for å hjelpe QA-analytikere og alle andre som arbeider innen programvaretesting, med å forstå håndverket sitt bedre.
Hvorfor trenger vi programvaretesting?
Noen ganger er det viktig å bli minnet på hvorfor det du gjør, betyr noe. Det enkle faktum er at all programvare som noen gang er utviklet og har oppnådd suksess, har gjort det med hjelp fra programvaretestere som har arbeidet utrettelig for å sikre at produktet holder en så høy standard som mulig. Her er tre grunner til at programvaretesting er viktig.
- Kundetilfredshet: Når man utvikler et prosjekt, kan det være lett å gå seg vill i kodens skog og glemme at brukeren også må være fornøyd med hvordan programvaren fungerer. QA-analytikere og andre QA-medlemmer ivaretar denne rollen.
- Produktkvalitet: Alle yrker der et team eller en enkeltperson lager noe fra grunnen av, krever et annet team som kan oppdage feilene deres. Forfattere trenger redaktører. Filmregissører trenger også redaktører. Programvareutviklere trenger ikke redaktører, men de trenger et QA-team som kan gi et objektivt perspektiv og oppdage eventuelle feil.
- Sikkerhet: For hver dag som går, virker dette punktet stadig viktigere. Kundene ønsker trygghet i vissheten om at informasjonen de legger inn i programvaren, og arbeidet de utfører i den, forblir privat. En del av QA-arbeidet er å sørge for at kundene har denne tilliten.
Metoder for programvaretesting
Alle typene programvaretesting som er nevnt i denne artikkelen, tilhører én av to hovedkategorier: statisk testing og dynamisk testing. Før vi utforsker de spesifikke detaljene ved de ni ulike teknikkene for programvaretesting, skal jeg forklare forskjellen mellom disse to metodene og hvordan de inngår i programvareutviklingssyklusen.
Statisk testing
Statisk testing er en type programvaretesting som utføres tidlig i utviklingssyklusen. Det er en kostnadseffektiv måte å finne feil på før de blir store problemer for utviklingsteamet. Statiske tester kjøres tidlig i utviklingssyklusen fordi de kan utføres uten at man har fullt fungerende programvare. Ja, programvaren kan feilsøkes før den engang er i nærheten av å være ferdig. Ser du hvordan det kan være nyttig?
Statiske tester utføres på to måter:
- Manuelle undersøkelser: Koden analyseres av en QA-analytiker eller tester.
- Automatisk analyse: Et testverktøy kontrollerer programdokumentet automatisk og registrerer eventuelle feil.
Statisk testing er:
- Utført uten å kjøre kode.
- Kostnadseffektiv.
- Nyttig for å sikre at programvaren oppfyller verifikasjonsspesifikasjonene.
- En måte å fastslå den grunnleggende årsaken til feil på.
De fleste statiske tester gjennomføres i form av dokumentgjennomganger. I dette scenariet er et dokument enten en skriftlig beskrivelse av et produkt (kjent som et programvaredesigndokument) eller programmets kildekode. Her er noen teknikker for statisk testing som alle QA-analytikere bør kjenne til:
- Uformell gjennomgang: Det finnes ingen strenge retningslinjer for den uformelle gjennomgangen. Teamet ser over testdokumentene og kommenterer det de ser. Det finnes ingen dokumentasjon.
- Gjennomgang: Forfatteren av koden går gjennom dokumentet sitt, og QA-teamet stiller spørsmål og tar opp bekymringer. Gjennomganger er vanligvis svært uformelle og en god måte å diskutere temaer med personer utenfor programvarefeltet på.
- Teknisk gjennomgang: Tekniske eksperter samles for å gjennomgå de tekniske spesifikasjonene for koden. Ved å gjøre dette tidlig i utviklingsprosessen sikrer man at sluttproduktet oppfyller de nødvendige spesifikasjonene.
- Inspeksjoner: Den mest formelle av alle gjennomganger. Et team med opplærte moderatorer inspiserer dokumentene grundig under møtet. Alle feil som oppdages, dokumenteres og loggføres formelt for gjennomgang. Det gjennomføres en oppfølging for å kontrollere at de dokumenterte feilene er håndtert.
I de fleste tilfeller er gjennomganger av statisk testing nyttige fordi hele QA-teamet analyserer produktet og foreslår endringer basert på problemer de ser, og problemer som kan forutses. I tillegg til fordelen ved å få en rekke ulike synspunkter med i samtalen, bidrar dette også til at alle teammedlemmene blir oppdatert på prosjektets fremdrift og utforming.
Bruk statisk testing hvis teamet ditt:
- Er tidlig i utviklingsprosessen.
- Ser etter en kostnadseffektiv måte å finne feil på.
- Har programvare som ikke er klar til å kjøres.
- Vil oppdage feil tidlig i utviklingen.
Have an account? Log In
Dynamisk testing
I motsetning til statisk testing er dynamisk testing en type programvaretesting som krever at kode kjøres. Dette krever naturligvis at utviklingen har kommet lenger i produksjonssyklusen. Fordelen med å teste kjørbar kode er at QA-analytikere kan se på hvordan programvaren fungerer mens den kjører i en virkelig situasjon. Dette er en god måte å kontrollere programvarens funksjonelle atferd og andre ting, som CPU-bruk. Dynamisk testing kontrollerer at det forventede resultatet samsvarer med resultatet i virkeligheten. Hovedmålet med dynamisk testing er å bekrefte at produktet oppfyller design- og funksjonskravene som ble fastsatt før prosjektet startet.
Vanligvis inngår det fire trinn når systemprogramvare testes dynamisk, som QA-analytikere bør kjenne til:
- Enhetstesting: Når programvare testes på enhetsnivå, deles den opp i de minste mulige komponentene og testes individuelt. Ved å teste på denne måten kan QA-analytikere være trygge på at hver enkelt del av programvaren fungerer som tiltenkt. Hvis en feil oppdages, er det enklere å rette den på dette utviklingsstadiet, fordi de raskt kan isolere problemkoden. Vanligvis begynner QA-teamet med enhetstester når det starter med dynamisk testing (selv om dette teststadiet noen ganger håndteres av utviklingsteamet).
- Integrasjonstesting: Etter at programvaren er grundig delt opp i komponenter og testet gjennom enhetstesting, settes programvaren sammen i grupper og testes på nytt. Hvis enhetstesting skal kontrollere at hver enkelt del fungerer som den skal, kontrollerer integrasjonstesting at disse delene kommuniserer med hverandre slik de skal. Tenk på det som montering av en bil. På hvert trinn i monteringen testes bildelene (motoren, pedalene og rattet) individuelt. Deretter monteres bilen og testes som en helhet, for å sikre at gasspedalen kommuniserer riktig med motoren (og at bremsene også gjør det!). Vil du sikre sømløs integrasjon mellom moduler? Våre anbefalte verktøy for programvaretesting kan hjelpe deg med nettopp det.
- Systemtesting: Systemtesting er det tredje nivået av programvaretesting. På dette stadiet testes en komplett og fullt integrert programvare. Formålet med systemtesten er å sikre at programvaren oppfyller kravene, altså gjør det den er utviklet for å gjøre.
- Akseptansetesting: Det siste stadiet i dynamisk testing. Akseptansetesten skal på nytt teste mot kravene og sikre at programvaren er ferdigstilt til en akseptabel standard. Den gjennomføres for å sikre at ingen feil har sluppet gjennom de andre teststadiene. I hovedsak er det en dobbeltsjekk av hensyn til sikkerheten.
Stadier i dynamisk testing
- Enhetstesting
- Integrasjonstesting
- Systemtesting
- Akseptansetesting
Raskt tips: Verifikasjonstesting kontra valideringstesting
Verifikasjonstesting har alle de viktigste kjennetegnene ved statisk testing. Formålet med en verifikasjonstest er å verifisere alle dokumentene og all koden, og dette oppnås gjennom de samme metodene som brukes ved statisk testing
På samme måte har valideringstesting alle de viktigste kjennetegnene ved dynamisk testing. En verifikasjonstest handler om å bekrefte at programvaren er av høy kvalitet, noe som er nøyaktig det system- og akseptansetestene handler om.
Nå som vi har gått gjennom noen viktige konsepter innen programvaretesting, skal vi se nærmere på de 9 typene programvaretesting alle QA-analytikere bør kjenne til.
9 typer programvaretesting alle QA-analytikere bør kjenne til:
- Svartboks
- Hvitboks
- Gråboks
- Automatisert
- Enhet
- Regresjon
- Utforskende
- Funksjonell testing
- Brukervennlighetstesting
1. Svartboks-testing
Svartboks-testing er en programvareteststrategi der utformingen av programvaresystemet som testes, er ukjent for testeren.
Husker du scenen på slutten av Pulp Fiction, der Samuel Jackson åpner kofferten og ansiktet hans lyser opp? Som publikum vet vi hva kofferten betyr og representerer i filmens kontekst, men vi får aldri vite hva som er inni. En svartbokstester er publikumsmedlemmet som vet hva tingen (enten det er en koffert eller systemprogramvare) skal gjøre, men ikke hva den er laget av.
En tester som har ansvar for svartboks-testing av tidsregistreringsprogramvare, åpner programmet uten kunnskap om programvarens interne utforming og prøver ut de ulike funksjonene og menyene for å kontrollere at de fungerer som forventet. Grunnen til å gjennomføre svartboks-testing er at testeren, uten inngående kjennskap til programvarens utforming, vil møte programvaren med omtrent de samme forventningene som sluttbrukeren.
Noen fordeler med svartboks-testing er:
- Testere trenger ikke mye kunnskap om programmeringsspråk fordi testeren bruker programvaren fra en brukers perspektiv.
- Gir en upartisk vurdering av programvaren fordi programvaretesten utføres av QA-teamet i stedet for programvareutviklerne.
- Testerne trenger ikke å være oppdatert på utviklingen av programvaresystemet, noe som betyr at det er svært kort oppstartstid før testene kan gjennomføres.
Relatert lesning: De 10 beste verktøyene for svartboks-testing
2. Hvitboks-testing
Ved hvitboks-testing har QA-medlemmet full forståelse av den interne strukturen og utformingen av programvaren som testes. Testeren går inn i testen som en inspektør og sørger for at alle deler av programmet kjører som de skal. Hvitboks-testing omtales noen ganger som klarboks-testing fordi testeren observerer samspillet mellom enhetene mens programvaren testes. I motsetning til ved svartboks-testing er en hvitbokstester ikke på langt nær like opptatt av brukeropplevelsen.
Noen fordeler med hvitboks-testing er:
- Tester kan kjøres på tidlige utviklingsstadier. Det grafiske brukergrensesnittet (GUI) trenger ikke å være fullt funksjonelt.
- Testene er mer grundige og gjennomtenkte enn svartbokstestene.
I Pulp Fiction-eksempelet er hvitbokstesteren Tim Roths rollefigur, som stirrer direkte på det som er inni kofferten.
3. Gråboks-testing
Ved gråboks-testing har testeren en viss kunnskap om programvarens interne struktur og utforming (hvitboks), men tester fortsatt fra sluttbrukerens perspektiv (svartboks). Slik oppsto gråboks-testing. Ved gråboks-testing utvikles utformingen av testen ved å se på programvarens interne struktur, mens selve testen gjennomføres ved hjelp av brukergrensesnittet.
Hvis dette igjen hadde vært den berømte scenen fra Pulp Fiction, er gråbokstesteren verken publikum eller Tim Roth. Denne gangen er testeren Quentin Tarantino selv.
4. Automatisert testing
Automatiserte tester bruker programvare til å utføre oppgaver uten manuelle instrukser fra en tester.
Ved manuell testing skriver testeren koden de vil kjøre, eller planlegger programvareforløpet de vil kontrollere at fungerer som det skal. Automatiserte tester tar seg av slike ting på vegne av testeren. Her er en kort liste over automatisert programvare og QA-verktøy som QA-analytikere bør kjenne til:
For en mer grundig gjennomgang av verktøy for automatisert testing kan du se listen over de beste verktøyene for automatisert testing som du bør bruke.
5. Enhetstesting
Verktøy for enhetstesting sørger for at hver enkelt del av programvaren fungerer som den skal. Det er svært viktig å sørge for at enhetstestingen gjennomføres på riktig måte, ellers vil utviklingsteamet få et stort tilbakeslag når de senere innser at en viktig del av programvaren ikke fungerer.
6. Regresjonstesting
Verktøy for regresjonstesting kjører gamle tester på nye bygg for å sørge for at programvaren fortsatt fungerer som tiltenkt. Ved å kjøre regresjonstester beskytter man utviklerne mot uforutsette konsekvenser og sørger for at en endring i programvaren på punkt A ikke ved et uhell ødelegger noe på punkt D.
For en QA-analytiker bør to skritt frem og ett skritt tilbake ikke ses på som noe negativt. Ved å ta ett skritt tilbake nå og da sørger du for at du ikke risikerer å måtte ta femti skritt tilbake senere.
7. Utforskende testing
Utforskende testing er testing for folk som ikke liker planlegging. I de fleste andre situasjoner planlegges testtilfellet grundig før det utføres. Ikke her. Når en tester gjennomfører en utforskende test, utforsker vedkommende programvaren uten noen forhåndsdefinert plan ved hjelp av spesialiserte verktøy for utforskende testing.
Fordelen med utforskende testing er at testeren kan tilpasse seg funnene sine underveis, uten å måtte skrive et nytt testtilfelle. Utforskende testing legger også til rette for samarbeid, utvikling av teorier og problemløsning – alt underveis.
Ettersom den smidige utviklingsteorien har blitt mer fremtredende, har også utforskende testing blitt det. Ved å la QA-testere bruke intuisjonen sin oppdages mange interessante feil som en tradisjonell testgjennomføring kanskje ikke ville ha lett etter.
Vær advart: Utforskende testing kan kreve stor kreativitet.
More Articles
8. Funksjonstesting
Funksjonstesting gjennomføres for å sørge for at systemprogramvaren samsvarer med prosjektkravene som ble fastsatt før utviklingen startet.
Programvaretesteren kontrollerer at inndataene samsvarer med det forventede resultatet. Den gjennomføres i en av de siste testfasene, enten som systemtesting eller akseptansetesting, og er utelukkende en form for svartboks-testing, ettersom den ikke er opptatt av hvordan programvaren fungerer, så lenge den fungerer.
9. Brukervennlighetstesting
Testere av brukervennlighet sørger for at designvalgene er funksjonelle, men samtidig intuitive.
Hvis du antar at mange brukere av programvaren ønsker å sikkerhetskopiere dokumentene sine hver halve time, er det best å plassere sikkerhetskopieringsfunksjonen på et lett tilgjengelig sted i stedet for å skjule den bak fire undermenyer.
Ved mange anledninger har det blitt utviklet programvare som fungerer feilfritt og dekker et viktig behov i markedet, men som er helt umulig å navigere i fra brukerens perspektiv. Dette kan forklares med mangel på brukervennlighetstesting i testfasen for programvaren.
Til syvende og sist vil det, uansett hvor god programvaren er teknisk sett, være vanskelig å finne et marked hvis brukerne ikke liker å bruke den.
Vil du ha mer?
Programvaretestingsbransjen er i stadig endring, og QA-analytikere må holde seg oppdatert på aktuelle trender. Det finnes utallige ressurser om programvaretesting, blant annet podkaster, bøker, nyhetsbrev og mer.
Abonner på The CTO Club-nyhetsbrevet for produktoppdateringer, verktøyanmeldelser og flere ressurssamlinger.
