Testcase-mal for forbedret programvarekvalitet (2023)

Å skrive effektive testcases er en integrert del av programvareutviklings- og testprosessen, spesielt når man arbeider med komplekse applikasjoner med flere funksjoner. Testtilfeller fungerer som en referanse for fremtidige testsykluser, letter kunnskapsoverføring når nye teammedlemmer blir med, og hjelper til med å identifisere og dokumentere komplekse funksjoner. De er også viktige for å forhindre feil, forbedre testdekningen og prioritere produktutgivelser

Hva er testtilfeller:

En testcase er et sett med trinn eller instruksjoner skrevet for å teste en funksjonalitet eller en funksjon i en programvareapplikasjon. For å utføre omfattende testing av en programvareapplikasjon, trenger vi detaljerte testtilfeller på plass. Testcases er også den enkleste måten og en del av prosessen når det gjelder kunnskapsoverføring. Det kan hjelpe den andre personen til å forstå applikasjonen på et innledende nivå.

Hvorfor skrives testsaker:

Testsaker skrives vanligvis av følgende grunner:

1. Forebygging av feil

3. Bedretestdekning

4. Identifisere og dokumentere komplekse funksjoner

5. Prioritere dem mens du slipper produktet

Testtilfeller og testscenarier:

Testscenarier er vanligvis utledet fra forskjellige aspekter. Den gir vanligvis informasjon om hva alle parametere vurderes for å evaluere produktet. Det kan komme fra:

1. BRD (Business Requirement Document)

2. Tilbakemelding fra kunder

3. Akseptkriterier

4. Forutsetninger for de udokumenterte kravene

5. Brainstorming økter

6. Endringsforespørsler

Ved å bruke testscenarier lager man testcases som gir detaljert informasjon om 1. Trinn som skal følges

2. Forutsetninger

3. Datasett som skal brukes

4. Utgang

Testtilfeller er de detaljerte trinnene utledet for testscenarioene, som skal dokumenteres for å hjelpe teamet til å øke effektiviteten og spare tid i fremtiden, der teamet må referere til tidligere testsykluser og identifisere manglende scenarier

Hvem skriver testsakene:

Den som er ansvarlig for å teste produktet skriver testsakene. I et team som jobber i et smidig miljø, siden hver enkelt kommer med sin egen ekspertise, kan testcases skrives av alle medlemmer av teamet som utviklere, kvalitetsingeniører og forretningsanalytikere.

Utviklere skriver testsakene som en del av utviklingsprosessen som vi kaller Unit tests. Dette gir oss kodedekning for modulen som er mest påvirket av kodeendringen

Når QA-ingeniører skriver testcaser, vurderer de vanligvis den generelle kvaliteten på en applikasjon, som krever flere iterasjoner og teknikker.

Forretningsanalytikeren eller en produkteier som er ansvarlig kan også skrive testcaser fra et produktfitness-synspunkt som senere kan dissekeres på et lavere nivå.

Testcase-mal:

Mens du skriver en testcase, må en tester ha i tankene å lage et dokument som har den nødvendige informasjonen for å utføre og evaluere testcasestatusen. En test består vanligvis av parametrene nedenfor.

1.Testtilfelle-ID:Hver test må ha en unik id som kan tilordnes Story id eller Req id i verktøyet som brukes i teamet, som hjelper til med å holde oversikt og beregne testdekningen. Du kan referere til en kravdokumentmatrise for det samme

2.Beskrivelse: En kort beskrivelse av hva funksjonaliteten handler om og testscenarier den er avledet fra, sammen med en kort idé om forretningskravet, vil være nyttig for en ny person å forstå det på en bedre måte

3.Modulnavn: Modulen som testtrinnene tilhører, som hjelper oss senere å finne ut hvilke avhengige og påvirkede moduler som må prioriteres for testing.

4.Kompleksitet: Hva er kompleksiteten i testsaken? Det kan være (enkelt, middels eller komplekst), som hjelper oss å bestemme hvilken vi skal velge først når det er tidsklemme. Vi kan ganske enkelt filtrere ut de komplekse scenariene og planlegge testingen.

5.Forutsetninger: Det ideelle miljøet for å utføre trinnene for både positive og negative scenarier.

6.Testtrinn: Detaljerte trinn som følges av brukeren for å utføre de tiltenkte handlingene.

7.Testdata: Et omfattende testdatasett som brukeren må bruke for å utføre testsaken. Det kan være dummy-data opprettet i lavere miljøer, men det er alltid foretrukket å bruke ekte brukerdata for å få bedre utdata.

8.Forventede resultater:Resultatet forventet etter å ha fullført trinnene. Det kan være en melding eller en annen landingsside, en feilmelding (i tilfelle et negativt testtilfelle), eller en bekreftelsesmelding (for en vellykket transaksjon).

9.Egentlige resultatet:Fange opp systemets oppførsel etter at trinnene er utført og sammenligne det med forventet resultat

10.Status:Sett statusen som PASS/Ikke bestått i henhold til forrige trinnresultat. Hvis statusen mislykkes, oppretter og merker feilen for den spesifikke testsaken

11.Prioritet:Vi må sette prioriteringen av testsakene basert på forhold som funksjonalitet som har størst innvirkning på store arbeidsflyter i et system og som skal utføres til enhver tid eller basert på risiko og dekning og funksjonalitet som har mindre innvirkning og kan neglisjeres for en utgivelse.

