Ultieme gids voor validatietesten

validation testing ultimate guide

Ontdek het belang van validatietests:

Wat je leert:

• Wat is validatietesten?
• Verschil tussen verificatie en validatie
• Betrokken fasen
  • Ontwerpkwalificatie
  • Installatiekwalificatie
  • Operationele kwalificatie
    • Functioneel testen en zijn typen
    • Integratietesten en de typen
    • Systeemtesten en zijn typen
  • Prestatiekwalificatie
• Voorbeeldvalidatietestcases of protocol
• Gevolgtrekking
• Aanbevolen literatuur

Wat is validatietesten?

Validatietesten is het proces waarbij wordt gecontroleerd of de geteste en ontwikkelde software voldoet aan de behoeften van de klant / gebruiker. De logica of scenario's van de bedrijfsvereisten moeten in detail worden getest. Alle kritische functionaliteiten van een applicatie moeten hier getest worden.

Als tester is het altijd belangrijk om te weten hoe u de bedrijfslogica of scenario's die u krijgt, kunt verifiëren. Een van die methoden die helpt bij de gedetailleerde evaluatie van de functionaliteiten, is het validatieproces.

Elke keer dat u wordt gevraagd om een ​​validatietest uit te voeren, vergt dit een grote verantwoordelijkheid, aangezien u alle kritieke bedrijfsvereisten moet testen op basis van de gebruikersbehoeften. Er mag zelfs geen enkele fout zijn op de vereisten van de gebruiker. Daarom is een goede kennis van validatietesten erg belangrijk.

Als tester dient u te beoordelen of de resultaten van de testuitvoering voldoen aan hetgeen vermeld staat in het requirementsdocument. Elke afwijking dient onmiddellijk gemeld te worden en die afwijking wordt dan ook een bug genoemd.

Tools als HP Quality Center, Selenium, Appium, etc worden gebruikt om validatietests uit te voeren en we kunnen de testresultaten daar opslaan. Een goed testplan, testuitvoeringsruns, defectrapporten, rapporten en statistieken zijn de belangrijkste te leveren producten.

Vanuit bedrijfsperspectief wordt de validatietest in simple uitgevoerd door de volgende stappen:

• U verzamelt de zakelijke vereisten voor validatietesten van de eindgebruiker.
• Stel het businessplan op en stuur het ter goedkeuring naar de betrokken onsite / belanghebbenden.
• Na goedkeuring van het plan begint u de nodige testcases te schrijven en deze ter goedkeuring op te sturen.
• Na goedkeuring begin je het testen met de vereiste software en omgeving af te ronden en de deliverables te verzenden zoals gevraagd door de klant.
• Na goedkeuring van de deliverables wordt de UAT-test uitgevoerd door de klant.
• Daarna gaat de software voor productie.

wat is de implementatiefase in de sdlc?

Laten we nu in detail meer over validatie onderzoeken.

Verschil tussen verificatie en validatie

Laten we deze op een eenvoudige manier met een voorbeeld begrijpen.

Voorbeeld:

Klantvereiste:

De voorgestelde injectie mag niet meer dan 2 cm wegen.

Verificatietest:

• Controleer of de injectie de injectie is die niet meer dan 2 cm weegt door middel van checklist, beoordeling en ontwerp.

Validatietest:

• Controleer of de injectie niet meer dan 2 cm weegt door handmatige of automatische tests uit te voeren.
• U moet elk mogelijk scenario met betrekking tot het injectiegewicht controleren door een geschikte testmethode te gebruiken (functionele en niet-functionele methoden).
• Controleer op afmetingen van minder dan 2 cm en groter dan 2 cm.

Betrokken fasen

• Ontwerpkwalificatie: Dit omvat het maken van het testplan op basis van de zakelijke vereisten. Alle specificaties dienen duidelijk vermeld te worden.
• Installatiekwalificatie: Dit omvat software-installatie op basis van de vereisten.
• Operationele kwalificatie: Dit omvat de testfase op basis van de specificatie van de gebruikersvereisten.

