Menu

Testcases schrijven vanuit SRS-document (DOWNLOAD Live Project-voorbeeldtestcases)

writing test cases from srs document

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Testcases schrijven vanuit SRS-document (download live projectvoorbeeld testcases) - Software testen QA-training dag 4

Gewoon om te herhalen wat we tot nu toe hebben gedaan - we werken ons een weg door de Training voor softwaretests mini-cursus op een live project OrangeHRM.

In deze gratis online QA-trainingsreeks tot nu toe zijn we klaar met:

  1. SRS-beoordeling,
  2. Testscenario / testscope identificatie en
  3. Documenteerde het testplan ​

Testcases schrijven vanuit SRS-document

Nu hebben we het deel bereikt dat de echte deal is,de testgevallen​

Zoals aangegeven in het artikel hiervoor: Testgevallen worden gedocumenteerd door het QA-team terwijl de codefase van de SDLC aan de gang is. Met andere woorden, terwijl het Dev-team het softwaresysteem bouwt, maakt het testteam zich klaar met de testcases die ons zouden helpen het systeem te testen zodra het klaar is, d.w.z. aan het einde van de codefase.

Daarom zullen we in het artikel van vandaag proberen te begrijpen wat testcases zijn, hoe we ze kunnen maken en een paar voorbeeldtestcases schrijven voor ons live-project.

Laten we er meteen aan beginnen.

Wat je leert:

Basisprincipes van het schrijven van testcases

# 1) Als testscenario's allemaal over gingen: 'Wat gaan we testen' op de AUT - de testcases gaan allemaal over “Hoe we een vereiste gaan testen”.

Bijvoorbeeld , als het testscenario is 'Valideer de Admin login-functionaliteit' - Dit zou in 3 testgevallen (of voorwaarden) opleveren - Login (succesvol), Login-niet succesvol wanneer de verkeerde gebruikersnaam is ingevoerd, Login-niet succesvol wanneer het onjuiste wachtwoord is ingevoerd . Elk testgeval zou op zijn beurt stappen bevatten om aan te pakken hoe we kunnen controleren of aan een bepaalde testvoorwaarde is voldaan of niet.

#twee) De input om een ​​testcase-document te maken is FRD, testscenario's die in de eerdere stap zijn gemaakt en eventuele andere referentiedocumenten, indien aanwezig.

# 3) De testcase-documentatie is een belangrijk resultaat van het QA-team en wordt gedeeld met BA, PM en andere teams wanneer ze klaar zijn voor hun feedback.

# 4) Het werk wordt verdeeld over de teamleden en elk lid is verantwoordelijk voor het maken van testcases voor een bepaalde module of een deel van een bepaalde module.

# 5) Net als bij de testscenario's, moet voordat we beginnen met de documentatie van de testcase, een gemeenschappelijk sjabloon worden afgesproken. Vrijwel alles kan worden gebruikt om testcases te maken. De 2 meest gebruikte keuzes zijn MS Excel en MS Word.

# 6) De MS Word-sjabloon ziet er ongeveer zo uit:

Testcases MS Word-sjabloon

# 7) De Excel-sjabloon zou er als volgt uit kunnen zien:

qa training testcases samples xls

# 8) Uit de bovenstaande twee sjablonen kan worden opgemerkt dat de velden (of de componenten) waaruit een testcase bestaat, hetzelfde zijn, het enige verschil is de manier waarop ze zijn georganiseerd.

Dus zolang er een veld is voor elk van de soorten informatie die in een test moeten worden opgenomen, doet het formaat van de sjabloon er niet toe. Mijn persoonlijke favoriet is echter toevallig het Excel-blad, omdat het gemakkelijk is uit te vouwen, samen te vouwen, te sorteren, enz. Maar nogmaals, kies elk formaat dat het beste bij je past.

Velden in testcases

Laten we even de tijd nemen om de velden te bekijken die deel uitmaken van een testcase.

Testcase-ID en Testcase-beschrijving zijn de generieke.

De andere velden zijn als volgt te verklaren:

  • Voorwaarde: Staat van de AUT (de staat waarin de AUT moet zijn om te kunnen beginnen).
  • Invoer: Stappen voor gegevensinvoer. Voor deze stappen is het belangrijk om op te merken wat voor soort invoerinformatie vereist is: testgegevens.
  • Validatiepunt / trigger / actie : Wat veroorzaakt de validatie? (Klik op een knop of schakelaar of de linktoegang. Zorg ervoor dat er ten minste één validatiepunt is voor een testcase - anders wordt het allemaal gegevensinvoer zonder iets om naar te zoeken. Ook om ervoor te zorgen dat we voldoende modulariteit hebben, probeer niet te veel validatiepunten in één testcase te combineren. 1 per testcase is optimaal.)
  • Uitgang: Verwacht resultaat.
  • Nabehandeling: Dit is aanvullende informatie die wordt verstrekt ten behoeve van de tester, alleen om de testcase inzichtelijker en informatief te maken. Dit omvat een uitleg van wat er gebeurt of wat er van de AUT kan worden verwacht als alle testcase-stappen zijn voltooid.