Noen gode fremgangsmåter å følge når du skriver testsaker:

1. Sikt mot scenarier for hjørne/kantkasse

2. Skriv testtrinnene nøyaktig med fokus på omfanget

3. Legg ved og referer relevante testdata eller dokumenter som må henvises til i ethvert trinn 4. Unngå å bruke det komplekse engelske språket

5. Ikke stol på antagelser mens du skriver testcaser

6. Samle så mye domenekunnskap du kan før du begynner på testideer

7. Få testsakene dine gjennomgått av produktets eier eller BA og samle tilbakemeldingene deres. 8. Ha tidligere brukeratferd og feil i bakhodet og ta med dem i testtrinnene dine

9. Se forbi brukergrensesnittet, og prøv å finne ikke-funksjonelle testtilfeller for funksjonen

10. Ta hjelp av automatisering for å øke produktiviteten ved å redusere repeterende oppgaver og fokusere mer på å lage bedre testideer

11. Bruk teststyringsverktøy aktivt for å redusere vedlikehold.

Ved å bruke verktøy for å skrive testcases reduseres innsatsen til teamet til en maksimal prosentandel. Ved å bruke disse verktøyene kan vi øke konsistensen, nøyaktigheten og gjenbrukbarheten til testsakene.

For å skrive automatiserte testsaker:

∙ vi må bestemme omfanget av testingen og identifisere testscenariene for testautomatisering

∙ Vi ​​må velge et automatiseringsverktøy som best passer kravene og ferdighetene til teammedlemmene.

∙ Design og utfør testsakene og evaluer resultatene på en automatisert måte når det er nødvendig.

Opprette og administrere testcases gjennom Testsigma:

For å skrive, utføre og vedlikeholde automatiserte testsaker tilbyr Testsigma en brukervennlig plattform hvor man kan lage ulike kategorier i henhold til kravet.

Definer type testcase:

Angi prioriteringer:

Brukere kan også angi prioriteter (Kritisk, Høy, Middels, Lav) for de opprettede testsakene inne i verktøyet. Brukere er i stand til å lage tilpassede prioriteringer som (f.eks: superkritisk).

Definer kravene:

Brukeren kan også lage egne kravtyper som testcasen er utledet fra, da kravene til testcasene kommer fra ulike innganger.

Vedlikehold av testtilfeller:

Mens du legger til, oppdaterer og fjerner testtilfeller fra verktøyet, holder det styr på tidligere aktiviteter og bidrar til å unngå menneskelige feil. Den har historikk lagret for hver handling som skjedde for testtrinnet opprettet av brukeren.

Brukere kan også filtrere de nødvendige trinnene gjennom forskjellige tagger som er lagt til testtrinneneImport og eksport:

Brukere kan importere de opprettede testsakene fra forskjellige plattformer som jira , testsigma hjelper til med å migrere eller laste opp testtrinnene i bulk der brukere må gjøre endringer i alle eksisterende testtilfeller.

Finn mer informasjon om automatisering av testtilfeller med Testsigma på:

https://testsigma.com/docs/test-cases/overview/

Sammendrag:

Vedlikehold av testcases kan være en utfordring i et smidig miljø, hvor krav er gjenstand for hyppige endringer. Bruk av automatiserte verktøy kan imidlertid være verdifullt i slike scenarier, noe som lar teamet tilpasse seg endrede krav samtidig som testsakene holdes oppdatert.

Håper du finner det nyttig

Lykke til med testingen ☺

H2: Ofte stilte spørsmål:

Hva er de fem viktigste elementene i en testsak?

1. Samle de riktige kravkriteriene

2. Ha brukeratferden i bakhodet.

3. Forutsetninger er den viktigste delen av enhver testsak

4. Lag konsise testcases, som er lett lesbare for andre
5. Vedlikehold og oppdater testsakene når det er nødvendig

Hva er de 4 egenskapene til en testcase?

1. Skrevet på en presis og kortfattet måte

2. Lett å forstå for alle

3. Dekker alle aspekter ved testing

4. Enkel å vedlikeholde

Hvordan oppretter jeg en testcase i Jira?

1. Logg inn på Jira-kontoen din og naviger til prosjektet der du vil legge til testsakene.

2. Klikk på "Problemer"-fanen i den øverste navigasjonslinjen.

3. Velg "Create Issue" for å opprette en ny utgave.

4. I "Opprett utgave"-skjemaet velger du problemtypen som "Test".

5. Fyll ut den nødvendige informasjonen som sammendrag, beskrivelse og eventuelle andre relevante felt.

6. I beskrivelsen eller kommentarseksjonen kan du gi detaljerte trinn for testtilfellet, forventede resultater og annen nødvendig informasjon.

7. Tilordne problemet til det aktuelle teammedlemmet som er ansvarlig for å utføre testsaken, ved å velge navnet deres fra feltet "Tilordnet".

8. Angi prioritet og andre relevante felt basert på prosjektets krav.

9. Om nødvendig kan du legge ved filer eller skjermbilder til testsaken ved å bruke delen "Vedlegg".

10. Lagre problemet for å opprette testsaken i Jira.

11. Gjenta trinnene ovenfor for hver ekstra testtilfelle du vil legge til.