Hvordan skrive testsaker med eksempler

๐Ÿš€ Smart sammendrag

En testtilfelle er et dokumentert sett med betingelser, inndata, handlinger og forventede resultater for รฅ bekrefte at en spesifikk funksjon fungerer som den skal i programvareapplikasjoner.

  • Nรธkkelprinsipp: Hvert testtilfelle mรฅ validere et enkelt krav eller en enkelt funksjon, og dokumentere betingelser, inndata og forventede resultater.
  • Implementeringsfokus: Testere mรฅ dokumentere tydelige, trinnvise handlinger og testdata for konsistent utfรธrelse av alle teammedlemmer.
  • Brukersentrisk tilnรฆrming: Design testtilfeller med sluttbrukerperspektivet i tankene, og sรธrg for at de gjenspeiler virkelige scenarier og krav.
  • Dekningsforsikring: Bruk sporbarhetsmatriser for รฅ sikre at alle krav testes, unngรฅ blindsoner og maksimer dekningen.
  • Eliminering av relevans: Unngรฅ รฅ gjenta testtilfeller; bruk testtilfelle-ID-er for รฅ referere til avhengigheter i forhรฅndsbetingelser.
  • Teknikkapplikasjon: Bruk testteknikker som grenseverdianalyse og ekvivalenspartisjonering for รฅ fokusere pรฅ omrรฅder med hรธy risiko.
  • Hรฅndtering og sporbarhet: Bruk testadministrasjonsverktรธy for maldrevet dokumentasjon, utfรธrelsessporing og automatisert feilkobling.

Hvordan skrive testsaker

Hva er en testcase?

A testforsรธk er et sett av handlinger, innspill og forventede resultater som hjelper testere med รฅ bekrefte om en spesifikk funksjon eller funksjonalitet i programvare fungerer som tiltenkt. Den fungerer som en trinnvis veiledning som definerer hva som skal testes, hvordan det skal testes og hvilket resultat man kan forvente.

Tenk pรฅ et testtilfelle som en oppskrift pรฅ validering โ€“ den forteller deg de nรธyaktige ingrediensene (testdata), prosessen (trinn som skal utfรธres) og hvordan en perfekt rett (forventet resultat) bรธr se ut.

En godt skrevet testcase bidrar til รฅ sikre:

  • Programvaren oppfyller forretnings- og brukerkrav.
  • Feil eller uventet oppfรธrsel er fanget tidlig.
  • Testing kan vรฆre gjentatt og gjennomgรฅtt av enhver QA-profesjonell.
  • Lag kan spore hvilket krav hver test verifiserer.

๐Ÿ‘‰ Meld deg pรฅ gratis live programvaretestingsprosjekt

Trinn for รฅ lage testtilfeller i manuell testing

La oss lage et testtilfelle for scenariet: Sjekk pรฅloggingsfunksjonalitet

Opprett testtilfeller i manuell testing

Trinn 1) En enkel testcase for รฅ forklare scenariet ville vรฆre

Testtilfelle # Testsak Description
1 Sjekk svar nรฅr gyldig e-post og passord er angitt

Trinn 2) Test dataene.
For รฅ utfรธre testsaken, trenger du Testdata. Legger det til nedenfor

Testtilfelle # Testsak Description Testdata
1 Sjekk svar nรฅr gyldig e-post og passord er angitt E-post: guru99@email.com
Passord: lNf9^Oti7^2h

Identifisering av testdata kan vรฆre tidkrevende og kan noen ganger kreve รฅ lage testdata pรฅ nytt. Grunnen til at det mรฅ dokumenteres.

Trinn 3) Utfรธr handlinger.
For รฅ utfรธre en testsak, mรฅ en tester utfรธre et spesifikt sett med handlinger pรฅ AUT. Dette er dokumentert som nedenfor:

Testtilfelle # Testsak Description Teststrinn Testdata
1 Sjekk svar nรฅr gyldig e-post og passord er angitt 1) Skriv inn e-postadresse

2) Skriv inn passord

3) Klikk pรฅ Logg pรฅ

E-post: guru99@email.com

Passord: lNf9^Oti7^2h