Dit kan zijn: Functionaliteitstesten:

• • Testen van een eenheid - Zwarte doos, Witte doos, Grijze doos.
  • Integratietesten - Top-down, Bottom-up, oerknal.
  • Systeemtesten - Testen van geestelijke gezondheid, rook en regressie.
• Prestatiekwalificatie: UAT (User Acceptance Testing) ​ Alfa- en bètatesten.
• Productie

Ontwerpkwalificatie

Ontwerpkwalificatie betekent simpelweg dat je het ontwerp van de software zo moet voorbereiden dat het voldoet aan de gebruikersspecificaties. In de eerste plaats moet u het Document met specificatie van gebruikersvereisten (URS) van de klant om verder te gaan met het ontwerp.

Teststrategie:

Dit document vormt de basis voor het opstellen van het testplan. Het wordt meestal voorbereid door de teamleider of manager van het project. Het beschrijft hoe we verder gaan met testen en het gewenste doel bereiken.

Om alle procedures op te nemen, moet een goed plan worden ontworpen en goedgekeurd door de belanghebbenden. Laat ons dus de onderdelen van het testplan weten.

In enkele projecten kunnen testplan en teststrategie als één document worden opgenomen. Er worden ook aparte strategiedocumenten opgesteld voor een complex project (meestal in automatiseringstechniek).

Onderdelen van het validatietestplan:

• Beschrijving van het project
• Inzicht in de vereisten
• Reikwijdte van testen
• Testniveaus en testschema
• Voer het maken van een plan uit
• Hardware-software en personeelsvereisten
• Rollen en verantwoordelijkheden
• Aanname en afhankelijkheden
• Risico's en beperking
• Rapport en statistieken

Beschrijving van het project: Hier moet u de volledige beschrijving van de applicatie toelichten die u voor het testen is verleend. Het moet alle functionaliteiten van de app bevatten.

Inzicht in de vereisten: Bij het verkrijgen van de USR moet u de begrepen vereisten van uw kant vermelden. U kunt eventueel ook verduidelijkingen geven. Dit staat als het basis- of testcriterium voor testen.

Omvang van testen: De scope moet de modules in detail omvatten, samen met de features op hoog niveau. U moet de klant vertellen aan welke vereisten u tijdens uw tests zou voldoen.

Vanuit een zakelijk perspectief kunnen validatietests worden gevraagd om uit te voeren voor de kritieke vereisten van een applicatie. Het betekent gewoon dat u zegt wat er wel en wat niet wordt gedekt ​

Testniveaus en testschema: U moet aangeven hoeveel testronden er moeten worden uitgevoerd. De totale inspanning voor het testproject wordt geschat met behulp van de standaard schattingstechnieken zoals Test Case Point (TCP) -schatting enz.

Zoals de naam impliceert testschema beschrijft hoe het testen zal worden uitgevoerd. Het moet ook vermelden hoe en wanneer de goedkeuring en beoordelingen zullen worden uitgevoerd.

Voorbeeld:

Het ontwerp van een webpagina is het overwogen project.

Testniveaus zijn onder meer:

Niveau 1: Rook testen
Level 2: Testen van een eenheid
Niveau 3: Integratietesten
Niveau 3: Systeem testen
Niveau 3: Acceptatietesten

Testschema:

1. Plan indienen - Dag 1
2. Ontwerp van testcases - Dag 2
3. Droogloop en bugfixing - Dag 4
4. Beoordeling- Dag 5
5. Formele run - Dag 6
6. Te leveren items ter goedkeuring verzonden - Dag 8
7. Rapporten - Dag 10

Maak een plan: Het runplan geeft het aantal runs aan dat nodig is voor het testen. Elke run die u op een externe locatie uitvoert, wordt genoteerd door het team ter plaatse.

Bijvoorbeeld, wanneer u de HP Quick Test Professional-tool voor uitvoering wordt het aantal runs weergegeven op het tabblad Runs van het testplan.

