7 Tips för att skriva testfall för att förbättra din testprocess för ERP-programvara

testfall är mycket viktiga för att säkerställa kvaliteten i din testprocess för ERP-programvara. De är de första stegen i en testcykel och om testfall inte är av tillräcklig kvalitet kommer hela projektet att belastas. Att skriva” bra ” testfall är en färdighet som får form genom att helt enkelt göra det. Men det är väldigt praktiskt att ha några insikter som kan hjälpa dig. Med den här artikeln vill jag nå ut till dig och ge förslag för att göra det enklare, roligare och bättre. De tips som kommer att ges kommer särskilt att relatera till testfall vid acceptanstestning av ERP-system.

vad är testfall?

inom mjukvarutestvärlden finns det många definitioner av testfall. På grund av detta är det viktigt att namnge vår definition. I vår filosofi är testfall (baserat på IEEE610): “en uppsättning testingångar, exekveringsförhållanden och förväntade resultat utvecklade för ett visst mål.”Att veta hur man skriver bra testfall är extremt användbart för alla som vill testa. Oavsett om det är ett funktionstest, ett användaracceptanstest, testa en webbapplikation eller en modul i ett ERP-system. I alla situationer som beskrivs ovan testfall avgöra i vilken utsträckning resultaten ger en dom på de förinställda målen.

Varför är det så svårt att skriva testfall?

som beskrivs i definitionen hjälper testfall att vägleda testare genom en sekvens av testinstruktioner för att avgöra om programvaran uppfyller de fördefinierade kraven eller inte. Genomförandet av testfall hjälper oss att samla in och upptäcka information för att förverkliga det specifika målet eller målet. Det första problemet vi direkt stöter på är mångfalden av möjliga mål. Och eftersom det finns olika typer av test och mål finns det olika typer av motsvarande testfall.

ett andra problem är relaterat till innehållet i den faktiska testinstruktionen eller stegen. Nivån på dessa instruktioner är beroende av vilken typ av testare som måste tolka denna information och ge ett yttrande. En professionell testare behöver olika instruktioner i motsats till en slutanvändare som är involverad i acceptanstestning av ett ERP-system

Tips 1: Bestäm ditt mål och vad du vill rapportera

Tänk på vad du vill rapportera, så att du kan bestämma ditt derivatmål. Med det som bas har du konturerna av testfallet i sikte. Det finns många olika mål, där vi alltid måste fråga oss vad vi försöker lära oss eller uppnå när vi ska köra testet. Här är några exempel:

• hitta defekter: detta är det klassiska syftet med testning. Ett test utförs för att avslöja defekter.
• maximera antalet buggar: Skillnaden mellan” maximera antalet buggar “och” hitta fel ” är att det totala antalet buggar är viktigare än täckningen.
• Blockera för tidiga produktutgåvor: målet med detta test är att i förtid hitta så många allvarliga defekter (showstoppers) så att ingen tar produkten i produktion.
• stöd Chefer med sina go/no-go-beslut: Chefer fattar beslut baserat på risker. Riskindikationer som testtäckning, effekter av problem som hittats etc. Ge dem en bättre bakgrund att basera sina beslut på.
• bedöma överensstämmelse enligt specifikation: de påstådda specifikationerna kontrolleras för deras funktion. Alla frågor som inte är förknippade med specifikationerna beaktas inte.
• bedöma kvaliteten: Detta är ett svårt mål, eftersom kvaliteten är flerdimensionell. Kvaliteten är beroende av produktens natur. För att bedöma kvaliteten bör tydliga kriterier utarbetas, som definieras på ett sätt som de faktiskt kan göras mätbara.

testresultaten som härrör från testfallen ger direkt relevant information om målet.

Tips 2: reservera tillräcklig designtid

reservera tillräckligt med tid för att designa dina testfall, så att de matchar dina mål. Dåliga testfall kommer att hemsöka dig under hela testprocessen. Jämförelse av testresultat, rapportering om flera testrundor etc. Bestäms i huvudsak av kvaliteten på dina testfall.

om du redan har slut på tid att designa, men ändå vill börja testa, se till att du åtminstone har definierat de viktigaste riskerna. Om 10 testare måste granska 5 testfall med 1 teststeg, kommer detta att resultera i 50 testresultat. Oavsett vad dessa 50 Resultat ger mer information om kvalitet och gör ingenting. Detta kommer förmodligen inte att vara uttömmande, men det är ett första steg. Därifrån kan detaljnivån för vissa delar bestämmas.

vi föredrar att du tänker i god tid på hur testet ska utformas och att resultaten av testet ger ett verkligt svar på målet. Men i verkligheten är det ibland orubbligt.

