Hoe testgevallen te schrijven

Er is geen twijfel over mogelijk dat het schrijven van effectieve Test Cases een must is voor QA specialisten. Zoals elke vaardigheid kan ook deze vaardigheid worden verworven en verbeterd. De belangrijkste principes en tips van het effectief schrijven van Test Cases zullen in dit artikel worden behandeld.

Voordat we beginnen, moeten we eerst goed begrijpen wat een Test Case is. Stel je voor dat je een bepaalde functionaliteit van de applicatie moet testen. U moet stap voor stap de situatie waarin het zou kunnen worden geïmplementeerd.

Eenvoudig gezegd, Test Case is een set van dergelijke goed ontworpen en gemakkelijk te begrijpen stappen (acties) uitgevoerd om een bepaalde functie of functionaliteit van uw software applicatie te verifiëren. Houd in je gedachten “goed ontworpen” en “gemakkelijk te begrijpen”. Het heeft een belangrijke betekenis zoals je verderop zult zien.

Dus, nu kunnen we beginnen. Hier zullen we de Test Case in onderdelen verdelen en proberen te analyseren wat wel en wat niet moet worden gedaan om het met hoge efficiëntie te schrijven.

Test Case ID

Dit is een uniek nummer van de Test Case in het test management systeem of in het document. In de regel wijzen alle moderne test management systemen zoals Jira, TestRail, en Zephyr automatisch een ID toe aan een nieuw aangemaakte Test Case. Dus, er is geen mogelijkheid om een fout te maken met dit onderdeel.

Maar, het moet worden opgemerkt, dat op sommige projecten wordt nog steeds gebruikt Excel voor het testen. Daarom moet je altijd de regel onthouden: “Er zijn geen Test Cases met dezelfde ID in je test management systeem. Zelfs dit zijn Test Cases van afgeronde projecten”.

Test Case Title

Strong Title is het verplichte attribuut van de effectieve Test Case. Wat houdt het in? De belangrijkste kenmerken van een sterke Titel zijn: makkelijk te begrijpen en laconiek. Daarnaast moet de titel van de Test Case de naam van de module of het functionele gebied dat u gaat verifiëren weergeven.

Stel u voor dat we een taak hebben om te controleren wat er gebeurt als we ongeldige symbolen zoals $,&, * invoeren in het “e-mail” veld van het registratieformulier van Test Management Systeem EasyQA. Volgens de bovenstaande principes zou de titel van de testcase er als volgt uit moeten zien: “E-mail veld ongeldige invoer in het registratieformulier”.

Laten we eens kijken naar het voorbeeld van een niet sterke titel. “E-mail veld “$&*” symbolen input in het Registratie formulier van de “EasyQA”. Hier hebben we ten minste twee fouten.

• De buitensporige lengte van de titel. Het is niet nodig om “EasyQA” te vermelden, omdat deze Test Case een onderdeel is van het Test Plan voor dit Test Management Systeem. Dus alle testgevallen hebben betrekking op “EasyQA”.
• Concretisering van de speciale symbolen “$&*”. Andere ongeldige symbolen kunnen ook worden ingevoerd voor het uitvoeren van dit soort testgevallen. Dus “ongeldige symbolen” is een betere definitie voor deze titel.

Enkele Test Management Systemen, waaronder EasyQA, vereenvoudigen dit proces door voor elke Test Case een speciaal moduleveld aan te maken.

Test Plan is onderverdeeld in modules, die bepaalde Test Cases bevatten. Daarom is het gemakkelijker om een sterke titel voor een testcase te maken.

Testcasebeschrijving

Voordat u met testen begint, moet u alle details vermelden over wat u gaat testen. Dit zijn: Test Data to be used, Preconditions (Presteps), Test Environment Details, Testing Tools.

Als je Test Data to be used wherever applicable for the Test Case binnen de test case beschrijving of bij de specifieke Test Case stap geeft, help je niet alleen jezelf, maar ook je collega-testers. Het is een ernstige fout om Test Cases alleen voor jezelf te schrijven.

Precondities (Presteps) beschrijven verschillende soorten afhankelijkheden van de Testuitvoering:

• Er moet een speciale set-up worden gedaan
• Afhankelijkheden van andere Test Cases – moet de Test Case voor/na een andere Test Case worden uitgevoerd
• Afhankelijkheid van gebruikersgegevens – op welke pagina moet de gebruiker beginnen; de gebruiker moet ingelogd zijn.