Zie ook => Voorbeeld testcase-sjabloon

Voorbeeldtestcases voor live projecten (download)

Nu we voldoende achtergrondinformatie hebben om aan de slag te gaan met het maken van testcases, gaan we aan de slag en enkele testcases maken voor ons Live Project.

Op basis van het hierboven genoemde proces hebben we enkele voorbeeldtestcases gemaakt voor de OrangeHRM-accountmodule. Deze zouden u een exacte testcase-indeling en een idee moeten geven over hoe u het schrijven van testcases kunt benaderen.

​ Download hier het voorbeeldtestcases-document voor ons live-project ​

Notitie: Er zijn enkele afbeeldingen verwezen naar voorbeeldtestcases XLS-document. Als u dit in de oudere MS Office-versie bekijkt, kunt u compatibiliteitsproblemen ondervinden.

We hebben die afbeeldingen hieronder opgesomd volgens hun naam in de XLS-bestanden:

Bekijk Pic 1
Bekijk Pic 2
Bekijk Pic 3

Daar, allemaal gedaan en allemaal goed.

Testcases schrijven / optimalisatiemethoden

Stel je nu een situatie voor waarin een bepaalde pagina een paar tientallen velden bevat of een complexe bedrijfslogica heeft die daarin is geïmplementeerd. Om ervoor te zorgen dat we het proces voor het maken van testcases in dergelijke situaties optimaliseren, hebben wij testers bepaalde testcase-optimalisatiemethoden.

Hieronder staan ​​de links vermeld voor meer informatie over deze methoden.

apps waarmee je YouTube-video's kunt downloaden

Met behulp van de bovenstaande technieken en door het algemene proces voor het maken van testcases te volgen, creëren we een reeks testcases die de aanwezige applicatie effectief zouden testen.

Enkele belangrijke punten om op te merken

  • De testcases die we maken zijn niet alleen het referentiepunt voor de QA-fase, maar ook voor de UAT.
  • Intern zijn testcases Peer-reviewed binnen het team ​
  • Wanneer een bepaalde situatie niet wordt aangepakt door een testcase - de vuistregel is dat deze niet wordt getest. Dit is dus een goede plek om te controleren of de testsuite die we hebben gemaakt het doel van 100% testdekking bereikt of niet. Hiervoor kan een traceerbaarheidsmatrix worden gemaakt. Bekijk alles wat er te weten valt over de Traceerbaarheidsmatrix hier ​
  • Tools - Testbeheertools zoals QC ​ qTest help ons bij het maken van testcases. Kijk hier voor een voorbeeld van hoe testcases kunnen worden afgehandeld met Quality Center Tutorial van Quality Center ​
  • Automatiseringstools kunnen worden gebruikt om testcases te maken, in welk geval ze worden aangeduid als testscripts.
Pro-tip ​Voer een spelling- en grammaticacontrole uit voor elk document dat we maken. Wij zijn de kwaliteitsvertegenwoordigers voor IT-projecten - en het is niet positief voor ons als onze deliverables zelf van inferieure kwaliteit zijn.

Dat brengt ons bij de finish van een ander interessant segment.

Gevolgtrekking

Het einde van het testcreatieproces / testontwerpfase (STLC) en het einde van de codefase (SDLC) markeren over het algemeen het einde van de testvoorbereidingsfase en het begin van de testuitvoeringsfase.

Volgende tutorial in deze cursus Software Testing ​ In het komende artikel zullen we bespreken wat Test Execution is, wat het inhoudt en wat de verwachtingen zijn van het QA-team tijdens deze fase.

​ QA-training dag 5: Testuitvoering

We hopen dat jullie allemaal aan deze serie meewerken. Eenvoudigheidshalve zijn er maar een paar testcases gemaakt. De beste resultaten zie je echter als je uitgebreid aan testen werkt, wat betekent dat je steeds meer testcases schrijft. Beperk uw werk dus niet en doe zoveel mogelijk.

Laat het ons hieronder weten wat uw vragen en opmerkingen zijn. Veel plezier met testen!

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

^