Mange ganger er ikke testtrinnene sรฅ enkle som ovenfor, og derfor trenger de dokumentasjon. I tillegg kan forfatteren av testtilfellet forlate organisasjonen, dra pรฅ ferie, vรฆre syk og ha fri, eller vรฆre veldig opptatt med andre kritiske oppgaver. En nylig ansatt kan bli bedt om รฅ utfรธre testtilfellet. Dokumenterte trinn vil hjelpe vedkommende og ogsรฅ legge til rette for gjennomgang av andre interessenter.

Trinn 4) Sjekk oppfรธrselen til AUT-en.
Mรฅlet med testtilfeller i programvaretesting er รฅ sjekke oppfรธrselen til AUT-en for รฅ fรฅ et forventet resultat. Dette mรฅ dokumenteres som vist nedenfor.

Testtilfelle # Testsak Description Testdata forventet resultat
1 Sjekk svar nรฅr gyldig e-post og passord er angitt E-post: guru99@email.com
Passord: lNf9^Oti7^2h
Innlogging skal vรฆre vellykket

Under testgjennomfรธringstiden vil testeren sjekke forventede resultater mot faktiske resultater og tildele en bestรฅtt eller ikke bestรฅtt status

Testtilfelle # Testsak Description Testdata forventet resultat Egentlige resultatet Bestรฅtt / ikke bestรฅtt
1 Sjekk svar nรฅr gyldig e-post og passord er angitt E-post: guru99@email.com Passord: lNf9^Oti7^2h Innlogging skal vรฆre vellykket Pรฅloggingen var vellykket Pass

Trinn 5) At bortsett fra testsaken - kan ha et felt som,
en forutsetning som spesifiserer ting som mรฅ vรฆre pรฅ plass fรธr testen kan kjรธres. For vรฅrt testtilfelle ville en forutsetning vรฆre รฅ ha en nettleser installert for รฅ fรฅ tilgang til nettstedet som testes. Et testtilfelle kan ogsรฅ inkludere etterbetingelser som spesifiserer alt som gjelder etter at testtilfellet er fullfรธrt. For vรฅrt testtilfelle ville en etterbetingelse vรฆre at tid og dato for innlogging lagres i databasen.

Viktige elementer i en testtilfelle

En standard testtilfelle inkluderer vanligvis:

  1. Testtilfelle-ID โ€“ Unik identifikator (f.eks. TC001)
  2. Tittel eller Description โ€“ Hva testen bekrefter
  3. Forutsetninger โ€“ Hva som mรฅ vรฆre pรฅ plass fรธr testen starter
  4. Teststrinn โ€“ De nรธyaktige handlingene som skal utfรธres
  5. Testdata โ€“ Inndataverdier eller parametere
  6. forventet resultat โ€“ Resultatet du skal se
  7. Egentlige resultatet โ€“ Hva som egentlig skjedde
  8. status โ€“ Bestรฅtt, ikke bestรฅtt eller blokkert

Testcase vs Test Scenario

A testscenario beskriver hva som mรฅ testes โ€“ den brede funksjonaliteten eller brukerreisen.

A testtilfelle, pรฅ den annen side forklarer hvordan funksjonaliteten vil bli verifisert โ€“ de nรธyaktige trinnene, dataene og forventede resultatene.

For รฅ si det enkelt:

  • Testscenario = Idรฉ av hva som skal testes.
  • Testtilfelle = Implementering hvordan man tester den ideen.

Tenk pรฅ det slik โ€“

ยซHvis et testscenario er en kapitteltittel, er hvert testscenario et avsnitt som forklarer det kapittelet i detalj.ยป

Eksempelillustrasjon:

La oss ta et eksempel for รฅ gjรธre det tydeligere:

Testscenario:

ยซSjekk nettsidens innloggingsfunksjonalitet.ยป

Relaterte testtilfeller:

  1. Bekreft pรฅlogging med gyldig brukernavn og passord.
  2. Bekreft feilmeldingen med ugyldig passord.
  3. Bekreft pรฅlogging med tomme felt.
  4. Feltet for รฅ bekrefte passord skjuler inndatateksten.

Her er scenariet et enkelt funksjonelt mรฅl, mens testtilfeller deler det opp i spesifikke, testbare forhold.

Les for mer informasjon om Forskjellen mellom testtilfelle og testscenario