Test Omgeving is een setup van software en hardware voor de testteams om testgevallen uit te voeren. Met andere woorden, het ondersteunt testuitvoering met hardware, software en netwerk geconfigureerd.

Wanneer mensen spreken over Tools voor het testen, Geautomatiseerd testen wordt vaak gesuggereerd. Natuurlijk zijn ze eerder betrokken bij dit type van testen. Maar er zijn ook eenvoudige tools voor handmatig testen. Mind mapping tools zoals Xmind, screenshots managers zoals Jing zijn eenvoudig te gebruiken, zelfs voor nieuwkomers op QA gebied. Hoe dan ook, als een speciale tool verplicht is voor het testen, moet je het vermelden in de Test Case beschrijving.

Natuurlijk, als dezelfde tool wordt gebruikt voor de uitvoering van een groep van Test Cases, zou het beter zijn om het te beschrijven op Test Module / Submodule of zelfs in het Test Plan.

Er is een soort van typische fout waar je je op moet richten. Sommige testers met minder ervaring verwarren Steps met Presteps. Let wel, dat Presteps de manier is om de situatie te krijgen waarin de uitvoering van de Test Case kan worden gestart. Stappen zijn de meest effectieve manier om het daadwerkelijke resultaat van de uitvoering van de Test Case te krijgen.

Bijv. als we de functionele mogelijkheden van geregistreerde gebruikers moeten testen, zou het fout zijn om voor elke Test Case in de juiste module speciale stappen voor de registratie van gebruikers te maken. De juiste beslissing is om in de Presteps voor alle registreer gebruiker Test Suites module weer te geven: gebruiker moet worden geregistreerd. Het proces van registratie wordt geverifieerd in een bepaalde Test Suite.

Zoals eerder gezegd, zijn stappen de weg naar het verwachte resultaat. Een ander ding dat moet worden herinnerd Stappen in de effectieve Test Case zijn goed ontworpen en gemakkelijk te begrijpen. Deze twee punten zijn de basis om te begrijpen hoe je Steps voor je Test Cases moet plannen.

De belangrijkste attributen van goed ontworpen Steps:

1. Optimale hoeveelheid Steps. Het is niet nodig om extra stappen te schrijven als “te eten” stap. De dingen die er voor jou duidelijk uitzien, zijn niet zo duidelijk voor je collega’s.
2. Een Test Case dekt slechts één onafhankelijke functionaliteit. Het is een vergissing om verschillende functionaliteit in één Test Case te verifiëren.
3. Steps zijn eenvoudig uitvoerbaar.
4. Steps moeten niet alleen de functionele flow dekken, maar ook elk verificatiepunt dat getest moet worden.

De belangrijkste eigenschappen van eenvoudig te begrijpen Steps:

1. Steps zijn to-the-point. Je moet geen essay schrijven om je Stappen te beschrijven.
2. Heldere uitdrukking. Je moet dubbelzinnigheid vermijden in je Test Case Stappen.
3. Onbegrijpelijk, zelfs voor beginners. Uw collega’s, die waarschijnlijk niet zo ervaren zijn, moeten in staat zijn om te begrijpen hoe elke Stap moet worden uitgevoerd.

De prestaties van de applicatie na het uitvoeren van de bovenstaande teststappen worden weergegeven in het verwachte resultaat. Dus, voordat je Test Cases schrijft, moet je volledig onderkennen welke pagina/scherm je verwacht te zien na de test en welke updates je als resultaat verwacht in back-end systemen of database.

Hoop dat je je herinnert dat één Test Case één onafhankelijke functionaliteit dekt. Daarom zou het een vergissing zijn om een Test Case te schrijven met meer dan één verwacht resultaat.

Commentaar/Post Conditions zijn geen verplichte onderdelen van de Test Case, maar het verhoogt wel de efficiëntie van je Test Case. Hier kun je extra nuttige informatie plaatsen, zoals screenshots en beschrijvingen, om de ontwikkelaars de informatie te geven die ze nodig hebben om eventuele gevonden defecten te corrigeren.

Post Conditions worden ook gebruikt om richtlijnen te geven om het systeem in de oorspronkelijke staat terug te brengen, zodat het niet interfereert met latere tests. Dit is bijvoorbeeld heel nuttig als u de wijzigingen vermeldt die in een Test Data moeten worden aangebracht om deze te kunnen gebruiken voor een latere Test Case voor dezelfde functionaliteit.

Verschillende Test Management systemen bieden verschillende varianten van het Test Case veld. De test case in EasyQA Test Management tool heeft de volgende:

1. Title
2. Module – om de module te kiezen waar onze Test Case betrekking op heeft. – Als u in de module op Case toevoegen drukt, wordt dit veld standaard ingevuld.
3. Type – selecteer een type van de testcase uit de drop-down lijst volgens de volgende beschrijving:

• Positief is een testcase waarbij alleen correcte gegevens worden gebruikt.
• Negatief is een testgeval waarbij niet alleen correcte gegevens worden gebruikt.
• Grens is een testgeval waarbij max/min waarden worden gebruikt.
• Integratie is een onderdeel van integratietesten.
• UI is het testen van een grafische gebruikersinterface.
• Lokalisatie is het testen van locaties, talen etc.

1. Voorstappen
2. Verwacht resultaat

In deze afbeelding ziet u het proces van testcase toevoegen met de ingevulde velden.

Als u de testgevallen hebt toegevoegd, kunt u ze kiezen met de bijbehorende selectievakjes. Nadat u een of enkele testgevallen hebt gekozen, kunt u ze verplaatsen naar de gewenste plaats. U kunt ze bewerken of verwijderen.

Nu, wanneer u enige theoretische kennis heeft over het schrijven van Test Cases, probeer het te gebruiken voor de volgende taakbeslissing.

Taakgegevens:

1. Er is een Test Management Systeem “EasyQA” – https://geteasyqa.com/
2. U moet nagaan of de geregistreerde gebruiker in staat is om een nieuw Test Plan te maken voor het project genaamd “Blogger” volgens de specificatie.
3. User e-mail is “[email protected]”, wachtwoord is “gEORGe52”

Laten we eens kijken hoe je elke stap aanmaakt.

Natuurlijk wordt het unieke ID automatisch toegewezen door het Test Management Systeem dat je gebruikt.

Eerst dien je de juiste titel, module en testscenario voor de Test Case te kiezen. Natuurlijk kan de module “Geregistreerde gebruiker” zijn. En andere Test Cases die de geregistreerde gebruiker functionaliteit testen zullen in deze module worden geplaatst. De sterke titel lijkt op “Test Plan creatie mogelijkheid”. Test scenario is positief.

Zo goed als je de geregistreerde gebruiker functionaliteit moet testen, moet je de weg naar registratie weergeven in de Pre Steps. Deze Pre Steps zullen voor alle Test Cases in de module “Geregistreerde gebruiker” hetzelfde zijn.

In het veld Steps moet je laten zien hoe je het Verwachte resultaat bereikt.

Laten we het verwachte resultaat bepalen als “Geregistreerde gebruiker heeft de mogelijkheid om een testplan te maken”.

We kunnen het resultaat van onze acties zien met behulp van EasyQA Test Management tools.

Laten we eens kijken naar een aantal typische Test Cases op basis van verschillende scenario’s.

De taakgegevens zijn bijna gelijk aan de vorige taak:

1. Er is een Test Management Systeem “EasyQA” – https://geteasyqa.com/
2. “Meld je aan” formulier moet worden getest.
3. Minimale lengte van wachtwoord is 6 symbolen. Maximale lengte is 128 symbolen
4. U kunt alleen Latijnse alfabetletters van A tot Z en cijfers gebruiken in de velden “Login”, “Wachtwoord” en “Bevestig wachtwoord”.

Hier beschouwen we enkele specificaties van dit soort Test Cases creatieproces.

EasyQA “Sign Up” formulier heeft de volgende verplichte velden: “Voornaam”, “Achternaam”, “E-mail”, “Wachtwoord”, en “Bevestig wachtwoord”. Daarnaast zijn er andere velden, zoals “Bedrijf” en “Land”, die niet verplicht zijn, maar ook moeten worden getest. U moet uw “Sign Up” Test Suite module dus onderverdelen in de juiste submodules.

Probeer een aantal typische scenario’s te analyseren: positief, negatief en grens.

Volgens het positieve scenario, voert de ongeregistreerde gebruiker alleen geldige gegevens in alle velden in. U zult dus geen problemen hebben met het maken van dit soort testgevallen. In de onderstaande afbeelding kunt u zien hoe dat er uitziet.

Het verwachte resultaat voor deze testcase is “Latijnse letters en cijfers kunnen in het veld “Wachtwoord” worden ingevoerd”.

Maar wat gebeurt er als de gebruiker ongeldige symbolen in een van de eerder genoemde velden invoert? Dat kunnen we controleren door Test Cases uit te voeren op basis van het Negative Scenario. In feite zijn er genoeg ongeldige invoervarianten. Die kunnen in een speciaal artikel worden behandeld. Hier zijn slechts enkele daarvan:

