7 Test Case Skrive Tips For Å Forbedre ERP Programvare Testing Prosessen

Testtilfeller er svært viktig for å sikre kvalitet i ERP programvare testing prosessen. De er de første trinnene i en testsyklus, og hvis testtilfeller ikke er av tilstrekkelig kvalitet, vil hele prosjektet bli ‘belastet’. Skrive “stor” testtilfeller er en ferdighet som får skjemaet ved å gjøre det. Men det er veldig nyttig å ha noen innsikt som kan hjelpe deg. Med denne artikkelen vil jeg nå ut til deg og gi forslag for å gjøre det enklere, morsommere og bedre. Tipsene som vil bli gitt vil i spesielt forholde seg med testtilfeller ved aksept testing AV ERP-systemer.

hva er testtilfeller?

innen programvaretesting er det mange definisjoner av testtilfeller. På grunn av dette er det viktig å nevne vår definisjon. I vår filosofi er testtilfeller (basert PÅ IEEE610): “et sett med testinnganger, utførelsesforhold og forventede resultater utviklet for et bestemt mål.”Å vite hvordan man skriver gode testtilfeller er ekstremt nyttig for alle som ønsker å teste. Enten det er en funksjonstest, en brukeraksepttest, testing av en webapplikasjon eller en MODUL i ET ERP-system. I alle situasjoner beskrevet ovenfor testtilfeller bestemme i hvilken utstrekning resultatene gi en dom på pre-set mål.

Hvorfor er det så vanskelig å skrive testtilfeller?

Som beskrevet i definisjonen, Hjelper Testtilfeller testere gjennom en sekvens av testinstruksjoner for å avgjøre om programvaren oppfyller de forhåndsdefinerte kravene. Utførelsen av testtilfeller hjelper oss med å samle og oppdage informasjon for å realisere det spesifikke målet eller målet. Det første problemet vi direkte møter er mangfoldet av mulige mål. Og fordi det finnes forskjellige typer test og mål, er det forskjellige typer tilsvarende testtilfeller.

et annet problem er relatert til innholdet i selve testinstruksjonen eller trinnene. Nivået på disse instruksjonene er avhengig av hvilken type tester som må tolke denne informasjonen og gi en mening. En profesjonell tester trenger forskjellige instruksjoner i motsetning til en sluttbruker som er involvert med aksept testing av ET ERP-system

Tips 1: Bestem målet ditt og hva du vil rapportere

Tenk på hva du vil rapportere, slik at du kan bestemme ditt avledede mål. Ved å bruke det som en base, har du oversikten over testsaken i sikte. Det er mange forskjellige mål, hvor vi alltid må spørre oss selv hva vi prøver å lære eller oppnå når vi skal kjøre testen. Her er noen eksempler:

• Finne feil: dette er det klassiske formålet med testing. En test utføres for å avsløre feil.
• Maksimer antall feil: Forskjellen mellom “maksimere antall feil “og” finne feil ” er at det totale antall feil er viktigere enn dekning.
• Blokker premature produktlanseringer: målet med denne testen er å for tidlig finne så mange alvorlige defekter (showstoppers) slik at ingen tar produktet i produksjon.
• Støtt ledere med sine go/no-go-beslutninger: Ledere tar beslutninger basert på risiko. Risiko indikasjoner som test dekning, virkningen av problemer funnet, etc. Gi dem en bedre bakgrunn for å basere sine beslutninger.
• Vurder samsvar i henhold til spesifikasjon: de påståtte spesifikasjonene kontrolleres for deres drift. Alle forhold som ikke er knyttet til spesifikasjonene, blir ignorert.
• Vurder kvaliteten: dette er et vanskelig mål, fordi kvaliteten er flerdimensjonal. Kvaliteten er avhengig av produktets natur. For å vurdere kvaliteten bør klare kriterier utarbeides, som er definert på en måte som de faktisk kan gjøres målbare.

testresultatene fra testtilfellene gir direkte relevant informasjon om målet.

Tips 2: reserver tilstrekkelig designtid

Reserver nok tid til å designe testtilfellene dine, slik at de samsvarer med målene dine. Dårlige testtilfeller vil hjemsøke deg gjennom hele testprosessen. Sammenligning av testresultater, rapportering på flere testrunder, etc. Er i hovedsak bestemt av kvaliteten på testtilfellene dine.

hvis du allerede går tom for tid til å designe, men fortsatt vil begynne å teste, må du sørge for at du i det minste har definert hovedrisikoen. Hvis 10 testere må gjennomgå 5 testtilfeller med 1 testtrinn, vil dette resultere i 50 testresultater. Uansett hva disse 50 resultatene gir mer informasjon om kvalitet og gjør ingenting. Dette vil nok ikke være uttømmende, men det er et første skritt. Derfra kan detaljnivået for visse deler bestemmes.