Hardware-software en personeelsvereisten:

• Hardware- en softwarevereisten zoals de apparaten, browserversies, IOS, testtools die nodig zijn voor het project.
• Personeelsbezetting betekent het aanstellen van de personen die nodig zijn voor het testen. U kunt hier het aantal teams vermelden.
• Als u extra testleden nodig heeft, kunt u deze ter plaatse aanvragen, afhankelijk van de testscope. Simpelweg als het aantal testcases toeneemt, betekent dit dat je meer teamleden nodig hebt om ze uit te voeren.

Rollen en verantwoordelijkheden: Dit houdt in dat taken worden toegewezen aan de gerelateerde rollen die verantwoordelijk zijn voor het uitvoeren van de verschillende testniveaus.

Bijvoorbeeld,

Een app moet worden getest door een team bestaande uit 4 leden om 4 validatieprotocollen uit te voeren en u kunt de verantwoordelijkheden als volgt delegeren:

1. Test Lead: Ontwerp van testplan
2. Teamlid 1: Ontwerp en uitvoering van protocollen 1,2.
3. Teamlid 2: Ontwerp en uitvoering van protocollen 3,4.
4. Teamlid: Voorbereiding van rapporten, beoordelingen en statistieken.

Aanname en afhankelijkheden: Dit betekent dat de aannames die tijdens het ontwerp zijn gemaakt en de afhankelijkheden die voor het testen zijn geïdentificeerd, hier worden opgenomen.

Risico's en beperking: Risico's met betrekking tot de testplanning zoals beschikbaarheid van de gewenste omgevingen, build, enz. Samen met mitigatie- en noodplannen.

foutherstelprogramma voor Windows 10

Rapport en statistieken: Factoren die zijn gebruikt bij het testen en rapportages aan de stakeholders dienen hier vermeld te worden.

Een voorbeeld van een mobiele app wordt hieronder gegeven:

Installatiekwalificatie

• Installatiekwalificatie bevat details zoals welke en hoeveel testomgevingen zouden worden gebruikt, welk toegangsniveau vereist is voor de testers in elke omgeving, samen met de vereiste testgegevens. Het kan browsercompatibiliteit omvatten, tools die nodig zijn voor de uitvoering, apparaten die nodig zijn voor testen, enz. Het systeem dat wordt ontwikkeld, moet worden geïnstalleerd in overeenstemming met de gebruikersvereisten.
• Testgegevens zijn mogelijk vereist voor het testen van sommige toepassingen en moeten door de juiste persoon worden verstrekt. Het is een essentiële voorwaarde.
• Voor sommige toepassingen is mogelijk een database vereist. We moeten alle gegevens die nodig zijn voor het testen in een database bewaren om de specificaties te valideren.

Bijvoorbeeld, Een nieuwe app zegt dat 'abc' moet worden getest in mobiel (Android 4.3.1) en browser (Chrome 54), in dat geval moeten we het volgende bijhouden:

• Controleer of de juiste autorisatie is gegeven om de site van de app 'abc' te controleren.
• Kijk of de apparaten die worden gebruikt voor het testen van de app zoals mobiel (Android / ios), browser-Chrome, Internet Explorer met vereiste versie beschikbaar zijn.
• Controleer of deze correct zijn geïnstalleerd met de opgegeven versies (bijvoorbeeld: Chrome 54, Android-versie 4.3.1).
• Zorg ervoor dat de app toegankelijk is in zowel de browser als mobiel.

Operationele kwalificatie

Operationele kwalificatie zorgt ervoor dat elke module en submodule die voor de te testen applicatie is ontworpen, naar behoren functioneert zoals verwacht in de gewenste omgeving.

Een validatietest wordt in het algemeen uitgevoerd in de volgende hiërarchie.