Tips 3: Namn testfall

Namngivning testfall är viktigt. I ett genomsnittligt ERP-test har du enkelt mer än 500 testfall. Du kommer att förstå att en logisk namnstruktur förbättrar sökbarheten. I litteraturen kallas ofta ett komplett som möjligt namn, där den som ska testas process, modul, objekt etc. Alla ingår i namnet. Du kan tänka dig att tillhandahålla 500 testfall med en så komplett titel ger en kaotisk administration. Med ett enkelt Excel-ark förlorar du enkelt översikten. Testhanteringsverktyg ger en struktur som du kan relatera testfall till återanvändbara objekt, utan att de “förorenar” namnet. Du har också testregistreringsverktyg som organiserar dessa relationer på ett annat sätt.

inom TestMonitor till exempel uppfann vi en annan lösning. I verktyget kan du definiera etiketter eller taggar som du sedan kan länka till testfall. Inom TestMonitor är testfallen kopplade till en eller flera affärsprocesser, risk -, krav-eller applikationsetiketter. Detta gör att testfall kan grupperas och hämtas från olika perspektiv.

för namnet på ett testfall inom TestMonitor räcker det med en tydlig beskrivning av syftet med testfallet. För att göra det enkelt beskriver du en aktivitet med en implicit förväntan.

exempel på testfallsnamn:
“uppsägning av hyresavtal-oberoende hem”
” skapa kund “”preliminärt bokningskvitto”
etc.

exempel på testfall “provisoriskt bokningskvitto” som är kopplat till flera etiketter:

• affärsprocess ‘ta emot varor’
• krav ‘kontraktskrav’
• risk ‘operativ risk’
• ansökan ‘ERP’

det är viktigt att beskriva det förväntade resultatet per testfall. Testaren vet då i vilken riktning “svaret” behöver vara och får direkt ett uttryckligt testramverk.

Tips 4: teststegsbeskrivning

som beskrivs i definitionen är testfall en samling testinstruktioner som hjälper oss att upptäcka information för att uppnå ett visst mål.

ett testfall måste ha en tydlig början och slut för att avgöra om testfallet passerade eller misslyckades. Dessutom består ett testfall av en eller flera testinstruktioner eller-steg, där det finns flera vägar möjliga för att uppnå önskat resultat. Att bara testa vägen för framgång är ofta otillräcklig. I vissa situationer efter icke-framgång vägar kan bara göra skillnaden.

det är viktigt att definiera teststeg så tydligt som möjligt så att slutanvändaren för ett användaracceptanstest vet exakt vad de måste göra. Naturligtvis finns det förutsättningar att komma med, som funktionell nivå tester, kunskap om det nya systemet, kunskap om möjliga justerade affärsprocesser, etc. Men i huvudsak borde alla förstå alla teststeg.

Antag att vi vidare beskriver testfallet “Lease termination-independent home” för en enkel framgångsväg:

1. välj en enhet och börja uppsägning hyresavtalet. Kontrollera om det finns förutsättningar bland vilka uppsägning av hyresavtal kan/inte accepteras och skapa ett register över detta.
2. planera en tid för slutbesiktningen.
3. fyll i data på skärmen uppsägning av hyresavtalet. Dubbelkolla hyresgästen uppgifter i hyresavtalet uppsägning kortet.
4. registrera uppsägningen av hyresavtalet och skicka ett konformationsbrev. Kontrollera om bekräftelsebrevet har kommit i det digitala arkivet.
5. kontrollera i kontraktsregistret från enheten att det nuvarande kontraktet sägs upp, att det uppsagda kontraktet är kopplat till uppsägning av hyresavtalet och att det finns ett nyskapat vakansavtal.
6. kontrollera det nya (lediga)kontraktet baserat på hyrespolicyn och elementmallarna.

vad märker du?

• varje teststeg börjar med ett verb
• följt av ett ämne
• avslutande med detaljering och eventuellt kontrollfrågor. Du kan välja att sätta kontrollfrågorna i separata teststeg, men övningen visar att kontrollfrågan är en förfining av åtgärden och sedan logiskt kommer att skrivas ner som ett teststeg.

i ovanstående exempel antas att en specialist från ett visst område kommer att utvärdera teststeget. Och eftersom han eller hon är specialist, ges inga inmatningsvillkor eller uttryckliga förväntningar, eftersom specialisten fortfarande har sina egna fallstudier i ärmen och hans förväntningar är kristallklara.

om du för närvarande inte har en specialist kan du utöka teststegen med inmatningsförhållanden och uttryckliga förväntningar.