vi foretrekker at du tenker godt på forhånd om hvordan testen skal utformes, og at resultatene av testen gir et reelt svar på målet. Men i virkeligheten er dette noen ganger urettferdig.

Tips 3: Navnetesttilfelle

Navngivningstesttilfelle er viktig. I en gjennomsnittlig ERP-test har du lett mer enn 500 testtilfeller. Du vil forstå at en logisk navnestruktur forbedrer finnbarheten. I litteraturen blir det ofte referert til som et komplett som mulig navn, der det skal testes prosess, modul, objekt etc. Alt er inkludert i navnet. Du kan forestille deg at å gi 500 testtilfeller med en så komplett tittel gir en kaotisk administrasjon. Med et Enkelt Excel-ark mister du enkelt oversikten. Teststyringsverktøy gir en struktur som du kan relatere testtilfeller til gjenbrukbare objekter, uten at de “forurenser” navnet. Du har også testregistreringsverktøy som organiserer disse relasjonene på en annen måte.

Innen TestMonitor for eksempel oppfant vi en annen løsning. I verktøyet kan du definere etiketter eller koder som du deretter kan koble til testtilfeller. Innenfor TestMonitor er testtilfellene knyttet til en eller flere forretningsprosesser-, risiko -, krav-eller applikasjonsetiketter. Dette gjør at testtilfeller kan grupperes og hentes fra ulike perspektiver.

for navnet på et testtilfelle i TestMonitor er det nok med en klar beskrivelse av formålet med testtilfellet. For å gjøre det enkelt beskriver du en aktivitet med en implisitt forventning.

eksempel test case navn:
“Oppsigelse av lease-uavhengig hjem”
” Opprett kunde “”Foreløpig bestillingsbekreftelse”
etc.

eksempel på testtilfelle “Provisional booking receipt” som er knyttet til flere etiketter:

• forretningsprosess’Motta varer’
• krav ‘Kontraktskrav’
• risiko ‘Operasjonell risiko’
• søknad ‘erp’

det er viktig å beskrive det forventede resultatet per testtilfelle. Testeren vet da i hvilken retning “svaret” må være og får direkte et eksplisitt testramme.

Tips 4: Test trinn beskrivelse

som beskrevet i definisjonen testtilfeller er en samling av testinstruksjoner som hjelper oss å oppdage informasjon for å oppnå et bestemt mål.

et testtilfelle må ha en klar begynnelse og slutt for å avgjøre om testtilfellet besto eller mislyktes. I tillegg er et testtilfelle sammensatt av en eller flere testinstruksjoner eller-trinn, hvor det er flere baner mulig for å oppnå ønsket resultat. Bare å teste veien til suksess er ofte utilstrekkelig. I visse situasjoner følgende ikke-suksess baner kan bare gjøre forskjellen.

det er viktig å definere testtrinn så klart som mulig, slik at sluttbrukeren for en brukerakseptstest vet nøyaktig hva de må gjøre. Selvfølgelig er det forutsetninger for å komme opp med, som funksjonsnivå tester, kunnskap om det nye systemet, kunnskap om mulige justerte forretningsprosesser, etc. Men i hovedsak bør alle forstå alle teststrinnene.

Anta at vi videre beskrive testtilfelle “Lease oppsigelse-uavhengig hjem” for en enkel suksess banen:

1. Velg en enhet og start oppsigelsen av leieavtalen. Kontroller om det er forutsetninger blant annet oppsigelse av leieavtale kan / ikke aksepteres og opprett en oversikt over dette.
2. Planlegg en avtale for den endelige inspeksjonen.
3. Fyll dataene i skjermen Oppsigelse av leieavtalen. Dobbeltsjekk leietaker data i leieavtalen oppsigelse kortet.
4. Registrer oppsigelsen av leieavtalen og send et konformasjonsbrev. Sjekk om bekreftelsesbrevet er kommet i digitalarkivet.
5. Sjekk i kontraktsregisteret fra enheten at den nåværende kontrakten er avsluttet, at den avsluttede kontrakten er knyttet til oppsigelse av leieavtalen og at det er en nyopprettet en ledig kontrakt.
6. Sjekk den nye (ledig stilling) kontrakten basert på leiepolicy og elementmaler.

hva legger du merke til?

• hvert testtrinn starter med et verb
• Etterfulgt av et emne
• Avsluttes med detaljering og eventuelt kontrollspørsmål. Du kan velge å sette kontrollspørsmålene i separate testtrinn, men øvelsen viser at kontrollspørsmålet er en forfining av handlingen, og deretter, logisk, vil bli skrevet ned som et testtrinn.

i eksemplet ovenfor er det antatt at en spesialist fra et bestemt felt vil evaluere testtrinnet. Og fordi han eller hun er spesialist, er det ikke gitt noen innspillsbetingelser eller eksplisitte forventninger skissert, fordi spesialisten fortsatt har sine egne casestudier i ermet og hans forventninger er krystallklare.