Functioneel testen speelt een grote rol bij validatietesten. Het betekent simpelweg dat u de functionaliteit van de applicatie moet valideren voor elke genoemde kritieke vereiste. Dit maakt de weg vrij om de eisen genoemd in het Functionele Specificatie document in kaart te brengen en zorgt ervoor dat het product aan alle genoemde eisen voldoet.

Functioneel testen en zijn typen

Zoals de naam suggereert, functioneel testen is het testen van de functies, d.w.z. wat de software moet doen. De functionaliteiten van de software worden vastgelegd in het specificatiedocument.

Laten we een korte blik werpen op de typen.

# 1) Eenheidstest:

Unit testing is het testen van de individuele units / modules / componenten / methoden van het gegeven systeem. De veldvalidatie, layoutcontrole, ontwerp, etc. worden na codering getest met verschillende inputs. Elke regel van de code moet worden gevalideerd voor de individuele testgevallen.

Unit testing wordt door de ontwikkelaars zelf gedaan. De kosten voor het oplossen van bugs zijn hier lager in vergelijking met de andere testniveaus.

Voorbeeld:

Het evalueren van een lus van de code voor een functie, zeg maar dat geslachtskeuze een voorbeeld is van unit testing.

# 2) Black Box-testen:

Het gedrag van een applicatie voor de gewenste functionaliteiten toetsen aan de eisen zonder de interne details van het systeem te focussen, heet Black box testing. Het wordt meestal uitgevoerd door een onafhankelijk testteam of door de eindgebruikers van de applicatie.

De applicatie wordt getest met relevante inputs en wordt getest om te valideren of het systeem zich gedraagt ​​zoals gewenst. Hiermee kunnen zowel de functionele als niet-functionele eisen worden getest.

# 3) White Box-testen:

White box testen is niets anders dan een gedetailleerde controle van de programmacode per code. De volledige werking van de applicatie hangt af van de geschreven code, daarom is het noodzakelijk om de code zeer zorgvuldig te testen. U moet elke eenheid en de integratie ervan als een hele module stap voor stap controleren.

Een tester met programmeerkennis is hierbij een must criterium. Hiermee wordt duidelijk of er een afwijking is in de workflow van de applicatie. Het is handig voor zowel de ontwikkelaars als testers.

# 4) Gray Box-testen:

hoe string-array in java te retourneren

Gray box testing is een combinatie van zowel white box als black box testen. Gedeeltelijke kennis over de structuur of de code van de te testen eenheid is hier bekend.

Integratietesten en de typen

De afzonderlijke componenten van de software die al zijn getest tijdens het testen van eenheden, worden geïntegreerd en samen getest om hun functionaliteiten als geheel te testen, om de gegevensstroom tussen de modules te waarborgen.

Dit wordt gedaan door de ontwikkelaars zelf of door een onafhankelijk testteam. Dit kan worden gedaan nadat twee of meer eenheden zijn getest.

Top-down benadering:

Bij deze benadering worden eerst de bovenste eenheden getest en vervolgens worden de eenheden op een lager niveau stapsgewijs getest. Teststubs die kunnen worden gebruikt, zijn vereist om de eenheden op een lager niveau te simuleren die mogelijk niet beschikbaar zijn tijdens de eerste fasen.

Bottom-up benadering:

Bij deze benadering worden eerst de onderste units getest, geïntegreerd en vervolgens worden de hogere units getest. Teststubs die kunnen worden gebruikt, zijn vereist om de eenheden van een hoger niveau te simuleren die mogelijk niet beschikbaar zijn tijdens de eerste fasen.

Systeemtesten en zijn typen

Het testen van het complete systeem / software wordt systeemtesten genoemd. Het systeem wordt volledig getoetst aan de functionele eisen. Systeemtesten worden gedaan tegen zowel de functionele als niet-functionele vereisten. Black box-testen hebben over het algemeen de voorkeur voor dit type testen.

# 1) Rookonderzoek:

Wanneer de bouwers de build aanvankelijk laten testen, moeten we de build grondig testen. Dit wordt rooktesten genoemd. We moeten aangeven of de build verder kan worden getest of niet.

