7 Tips voor het schrijven van testcases om uw testproces voor ERP-Software te verbeteren
testcases zijn erg belangrijk om de kwaliteit van uw testproces voor ERP-software te garanderen. Het zijn de eerste stappen in een testcyclus en als testcases niet van voldoende kwaliteit zijn, wordt het hele project ‘belast’. Het schrijven van “grote” testcases is een vaardigheid die vorm krijgt door het gewoon te doen. Maar het is erg handig om wat inzichten te hebben die je kunnen helpen. Met dit artikel wil ik contact met u opnemen en suggesties geven om het gemakkelijker, leuker en beter te maken. De tips die zullen worden gegeven zullen in het bijzonder betrekking hebben op testcases bij acceptatietesten van ERP-systemen.
wat zijn testgevallen?
binnen de wereld van het testen van software zijn er veel definities van testgevallen. Daarom is het belangrijk om onze definitie te noemen. In onze filosofie testcases zijn (gebaseerd op IEEE610): “een set van testingangen, uitvoeringsvoorwaarden en verwachte resultaten ontwikkeld voor een bepaald doel.”Weten hoe je goede testcases moet schrijven is uiterst nuttig voor iedereen die wil testen. Of het nu gaat om een functionele test, een gebruikerstoets, het testen van een webapplicatie of een module van een ERP-systeem. In alle hierboven beschreven situaties bepalen de testcases in hoeverre de resultaten een oordeel geven over de vooraf vastgestelde doelstellingen.
Waarom is het schrijven van testcases zo moeilijk?
zoals beschreven in de definitie, helpen testcases testers door een reeks testinstructies te leiden om te bepalen of de software al dan niet voldoet aan de vooraf gedefinieerde eisen. Het uitvoeren van testcases helpt ons om informatie te verzamelen en te ontdekken om dat specifieke doel of doel te realiseren. Het eerste probleem dat we direct tegenkomen is de diversiteit van mogelijke doelstellingen. En omdat er verschillende soorten testen en doelen zijn, zijn er verschillende soorten overeenkomstige testcases.
een tweede probleem houdt verband met de inhoud van de eigenlijke testinstructie of-stappen. Het niveau van deze instructies is afhankelijk van het type tester dat deze informatie moet interpreteren en een advies moet geven. Een professionele tester heeft andere instructies nodig dan een eindgebruiker die betrokken is bij acceptatietests van een ERP-systeem
Tip 1: Bepaal uw doel en wat u wilt rapporteren
denk na over wat u wilt rapporteren, zodat u uw afgeleide doel kunt bepalen. Als je dat als basis gebruikt, heb je de omtrek van de TestCASE in zicht. Er zijn veel verschillende doelen, waarbij we ons altijd moeten afvragen wat we proberen te leren of te bereiken wanneer we de test gaan uitvoeren. Hier zijn enkele voorbeelden:
- defecten vinden: dit is het klassieke doel van testen. Er wordt een test uitgevoerd om defecten aan het licht te brengen.
- maximaliseer het aantal bugs: Het onderscheid tussen” maximaliseren van het aantal bugs “en” het vinden van gebreken ” is dat het totale aantal bugs is belangrijker dan de dekking.
- premature productuitgifte blokkeren: het doel van deze test is om voortijdig zoveel ernstige defecten (showstoppers) op te sporen, zodat niemand het product in productie neemt.
- steun managers met hun go / no-go-beslissingen: Managers nemen beslissingen op basis van risico ‘ s. Risico-indicaties zoals testdekking, impact van gevonden problemen, enz. Hen een betere achtergrond geven waarop zij hun beslissingen kunnen baseren.
- conformiteitsbeoordeling Volgens Specificatie: de vermeende specificaties worden gecontroleerd op hun werking. Alle zaken die niet in verband staan met de specificaties worden buiten beschouwing gelaten.
- de kwaliteit beoordelen: Dit is een moeilijke doelstelling, omdat kwaliteit multidimensionaal is. De aard van de kwaliteit is afhankelijk van de aard van het product. Om de kwaliteit te beoordelen moeten duidelijke criteria worden opgesteld, die zodanig worden gedefinieerd dat ze daadwerkelijk meetbaar kunnen worden gemaakt.
de testresultaten zoals afgeleid uit de testcases leveren directe relevante informatie over het doel.
Tip 2: reserveer voldoende ontwerptijd
reserveer voldoende tijd om uw testcases te ontwerpen, zodat ze overeenkomen met uw doelen. Slechte testcases zullen je achtervolgen gedurende het hele testproces. Vergelijking van testresultaten, rapportage over verschillende testrondes, enz. Worden hoofdzakelijk bepaald door de kwaliteit van uw testcases.
als u al geen tijd meer hebt om te ontwerpen, maar nog steeds wilt beginnen met testen, zorg er dan voor dat u tenminste de belangrijkste risico ‘ s hebt gedefinieerd. Als 10 testers 5 testgevallen met 1 teststap moeten beoordelen, resulteert dit in 50 testresultaten. Het maakt niet uit wat deze 50 Resultaten geven meer informatie over kwaliteit dan niets doen. Dit zal waarschijnlijk niet uitputtend zijn, maar het is een eerste stap. Van daaruit kan het detailniveau van bepaalde onderdelen worden bepaald.
wij geven er de voorkeur aan dat u ruim van tevoren nadenkt over de opzet van de test en dat de resultaten van de test een reëel antwoord geven op het doel. Maar in werkelijkheid is dit soms onhandelbaar.
Tip 3: Naam testcase
naam testcases is belangrijk. In een gemiddelde ERP-test heb je gemakkelijk meer dan 500 testcases. U zult begrijpen dat een logische naamstructuur de vindbaarheid verbetert. In de literatuur wordt vaak verwezen naar een volledige naam, waarin het te testen proces, module, object etc. Zijn allemaal opgenomen in de naam. Je kunt je voorstellen dat het verstrekken van 500 testcases met zo ‘ n volledige titel een chaotische administratie geeft. Met een eenvoudig Excel-blad verliest u gemakkelijk overzicht. Test management tools bieden een structuur waarmee je testcases kunt relateren aan herbruikbare objecten, zonder dat ze de naam “vervuilen”. Je hebt ook testregistratietools die deze relaties op een andere manier organiseren.
binnen TestMonitor hebben we bijvoorbeeld een andere oplossing uitgevonden. In de tool kunt u labels of tags definiëren die u vervolgens kunt koppelen aan testcases. Binnen TestMonitor zijn de testcases gekoppeld aan één of meerdere bedrijfsprocessen, risico ‘ s, vereisten of applicatielabels. Hierdoor kunnen testcases vanuit verschillende perspectieven worden gegroepeerd en opgehaald.
voor de naam van een testcase binnen TestMonitor volstaat een duidelijke beschrijving van het doel van de TestCASE. Om het eenvoudig te maken beschrijf je een activiteit met een impliciete verwachting.
voorbeeld testnaam:
“beëindiging van de huur – zelfstandige woning”
“Create customer” “Provisional booking receipt”
etc.
voorbeeld van testcase “Provisional booking receipt” die is gekoppeld aan verschillende labels:
- bedrijfsproces “ontvangende goederen”
- vereiste “Contractvereiste”
- risico “operationeel risico”
- toepassing “ERP’
het is belangrijk om het verwachte resultaat per testcase te beschrijven. De tester weet dan in welke richting het” antwoord ” moet zijn en krijgt direct een expliciet testkader.
Tip 4: Beschrijving van de Teststap
zoals beschreven in de definitie testcases zijn een verzameling testinstructies die ons helpen informatie te vinden om een bepaald doel te bereiken.
een testcase moet een duidelijk begin en einde hebben om te bepalen of de TestCASE geslaagd of mislukt is. Bovendien is een testcase samengesteld uit een of meer testinstructies of-stappen, waarbij er meerdere paden mogelijk zijn om het gewenste resultaat te bereiken. Alleen het testen van het pad van succes is vaak onvoldoende. In bepaalde situaties kan het volgen van niet-succesvolle paden gewoon het verschil maken.
het is belangrijk de teststappen zo duidelijk mogelijk te definiëren, zodat de eindgebruiker voor een gebruikerstoets precies weet wat hij moet doen. Natuurlijk zijn er voorwaarden om te komen met, zoals functional level tester, kennis van het nieuwe systeem, kennis van de mogelijke aangepaste bedrijfsprocessen, enz. Maar in essentie moet iedereen alle teststappen begrijpen.
stel dat we de TestCASE “Lease termination – independent home” verder beschrijven voor een eenvoudig succespad:
- selecteer een eenheid en start beëindiging van de huurovereenkomst. Controle als er voorwaarden waaronder de beëindiging van de huurovereenkomst kan/niet worden aanvaard en maak een record van deze.
- Maak een afspraak voor de eindcontrole.
- vul de gegevens in het scherm beëindiging van de huurovereenkomst. Controleer de huurdergegevens in de leasebeëindigingskaart dubbel.
- Registreer de beëindiging van de huurovereenkomst en stuur een conformatiebrief. Controleer of de bevestigingsbrief in het digitale archief is aangekomen.
- Controleer in het contractregister van de eenheid dat het lopende contract wordt beëindigd, dat het opgezegd contract gekoppeld is aan de beëindiging van de huurovereenkomst en dat er een nieuw gecreëerde vacaturecontract is.
- controleer het nieuwe (vacature)contract op basis van het huurbeleid en de templates voor elementen.
wat valt u op?
- elke teststap begint met een werkwoord
- gevolgd door een onderwerp
- dat wordt afgesloten met gedetailleerde en mogelijk controlevragen. U kunt ervoor kiezen om de controlevragen in afzonderlijke teststappen te plaatsen, maar de praktijk toont aan dat de controlevraag een verfijning van de actie is en dan logischerwijs als een teststap wordt opgeschreven.
in bovengenoemd voorbeeld wordt aangenomen dat een specialist uit een bepaald vakgebied de teststap zal evalueren. En omdat hij of zij een specialist is, worden geen inputvoorwaarden gegeven of expliciete verwachtingen geschetst, omdat de specialist nog steeds zijn eigen casestudy ‘ s in zijn mouw heeft en zijn verwachtingen glashelder zijn.
indien u momenteel geen specialist hebt, kunt u de teststappen uitbreiden met invoervoorwaarden en expliciete verwachtingen.
bijvoorbeeld teststap 1 bij de TestCASE “beëindiging van huur – zelfstandige woning” met meer details.
- Selecteer de eenheid “Fleet street 677” en start de beëindiging van de huurovereenkomst. De voorwaarden zorgen ervoor dat deze eenheid niet kan worden beëindigd voordat de achterstallige betalingen zijn voldaan.
- enz.
Tip 5: Niet meer dan 10 testinstructie in 1 testcase
we komen regelmatig testprojecten tegen waarbij >50 teststap aan één testcase worden toegewezen. Dit is te veel om een paar redenen:
- alle teststappen moeten afzonderlijk (of expliciet geslaagd) worden genomen voordat een testcase een oordeel krijgt.
- de uiteindelijke beoordeling van een testcase wordt bepaald door de “slechtste” score. Het kan dus goed zijn dat 49 teststappen als “goed” worden beoordeeld en één als “verkeerd” wat resulteert in een “verkeerde” testcase. De meting van de teststappen moet hierbij gelijk zijn. Daarmee bedoel ik dat vrijwel elke teststap gelijk moet zijn aan het effect van de evaluatie. Als u 10 teststappen moet volgen, inclusief 2 kleine teststappen die niet in verhouding staan tot de andere 8 teststappen, moet u ze anders formuleren. Hetzelfde geldt omgekeerd met een zware teststap.
- de tester raakt snel verloren met te veel teststappen binnen een testcase. We hebben er geen wetenschappelijk onderzoek over gedaan, maar de praktijk toont aan dat een testcase niet meer dan 10 teststappen mag bevatten. Er zijn veel uitzonderingen te bedenken (conversie controles, enz.), maar in de praktijk werkt dit voor een acceptatietest van een ERP systeem het beste.
- het is moeilijk voor ontwikkelaars om de gevonden fout te reproduceren. Met veel teststappen zal de ontwikkelaar veel tijd verliezen om de situatie na te spelen.
- herhalingen of hertesten van grote testcases kost te veel tijd. Wanneer een fout wordt gedetecteerd door een tester, moet de bijbehorende testcase opnieuw worden getest. Een hertest vereist dat zeer stap zal opnieuw worden beoordeeld, u wilt regressiefouten uiteraard voorkomen. Door te veel teststappen te nemen, ben je waarschijnlijk te veel aan het testen. Op deze manier duurt het testproces langer en kan het uiteindelijk uw testers overbelasten.
daarnaast hebt u ook testregistratietools die de testcases in verschillende vormen aan de tester kunnen presenteren. TestMonitor bijvoorbeeld heeft twee verschillende view. TestMonitor heeft een display dat alle teststappen afzonderlijk per pagina toont en een display waarin de testcases per pagina worden gepresenteerd, inclusief alle teststappen.Het voordeel van het eerste display is dat elke tester meer informatie kan verkrijgen voor elke teststap. Het nadeel in het geval de tester is meer ervaren moet hij klikken op “next” elke keer dat hij wil overgaan tot de volgende test stap. In de andere visie voor elk testcase zijn de voor-en nadelen vice versa.
Tip 6: beoordeling door een niet-ontwerper/leverancier
in de praktijk zien we regelmatig testscripts opgesteld door de programmeurs van de softwareleverancier. Bij het beoordelen van deze test scripts door de uiteindelijke testers, zijn er meestal meer vragen dan antwoorden. Omgekeerd, dit werkt hetzelfde voor test scripts opgesteld door hun eigen werknemer. Het geeft een echte toegevoegde waarde het beoordelen van deze door de softwareleverancier. Ze kijken naar de voltooide test scripts met verschillende ogen en komen altijd met zinvolle toevoegingen of wijzigingen.
met een beetje brainstormen met de specialisten van de softwareleveranciers en de klantorganisatie krijgt u snel aandacht voor de essentie van wat moet worden getest. Neem dan de tijd om de testcases, niet-successscenario ‘ s te overwegen en u zult zien dat uw testmodel snel uitgebreider en gedetailleerder wordt. Daarnaast krijg je meer informatie over de kwaliteit dan je voor mogelijk hield.
Tip 7: TestMonitor
daarnaast gebruik maken van een professioneel testplatform en maken kwaliteit echt inzichtelijk. Vraag vandaag nog een gratis proefversie van TestMonitor aan en zie en ervaar het verschil zelf.
als u een nieuwkomer bent in de wereld van testen, raakt u gemakkelijk overweldigd door alle testterminologie die rond wordt gegooid. In dit artikel, we zullen proberen om een aantal van de jargon die u zou kunnen tegenkomen in uw dagelijkse testen leven uit te leggen, gewoon om het allemaal een beetje begrijpelijker te maken.
begin met testen met TestMonitor
contact houden? Volg TestMonitor op Twitter en LinkedIn.
Leave a Reply