hvis du for øyeblikket ikke har en spesialist, kan du utvide testtrinnene med inngangsbetingelser og eksplisitte forventninger.

for eksempel test trinn 1 på testen saken “Oppsigelse av leieavtalen-uavhengig hjem” med flere detaljer.

1. Velg enheten “Fleet street 677” og starte oppsigelse av leieavtalen. Vilkårene sikrer at denne enheten ikke kan avsluttes før etterskuddsvis er betalt.
2. Etc.

Tips 5: Ikke mer enn 10 testinstruksjon i 1 testcase

vi kommer regelmessig over testprosjekter der >50 testtrinn er tildelt ett testcase. Dette er for mye av noen grunner:

• alle test skritt må tas separat (eller eksplisitt bestått) før en test sak får en dom.
• den endelige vurderingen av et testtilfelle bestemmes av den” verste ” poengsummen. Så det kan vel være at 49 testtrinn vil bli vurdert som ” gode “og en som” feil”, noe som resulterer i et” feil ” testfall. Målingen av testtrinnene skal herved være lik. Med det mener jeg at nesten hvert testtrinn må være lik effekten av evalueringen. Hvis du har 10 teststrinn du må følge, inkludert 2 små teststrinn som de er uforholdsmessige til de andre 8 teststrinnene, må du omformulere dem. Det samme gjelder omvendt med et tøft testtrinn.
• testeren går raskt tapt med for mange testtrinn i et testfall. Vi har ikke gjort en vitenskapelig studie om det, men øvelsen viser at et testfall ikke bør inneholde mer enn 10 testtrinn. Man kan tenke på mange unntak (konverteringskontroller, etc), men i praksis for en brukerakseptstest av ET ERP-system fungerer dette best.
• det er vanskelig for utviklere å reprodusere feilen som ble funnet. Med mange test trinn utvikleren vil miste mye tid på å prøve å re-vedta situasjonen.
• Repriser eller retest av store testtilfeller tar for mye tid. Når en feil oppdages av en tester, må det tilsvarende testtilfellet testes på nytt. En retest krever at selve trinnet blir revurdert, du vil åpenbart forhindre regresjonsfeil. Ved å ta for mange testtrinn, tester du mest sannsynlig for mye. På denne måten tar testprosessen lengre tid og kan til slutt overbelaste testerne dine.

Ved siden av det har du også testregistreringsverktøy som kan presentere testtilfellene i ulike former til testeren. TestMonitor har for eksempel to forskjellige visninger. TestMonitor har en skjerm som viser alle testtrinnene separat per side og en skjerm der testtilfellene presenteres per side, inkludert alle testtrinnene.Fordelen med den første skjermen er at hver tester kan få mer informasjon for hvert testtrinn. Ulempen hvis testeren er mer erfaren, må han klikke på” neste ” hver gang han vil gå videre til neste testtrinn. I den andre visningen for hvert testtilfelle er fordelene og ulempene omvendt.

Tips 6: Gjennomgang av en ikke-designer/leverandør

i praksis ser vi jevnlig testskript utarbeidet av programmererne til programvareleverandøren. Når du vurderer disse testskriptene av eventuelle testere, er det vanligvis flere spørsmål enn svar. Omvendt fungerer dette på samme måte for testskript utarbeidet av egen medarbeider. Det gir en reell merverdi å gjennomgå disse av programvareleverandøren. De ser på de ferdige testskriptene med forskjellige øyne og kommer alltid opp med meningsfulle tillegg eller modifikasjoner.

med litt brainstorming med programvareleverandørens spesialister og klientorganisasjonen får du raskt fokus på essensen av det som må testes. Så ta deg tid til å vurdere testtilfeller, ikke-suksess scenarier, og du vil se at testmodellen er raskt blir mer omfattende og detaljert. Dessuten får du mer informasjon om kvaliteten da du anses mulig.

Tips 7: TestMonitor

Ved siden av det gjør bruk av en profesjonell testplattform og gjør kvaliteten veldig innsiktsfull. Be om En gratis prøveversjon Av TestMonitor i dag og se og opplev forskjellen selv.

hvis du er en nykommer i verden av testing, du lett bli overveldet av all testing terminologi å bli kastet rundt. I denne artikkelen vil vi prøve å forklare noe av sjargongen du kan støte på i ditt daglige testliv, bare for å gjøre det hele litt mer forståelig.

Start testing Med TestMonitor

Ikke En TestMonitor bruker ennå? God og enkel testing er viktig for kvalitetssikringsledere, testledere, IT-ledere, testledere og release manager. TestMonitor gjør testing enkelt og morsomt for testbrukere også.

så la oss komme i gang. Du vil kanskje sjekke ut videoen vår eller laste ned produktbrosjyren. Men selvfølgelig, med en gratis prøveversjon kan du virkelig oppleve brukervennligheten Av TestMonitor selv.

Holde kontakten? Følg TestMonitor På Twitter og LinkedIn.