• “&%$” symbolen invoer
• Spaties invoer
• Leeg veld invoer
• Combinaties van ongeldige en ongeldige symbolen invoer
• Andere gevallen letter invoer etc.

Op de onderstaande afbeelding staat een voorbeeld van negatieve testcases.

Het verwachte resultaat voor deze testcase is “Ongeldige invoer is onmogelijk in het veld “Wachtwoord””.

Let op de voorwaarde – beperking van de lengte van het wachtwoord (6-128 symbolen). Is het mogelijk om geregistreerd te worden met slechts 3 symbolen wachtwoord? Hoe zit het met 150 symbolen wachtwoord? Test Cases geschreven door Boundary Value Testing ontwerp techniek geven u antwoord op deze vragen.

Het basis idee in Boundary Value Testing is om input variabele waarden te selecteren op hun: minimum, net boven het minimum, net onder het maximum, maximum. In ons voorbeeld zou je Test Cases moeten schrijven voor situaties met:

• 5 symbolen wachtwoord invoer
• 6 symbolen wachtwoord invoer
• 128 symbolen wachtwoord invoer
• 129 symbolen wachtwoord invoer.

Kijk naar de afbeelding hieronder om te zien hoe ziet Test Case geschreven volgens deze techniek eruit.

Het verwachte resultaat voor deze testcase is “Informatieve melding “De minimale lengte van het wachtwoord is 6 symbolen” wordt weergegeven”.

Verschillende functionaliteiten, zoals zoeken, rangschikken, pagineren, moeten ook worden getest. Deze testgevallen kunnen ook worden geschreven volgens de scenario’s die we eerder hebben bekeken. Ze controleren de normale werking van:

• Zoekvelden
• Paginaknoppen
• Pijlen
• Ranking op naam (A tot Z, Z tot A)
• Ranking op prijs (laagste eerst, hoogste eerst)
• Dashboard en sidebar menuknoppen enz.

Kom terug naar EasyQA Test Management System en schrijf een eenvoudige Test Case voor het controleren van “Gesloten issues” knop filter functionaliteit.

Het verwachte resultaat voor deze testcase is “Alleen gesloten problemen worden weergegeven in het menu van het dashboard”.

Veiligheidstests worden vaak uitgevoerd met speciale geautomatiseerde testtools, zoals Vega, Google Nogotofail, Wapiti enzovoort. Maar met behulp van je mentale activiteit vaardigheden kunt u schrijven eenvoudige Test Case voor het controleren van een aantal veiligheidsparameters van de website. Kom terug naar EasyQA Test Management System. Hieronder ziet u een voorbeeld van zo’n Test Case.

Let op de Stappen. Het verwachte resultaat voor deze testcase is “Het EasyQA Inschrijfformulier wordt weergegeven na het kopiëren/plakken van de URL van de ene browser naar de andere”. Er is dus geen toegang tot de gebruikersaccount.

Er zijn tal van Test Management tools om testers te helpen bij hun werk. EasyQA geeft u een breed scala aan extra handige functies:

1. Exporteer een voorbereid testplan in CSV formaat met één druk op de knop
2. Importeer een voorbereid testplan naar ons systeem.
3. Testgevallen weergeven op basis van verschillende criteria:
4. Crashrapporten maken
5. Buildistributie
6. Bug Tracking System
7. Uitvoeren van testen
8. Rapporten genereren
9. Snelle en eenvoudige integratie met uw bestaande tools.

Eenvoudig gezegd, EasyQA is meer dan een Test Management Systeem. Het is een omgeving om prettig en efficiënt te werken.

1. Bedenk, dat Test Cases ook door je collega’s worden uitgevoerd
2. Gebruik een sterke Titel
3. Let op de Pre Stappen en Randvoorwaarden
4. Test Case beslaat één functionaliteit en
5. Test Case heeft slechts één Verwacht Resultaat
6. Schrijf goedontworpen en eenvoudig te begrijpen stappen
7. Vergeet niet om alle nuttige informatie in de Comments of Post Conditions te zetten
8. Gebruik illustraties en eenvoudige testtools als het nodig is
9. Test Case moet herbruikbaar zijn
10. Start met oefenen

Wilt u effectieve Test Cases schrijven? Begin er dan gewoon mee. En het zal ons een genoegen zijn om u te helpen.

TRY EASY QA