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 holdt en så høy standard som mulig. Her er tre grunner til at programvaretesting er viktig.
- Kundetilfredshet: Under utviklingen av et prosjekt kan det være lett å gå seg vill i kodens villnis og glemme at brukeren også må være fornøyd med hvordan programvaren fungerer. QA-analytikere og andre QA-medlemmer fyller denne rollen.
- Produktkvalitet: Alle yrker der et team eller en enkeltperson skaper 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 typer 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 typene programvaretesting, skal jeg forklare forskjellen mellom disse to metodene og hvor i programvareutviklingssyklusen de kommer inn i bildet.
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. Det stemmer, 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 blir ikke utarbeidet noen dokumentasjon.
- Gjennomgang: Kodeforfatteren 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 gjennomgangene. Et team av opplærte moderatorer inspiserer dokumentene grundig under møtet. Alle feil som oppdages, dokumenteres formelt og loggføres for gjennomgang. Det gjennomføres en oppfølging for å kontrollere at de dokumenterte feilene er håndtert.
I de fleste tilfeller er statiske testgjennomganger nyttige fordi hele kvalitetssikringsteamet analyserer produktet og foreslår endringer basert på problemer de ser, og problemer som kan forutses. I tillegg til fordelen ved å få mange ulike stemmer 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 koden kjøres. Naturligvis betyr dette at utviklingen må ha kommet lenger i produksjonssyklusen. Fordelen med å teste kjørbar kode er at kvalitetssikringsanalytikere kan se på hvordan programvaren fungerer mens den kjører i en situasjon fra den virkelige verden. 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 fra den virkelige verden. 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 kvalitetssikringsanalytikere bør kjenne til:
- Enhetstesting: Når programvare enhetstestes, deles den opp i minst mulige komponenter og testes individuelt. Ved å teste på denne måten kan kvalitetssikringsanalytikere være trygge på at hver enkelt del av programvaren fungerer som tiltenkt. Og hvis det oppdages en feil, er den enklere å utbedre på dette utviklingsstadiet, fordi problemkoden raskt kan isoleres. Vanligvis starter kvalitetssikringsteamet med enhetstester når det begynner med dynamisk testing (selv om dette teststadiet noen ganger håndteres av utviklingsteamet).
- Integrasjonstesting: Etter at programvaren er grundig brutt ned i komponenter og testet gjennom enhetstesting, settes programvaren sammen i grupper og testes på nytt. Hvis enhetstesting skal sikre at hver enkelt del fungerer riktig, skal integrasjonstesting sikre at disse delene kommuniserer med hverandre slik de skal. Tenk på det som monteringen av en bil. På hvert monteringstrinn 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 nok en gang 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 vs. 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 har høy kvalitet, og det er nettopp dette 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 kvalitetssikringsanalytikere bør kjenne til.
9 typer programvaretesting alle kvalitetssikringsanalytikere bør kjenne til:
- Svart boks
- Hvit boks
- Grå boks
- Automatisert
- Enhet
- Regresjon
- Utforskende
- Funksjonstesting
- Brukervennlighetstesting
1. Svartboks-testing
Svartboks-testing er en programvareteststrategi der utformingen av programvaresystemet som testes, er ukjent for testeren.
Husk 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 sammenheng, men vi får aldri vite hva som er inni den. En svartboks-tester er som et publikumsmedlem: Testeren 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 et tidsregistreringsprogram, åpner programmet uten kjennskap til programvarens interne utforming og prøver de ulike funksjonene og menyene for å sikre at de fungerer som forventet. Grunnen til å utføre svartboks-testing er at testeren, uten inngående kjennskap til programvarens utforming, vil ha lignende forventninger til programvaren 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 å holde tritt med utviklingen av programvaresystemet, noe som betyr at det er svært kort forberedelsestid før testene kan utføres.
Relatert lesning: De 10 beste verktøyene for svartboks-testing
2. Hvitboks-testing
Ved hvitboks-testing har QA-medarbeideren full forståelse av den interne strukturen og utformingen til programvaren som testes. Testeren går frem 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 hvitboks-tester ikke på langt nær like opptatt av brukeropplevelsen.
Noen fordeler med hvitboks-testing er:
- Tester kan kjøres tidlig i utviklingen. Det grafiske brukergrensesnittet (GUI) trenger ikke å være fullt funksjonelt.
- Testene er mer grundige og bevisste enn svartboks-tester.
I Pulp Fiction-eksempelet er hvitboks-testeren Tim Roths rollefigur, som ser direkte på det som er inni kofferten.
3. Gråboks-testing
Ved gråboks-testing har testeren noe kjennskap til programvarens interne struktur og utforming (hvitboks), men tester fortsatt fra sluttbrukerens perspektiv (svartboks). Slik oppsto gråboks-testing. Ved gråboks-testing utvikles testutformingen ved å se på programvarens interne struktur, mens selve testen utføres ved hjelp av brukergrensesnittet.
Hvis dette igjen hadde vært den berømte scenen fra Pulp Fiction, er gråboks-testeren 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 programvarebanen de vil kontrollere at fungerer som den 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 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 riktig, ellers vil utviklingsteamet oppleve 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 å sikre at programvaren fortsatt fungerer som tiltenkt. Ved å kjøre regresjonstester beskytter man utviklerne mot latente effekter ved å sørge for at en endring i programvaren på punkt A ikke ved et uhell ødela noe langt borte 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 personer som ikke liker planlegging. I de fleste andre situasjoner planlegges testtilfellet grundig før det gjennomføres. Ikke her. Når en tester utfører en utforskende test, utforsker vedkommende programvaren uten en 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, teoriutvikling og samarbeid underveis.
Etter hvert som 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 oppmerksom på at utforskende testing kan kreve stor grad av kreativitet.
More Articles
8. Funksjonell testing
Funksjonell testing gjennomføres for å sikre at systemprogramvaren samsvarer med prosjektkravene som ble fastsatt før utviklingen startet.
Programvaretesteren kontrollerer at inndataene samsvarer med det forventede resultatet. Testingen gjennomføres i en av de siste testfasene, enten som systemtesting eller akseptansetesting, og er utelukkende en form for svartboks-testing, siden den ikke bryr seg om hvordan programvaren fungerer, så lenge den fungerer.
9. Testing av brukervennlighet
Testere av brukervennlighet sørger for at designvalgene er funksjonelle, men samtidig intuitive.
Hvis du antar at mange brukere av programvaren vil ønske å sikkerhetskopiere dokumentene sine hver halvtime, 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 fullstendig umulig å navigere i fra brukerens perspektiv. Dette kan forklares med manglende testing av brukervennlighet under programvaretestfasen.
Når alt kommer til alt, vil det være vanskelig å finne et marked for et programvareprodukt hvis brukerne ikke liker å bruke det, uansett hvor teknisk godt det er.
Vil du ha mer?
Programvaretestingsbransjen er i stadig endring, og QA-analytikere må holde seg oppdatert på aktuelle trender. Det finnes uendelig mange ressurser om programvaretesting, blant annet podkaster, bøker, nyhetsbrev og mer.
Abonner på The CTO Club-nyhetsbrevet for produktoppdateringer, verktøyanmeldelser og flere ressursoversikter.