till exempel teststeg 1 i testfallet “uppsägning av hyresavtal – oberoende hem” med mer information.

1. välj enheten “Fleet street 677” och börja uppsägning av hyresavtalet. Villkoren säkerställer att denna enhet inte kan avslutas innan efterskott har betalats.
2. etc.

Tips 5: Inte mer än 10 testinstruktioner i 1 testfall

vi stöter regelbundet på testprojekt där >50 teststeg tilldelas ett testfall. Detta är för mycket av några skäl:

• alla teststeg måste tas separat (eller uttryckligen godkännas) innan ett testfall får en dom.
• den slutliga bedömningen av ett testfall bestäms av den “värsta” poängen. Så det kan mycket väl vara att 49 teststeg kommer att bedömas som” bra “och en som” fel “vad resulterar i ett” fel ” testfall. Mätningen av provningsstegen skall vara likartad. Med det menar jag att praktiskt taget varje teststeg måste vara lika med effekten av utvärderingen. Om du har 10 teststeg måste du följa, inklusive 2 små teststeg som de är oproportionerliga mot de andra 8 teststegen, måste du omformulera dem. Detsamma gäller tvärtom med ett tufft teststeg.
• testaren går snabbt vilse med för många teststeg i ett testfall. Vi har inte gjort en vetenskaplig studie om det, men praxis visar att ett testfall inte bör innehålla mer än 10 teststeg. Man kan tänka på många undantag (konverteringskontroller, etc), men i praktiken för ett användaracceptanstest av ett ERP-system fungerar det bäst.
• det är svårt för utvecklare att reproducera det fel som hittats. Med många teststeg kommer utvecklaren att förlora mycket tid på att försöka återskapa situationen.
• Repriser eller retest av stora testfall tar för mycket tid. När ett fel upptäcks av en testare måste motsvarande testfall testas igen. En retest kräver att mycket steg kommer att omprövas, du vill förhindra regressionsfel självklart. Genom att ta för många teststeg testar du troligtvis för mycket. På så sätt tar testprocessen längre tid och kan så småningom överbelasta dina testare.

förutom det har du också testregistreringsverktyg som kan presentera testfallen i olika former för testaren. TestMonitor har till exempel två olika vyer. TestMonitor har en display som visar alla teststeg separat per sida och en display där testfall presenteras per sida inklusive alla teststeg.Fördelen med den första displayen är att varje testare kan få mer information för varje teststeg. Nackdelen om testaren är mer erfaren måste han klicka på” Nästa ” varje gång han vill gå vidare till nästa teststeg. I den andra vyn för varje testfall är fördelarna och nackdelarna vice versa.

Tips 6: granskning av en icke-designer/leverantör

i praktiken ser vi regelbundet testskript som utarbetats av programleverantörens programmerare. När du granskar dessa testskript av de eventuella testarna finns det vanligtvis fler frågor än svar. Omvänt fungerar detta på samma sätt för testskript som utarbetats av sin egen medarbetares. Det ger ett verkligt mervärde genom att granska dessa av mjukvaruleverantören. De tittar på de färdiga testskripten med olika ögon och kommer alltid med meningsfulla tillägg eller ändringar.

med lite brainstorming med mjukvaruleverantörsspecialisterna och kundorganisationen får du snabbt fokus på kärnan i det som behöver testas. Ta dig tid att överväga testfall, icke-framgångsscenarier och du kommer att se att din testmodell snabbt blir mer omfattande och detaljerad. Dessutom får du mer information om kvaliteten då du ansåg möjligt.

Tips 7: TestMonitor

förutom att använda en professionell testplattform och göra kvalitet riktigt insiktsfull. Begär en gratis testversion av TestMonitor idag och se och uppleva skillnaden själv.

om du är en nykomling i testvärlden blir du lätt överväldigad av all testterminologi som kastas runt. I den här artikeln försöker vi förklara en del av jargongen du kan stöta på i ditt dagliga testliv, bara för att göra allt lite mer förståeligt.

börja testa med TestMonitor

inte en TestMonitor-användare ännu? Bra och enkla tester är nyckelprioritering för kvalitetssäkringschefer, testchefer, IT-chefer, testchefer och release manager. TestMonitor gör testning enkelt och roligt för testanvändare också.

så låt oss komma igång. Du kanske vill kolla in vår video eller ladda ner produktbroschyren. Men självklart, med en gratis provperiod kan du verkligen uppleva användarvänligheten av TestMonitor själv.

hålla kontakten? Följ TestMonitor på Twitter och LinkedIn.