Om validatie uit te voeren, hebt u een goede build nodig. Daarom wordt rooktesten eerst gedaan door het testteam. De workflow van de geteste applicatie moet worden getest met of zonder de testcases. Een testcase die de hele stroom bestrijkt, is nuttig voor deze test.

# 2) Sanity testen:

Bij het testen van gezond verstand worden de belangrijkste functionaliteiten van de modules van de te testen applicatie getest. Bij het testen van een website met 3 tabbladen, d.w.z. het maken van profielen, onderwijs, inloggen, enz., In IRCTC moeten de belangrijkste functionaliteiten van al deze tabbladen worden gecontroleerd zonder erg dieper te gaan.

De menu's, submenu's, tabbladen moeten in alle modules worden getest. Het is een subset van regressietesten, aangezien er alleen op de hoofdstroom wordt getest en niet in de diepte.

# 3) Regressietesten:

Voor elke release van het project kan het ontwikkelteam bepaalde wijzigingen aanbrengen. Valideren of de nieuwe aangebrachte wijzigingen geen invloed hebben gehad op de werking van het systeem, wordt regressietesten genoemd. Hier hoeven alleen bepaalde testgevallen te worden getest die betrekking hebben op de nieuwe eisen.

Prestatiekwalificatie

UAT (User Acceptance Testing):

Dit is de laatste testfase die wordt uitgevoerd om ervoor te zorgen dat het systeem zich gedraagt ​​zoals vereist in overeenstemming met de gespecificeerde vereisten. Dit wordt gedaan door de klant. Zodra de klant de systeemtest heeft gecertificeerd en gewist, kan het product worden ingezet.

Alfa- en bètatests:

Alfatesten worden uitgevoerd door de ontwikkelaars op de applicatie voordat ze worden vrijgegeven op de softwareontwikkelingssite. Het omvat testen in zwarte en witte dozen. Beta-testen worden aan de kant van de klant uitgevoerd nadat het product is ontwikkeld en geïmplementeerd.

Voorbeeldvalidatietestcases of protocol

Met mijn ervaring heb ik dit protocol geschreven voor inloggen bij Gmail.

Een grondige controle van de inlogfunctionaliteit die wordt gedekt, is wat validatie eigenlijk is. Maar ik zou willen vermelden dat de stijl van de gebruikte zinkolommen volledig kan verschillen en afhankelijk is van de eisen van de klant.

=> Download voorbeeldvalidatietestcases: Testcase voor inloggen bij Gmail

Gevolgtrekking

Bij validatie draait het allemaal om het in detail analyseren van de functionaliteiten van een product. Als validatietester moet u er altijd aan denken om de afwijkingen ter plekke te rapporteren om optimale testresultaten te verkrijgen.

Elke testcase die wordt geschreven, moet scherp, beknopt en begrijpelijk zijn, zelfs voor de gewone man. Validatietesters moeten ervoor zorgen dat het juiste product wordt ontwikkeld tegen de gespecificeerde vereisten.

Als richtlijn voor validatietests heb ik het proces behandeld dat verband houdt met validatie.

Ontwerpkwalificatie die het validatieplan omvat, Installatiekwalificatie die spreekt over de hardware-software-installatie, een operationele kwalificatie die de volledige systeemtest omvat, prestatiekwalificatie die de gebruikersacceptatietest omvat die de autorisatie voor productie verschaft.

Ik hoop dat dit artikel je kennis over het concept van validatietesten zou hebben verrijkt !!

Aanbevolen literatuur

• Beste softwaretesttools 2021 (QA Test Automation Tools)
• Alfatesten en bètatesten (een complete gids)
• Belangrijkste verschillen tussen Black Box-tests en White Box-tests
• Functioneel testen versus niet-functioneel testen
• Primer eBook downloaden testen
• Build Verification Testing (BVT Testing) Complete Guide
• Wat is systeemtesten - een ultieme beginnershandleiding
• Handleiding voor het testen van webapplicaties