Fordeler med รฅ skrive testtilfeller av hรธy kvalitet

  • Testtilfeller av hรธy kvalitet sikrer grundig testdekning, konsistens og sporbarhet pรฅ tvers av hele kvalitetssikringsprosessen.
  • De hjelper testere med รฅ fange opp tidlige feil, vedlikeholde regresjonsstabilitet, og garantere at all funksjonalitet er i samsvar med forretningskravene.
  • Velskrevne testtilfeller er tydelig, gjenbrukbar og repeterbar, slik at ethvert tester- eller automatiseringsverktรธy kan utfรธre dem pรฅlitelig.
  • De fungerer ogsรฅ som en kommunikasjonsbro mellom utviklere, testere og interessenter โ€“ reduserer tvetydighet og sparer tid.
  • Ved รฅ dokumentere testmรฅl, trinn og resultater kan teamene mรฅle fremgang, overholde standarder, og administrere oppdateringer effektivt.
  • Viktigst av alt, gode testtilfeller redusere vedlikeholdskostnader, fremskynde automatisering, og tilby tillit til programvarekvalitet.
  • De fungerer som levende dokumentasjon for onboarding av nye testere og som strukturert input for AI og verktรธy for testhรฅndtering.

Vanlige feil รฅ unngรฅ nรฅr du skriver testtilfeller

Selv erfarne testere gjรธr smรฅ feil som svekker testkvaliteten.

ร… unngรฅ disse feilene kan forbedre det betraktelig nรธyaktighet, klarhet og vedlikeholdbarhet av testsuiten din.

  1. Skrive vage trinn: Tvetydige instruksjoner som ยซsjekk innloggingssidenยป forvirrer testere. Bruk tydelige, handlingsbaserte trinn.
  2. Hopp over negative scenarier: Inkluder alltid ugyldige inndata eller grensetester for รฅ sikre full dekning.
  3. Gjenbruk av uklare testdata: Umerkede eller inkonsistente data gjรธr testresultatene upรฅlitelige. Oppretthold et delt testdatablad.
  4. Overkompliserende testtilfeller: Lange saker med flere trinn er vanskelige รฅ vedlikeholde. Hold hver sak fokusert og atomรฆr.
  5. Ignorerer oppdateringer etter produktendringer: Utdaterte testtilfeller skaper falske resultater. Revse og revidere regelmessig.
  6. Manglende sporbarhet: Koble alltid testtilfeller til krav for รฅ spore dekning og samsvar.
  7. Hopper over fagfellevurderinger: Friske รธyne fanger opp uklare eller overflรธdige trinn tidlig.

Spรธrsmรฅl og svar

Testtilfeller skrives etter at kravene er ferdigstilt og fรธr utvikling eller testing starter. Dette sikrer tydelige valideringstrinn for hver funksjonalitet og hjelper QA-team med รฅ identifisere hull tidlig i programvareutviklingssyklusen.

Et sterkt testtilfelle inkluderer en unik ID, tittel, forutsetninger, testtrinn, inndata, forventede resultater, faktiske resultater, status og kommentarer. Disse feltene sikrer klarhet, sporbarhet og enkelt vedlikehold for testere og interessenter.

Testcasehรฅndtering sikrer organisert, gjenbrukbar og sporbar testdokumentasjon. Det forbedrer samarbeid, reduserer redundans og bidrar til รฅ spore testdekning. Bruk verktรธy som TestRail eller Jira for รฅ sentralisere, versjonskontrollere og overvรฅke testfremdriften effektivt.

For รฅ รธke effektiviteten, fokuser pรฅ gjenbrukbarhet, prioritering og klarhet. Bruk modulรฆr testdesign, automatisering for repeterende tester, regelmessige gjennomganger og sporbarhet til krav. Kontinuerlig optimalisering reduserer redundans og styrker testnรธyaktigheten over tid.

AI effektiviserer opprettelse av testtilfeller ved รฅ analysere krav, forutsi kanttilfeller og generere datadrevne scenarier. Den akselererer dekning, reduserer menneskelige feil og tilpasser tester dynamisk, slik at QA-team kan fokusere pรฅ strategi og kvalitetsvalidering i stedet for repeterende manuell skripting.

Claude og ChatGPT kan vรฆre kraftige allierte for รฅ skrive testtilfeller. Begge kan analysere krav, generere detaljerte eller parameteriserte testscenarier, foreslรฅ kanttilfeller og til og med konvertere naturlig sprรฅklige inndata til strukturerte testskript (som Gherkin eller pytest).

Oppsummer dette innlegget med: