TESTPLAN - SOFTWARE TESTEN

Een testplan is een gedetailleerd document waarin de gebieden en activiteiten voor het testen van software worden beschreven. Het schetst de teststrategie, doelstellingen, testschema, vereiste middelen (personeel, software en hardware), testschatting en testresultaten.

Het testplan vormt de basis voor het testen van elke software. Het is de meest cruciale activiteit die ervoor zorgt dat alle lijsten met geplande activiteiten in de juiste volgorde beschikbaar zijn.

Het testplan is een sjabloon voor het uitvoeren van softwaretestactiviteiten als een gedefinieerd proces dat volledig wordt bewaakt en gecontroleerd door de testmanager. Het testplan wordt opgesteld door de testleider (60%), testmanager (20%) en door de testingenieur (20%).

Soorten testplannen

Er zijn drie soorten testplannen

Mastertestplan
Fase Testplan
Testtypespecifieke testplannen

Mastertestplan

Mastertestplan is een type testplan met meerdere testniveaus. Het omvat een volledige teststrategie.

Fase Testplan

Een fasetestplan is een type testplan dat betrekking heeft op elke fase van de teststrategie. Bijvoorbeeld een lijst met tools, een lijst met testgevallen, enz.

Specifieke testplannen

Specifiek testplan ontworpen voor belangrijke soorten tests, zoals beveiligingstests, belastingtests, prestatietests, enz. Met andere woorden, een specifiek testplan ontworpen voor niet-functioneel testen.

Romeinse cijfers grafiek 1 100

Hoe schrijf je een testplan?

Het maken van een testplan is de meest cruciale taak van het testmanagementproces. Volg volgens IEEE 829 de volgende zeven stappen om een testplan op te stellen.

Analyseer eerst de productstructuur en architectuur.
Ontwerp nu de teststrategie.
Definieer alle testdoelstellingen.
Definieer het testgebied.
Definieer alle bruikbare bronnen.
Plan alle activiteiten op de juiste manier.
Bepaal alle testresultaten.

Onderdelen of attributen van het testplan

Het testplan bestaat uit verschillende onderdelen, die ons helpen de gehele testactiviteit af te leiden.

Doelstellingen: Het bestaat uit informatie over modules, features, testgegevens etc., die aangeven wat het doel van de applicatie is, het applicatiegedrag, het doel, etc.

Domein: Het bevat informatie die moet worden getest met de betreffende applicatie. De Scope kan verder worden onderverdeeld in twee delen:

Binnen reikwijdte
Buiten bereik

In reikwijdte: Dit zijn de modules die uitvoerig (tot in detail) getest moeten worden.

Buiten bereik: Dit zijn de modules die niet rigoureus hoeven te worden getest.

Bijvoorbeeld , Stel dat we een Gmail-applicatie moeten testen, waar kenmerken die getest moeten worden zoals E-mail opstellen, Verzonden items, Postvak IN, Concepten en de kenmerken die niet worden getest zoals Hulp , enzovoort, wat betekent dat we in de planningsfase zullen beslissen welke functionaliteit wel of niet moet worden gecontroleerd op basis van de tijdslimiet die in het product is opgegeven.

Nu hoe beslissen we welke functies niet worden getest?

We hebben de volgende aspecten waarbij we kunnen beslissen welke functie niet moet worden getest:

Zoals we hierboven zien Hulp functies worden niet getest, omdat deze zijn geschreven en ontwikkeld door de technisch schrijver en beoordeeld door een andere professionele schrijver.
Laten we aannemen dat we één applicatie hebben die dat wel heeft P, Q, R en S functies die moeten worden ontwikkeld op basis van de vereisten. Maar hier is de S-functie al ontworpen en gebruikt door een ander bedrijf. Het ontwikkelingsteam zal dus S van dat bedrijf kopen en integreren met extra functies zoals P, Q en R.

Nu zullen we geen functionele tests uitvoeren op de S-functie omdat deze al in realtime is gebruikt. Maar we zullen de integratietests en systeemtests uitvoeren tussen de P-, Q-, R- en S-functies, omdat de nieuwe functies mogelijk niet correct werken met de S-functie, zoals we in de onderstaande afbeelding kunnen zien:

Stel dat bij de eerste release van het product de elementen zijn ontwikkeld, zoals P, Q, R, S, T, U, V, W…..X, Y, Z . Nu zal de klant de vereisten opgeven voor de nieuwe functies die het product in de tweede release verbeteren en de nieuwe functies zijn A1, B2, C3, D4 en E5.

Daarna schrijven we de scope tijdens het testplan als

Domein

Functies die getest moeten worden

A1, B2, C3, D4, E5 (nieuwe functies)

P, Q, R, S, T

Functies die niet getest moeten worden

W X Y Z

Daarom zullen we eerst de nieuwe functies controleren en dan doorgaan met de oude functies, omdat deze mogelijk worden beïnvloed na het toevoegen van de nieuwe functies, wat betekent dat dit ook de impactgebieden zal beïnvloeden, dus we zullen een ronde van regressietests uitvoeren voor P, Q , R…, T-functies.

Testmethodologie:

Het bevat informatie over het uitvoeren van een ander soort testen, zoals functioneel testen, integratietesten en systeemtesten, enz. op de applicatie. Hierin zullen we beslissen welk type testen; we zullen de verschillende functies uitvoeren op basis van de toepassingsvereiste. En hier moeten we ook definiëren welk soort tests we zullen gebruiken in de testmethodologieën, zodat iedereen, zoals het management, het ontwikkelingsteam en het testteam, het gemakkelijk kan begrijpen, omdat de testtermen niet standaard zijn.

Bijvoorbeeld, voor zelfstandige toepassingen zoals Adobe Photoshop , zullen we de volgende soorten tests uitvoeren:

Rooktesten → Functioneel testen → Integratietesten → Systeemtesten → Adhoc-testen → Compatibiliteitstests → Regressietests → Globaliseringstests → Toegankelijkheidstests → Bruikbaarheidstests → Betrouwbaarheidstests → Hersteltests → Installatie- of de-installatietests

En stel dat we de https://www.jeevansathi.com/ toepassing, dus zullen we de volgende soorten tests uitvoeren:

Rook testen	Functioneel testen	Integratie testen
Systeem testen	Ad-hoc testen	Compatibiliteitstesten
Regressie testen	Mondialisering testen	Toegankelijkheidstesten
Bruikbaarheidstesten	Prestatietesten

Benadering

Dit kenmerk wordt gebruikt om de stroom van de applicatie te beschrijven tijdens het uitvoeren van tests en voor toekomstig gebruik.

We kunnen de stroom van de applicatie begrijpen met behulp van de onderstaande aspecten:

Door de scenario's op hoog niveau te schrijven Door het stroomdiagram te schrijven

Door de scenario's op hoog niveau te schrijven

Bijvoorbeeld , stel dat we de Gmail sollicitatie:

Inloggen bij Gmail - stuurt een e-mail en controleert of deze op de pagina Verzonden items staat
Inloggen …….
……
…....

We schrijven dit om de aanpak te beschrijven die moet worden gevolgd bij het testen van het product en alleen voor de kritische kenmerken waarvoor we de scenario's op hoog niveau zullen schrijven. Hier zullen we ons niet concentreren op het behandelen van alle scenario's, omdat de specifieke testingenieur kan beslissen welke functies wel of niet moeten worden getest.

Door het stroomdiagram te schrijven

Het stroomdiagram is geschreven omdat het schrijven van de scenario's op hoog niveau een tijdrovend proces is, zoals we in de onderstaande afbeelding kunnen zien:

We maken stroomgrafieken om de volgende voordelen te behalen, zoals:

Dekking is eenvoudig
Samenvoegen is eenvoudig

De aanpak kan worden onderverdeeld in twee delen, namelijk:

Benadering van boven naar beneden
Benadering van onder naar boven

Aanname

Het bevat informatie over een probleem of probleem dat zich mogelijk heeft voorgedaan tijdens het testproces en wanneer we de testplannen schrijven, worden de verzekerde aannames gedaan, zoals middelen en technologieën, enz.

Risico

Dit zijn de uitdagingen waarmee we het hoofd moeten bieden om de applicatie in de huidige release te testen en als de aannames mislukken, zijn er risico's aan verbonden.

Bijvoorbeeld, het effect voor een applicatie wordt de releasedatum uitgesteld.

Mitigatieplan of noodplan

Het is een back-upplan dat is opgesteld om de risico's of problemen te overwinnen.

Laten we een voorbeeld bekijken van aanname, risico en het noodplan samen, omdat ze onderling met elkaar verband houden.

In elk product is de aanname wat we zullen maken is dat alle drie de testingenieurs daar zullen zijn tot de voltooiing van het product en dat elk van hen verschillende modules krijgt toegewezen, zoals P, Q en R. In dit specifieke scenario is de risico Dat zou het geval kunnen zijn als de testingenieur het project halverwege zou verlaten.

Daarom, de noodplan krijgt voor elk kenmerk een primaire en ondergeschikte eigenaar toegewezen. Dus als de ene testingenieur vertrekt, neemt de ondergeschikte eigenaar die specifieke functie over en helpt ook de nieuwe testingenieur, zodat hij/zij de aan hem toegewezen modules kan begrijpen.

De aannames, het risico en het mitigatie- of noodplan zijn altijd nauwkeurig op het product zelf. De verschillende soorten risico’s zijn als volgt:

Klanten perspectief
Middelenbenadering
Technische mening

Rol & Verantwoordelijkheid

Het definieert de volledige taak die door het hele testteam moet worden uitgevoerd. Als er een groot project komt, dan is de Testmanager is een persoon die het testplan schrijft. Als er 3-4 kleine projecten zijn, wijst de testmanager elk project toe aan elke testleider. En vervolgens schrijft de testleider het testplan voor het project, dat hem/haar wordt toegewezen.

Laten we een voorbeeld bekijken waarin we de rollen en verantwoordelijkheid van de testmanager, de testleider en de testingenieurs zullen begrijpen.

Rol: Testmanager

Naam: Ryan

Verantwoordelijkheid:

Opstellen (schrijven en beoordelen) van het testplan
Voer de bijeenkomst met het ontwikkelteam
Voer de bijeenkomst met het testteam
Voer het gesprek met de klant
Organiseer maandelijks een stand-up meeting
Releasenota afmelden
Het afhandelen van escalaties en problemen

Rol: Testleider

Naam: Harvey

Verantwoordelijkheid:

Opstellen (schrijven en beoordelen) van het testplan
Dagelijks een stand-up meeting houden
Beoordeel en keur de testcase goed
Bereid de RTM en rapporten voor
Modules toewijzen
Afhandelingsschema

Rol: Testingenieur 1, Testingenieur 2 en Testingenieur 3

Naam: Louis, Jessica, Donna

Modules toewijzen: M1, M2 en M3

Verantwoordelijkheid:

Schrijven, beoordelen en uitvoeren van de testdocumenten die bestaan uit testcases en testscenario's
Lees, bekijk, begrijp en analyseer de vereiste
Schrijf de stroom van de applicatie
Voer de testcase uit
RTM voor respectievelijke modules
Het volgen van defecten
Bereid het testuitvoeringsrapport voor en communiceer dit aan de testleider.

Schema

Het wordt gebruikt om de timing van het werk uit te leggen. Wat moet er gebeuren of dit attribuut geeft aan wanneer elke testactiviteit precies moet beginnen en eindigen? En bij elke testactiviteit op de betreffende datum worden ook de exacte gegevens vermeld.

Daarom kunnen we in de onderstaande afbeelding zien dat er voor de specifieke activiteit een begin- en einddatum zal zijn; voor elke test voor een specifieke build zal er een gespecificeerde datum zijn.

Bijvoorbeeld

Testcases schrijven
Uitvoeringsproces

Het volgen van defecten

Dit gebeurt meestal met behulp van tools, omdat we de status van elke bug niet handmatig kunnen volgen. En we geven ook commentaar op de manier waarop we de bugs die tijdens het testproces worden geïdentificeerd, communiceren en terugsturen naar het ontwikkelingsteam, en hoe het ontwikkelingsteam zal reageren. Hier vermelden we ook de prioriteit van de bugs, zoals hoog, gemiddeld en laag.

Hieronder volgen verschillende aspecten van het volgen van defecten:

Blocker of showstopper

Bijvoorbeeld

Kritisch

Belangrijk

Minderjarige

Hoog-P1

Medium-P2

Laag-P3

Daarom zullen we, op basis van de prioriteit van bugs zoals hoog, gemiddeld en laag, deze categoriseren als P1, P2, P3 en P4.

Testomgevingen

Dit zijn de omgevingen waarin we de applicatie gaan testen, en hier hebben we twee soorten omgevingen, namelijk software En hardware configuratie.

De softwareconfiguratie betekent de details over verschillende Besturingssystemen zoals Windows, Linux, UNIX en Mac en divers Browsers leuk vinden Google Chrome, Firefox, Opera, Internet Explorer , enzovoort.

En de hardware configuratie betekent de informatie over verschillende maten van RAM, ROM en de processors .

Bijvoorbeeld

De Software omvat het volgende:

Server

Besturingssysteem	Linux
Web Server	Apache Tomcat
Applicatie server	Websfeer
Database server	Oracle- of MS-SQL-server

Let op: De bovenstaande servers zijn de servers die door het testteam worden gebruikt om de applicatie te testen.

Cliënt

Besturingssysteem	Windows XP, Vista7
Browsers	Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7 en Internet Explorer 8

Let op: Bovenstaande gegevens geven de verschillende besturingssystemen en browsers weer waarin het testteam de applicatie gaat testen.

De Hardware omvat het volgende:

Server : Zon StarCat 1500

Deze specifieke server kan door het testteam worden gebruikt om hun applicatie te testen.

Cliënt:

Het heeft de volgende configuratie, die als volgt is:

Verwerker	Totaal 2GHz
RAM	2 GB
….	….

Opmerking: het biedt de configuratie van de systemen van de testingenieurs die het testteam vormen.

Het ontwikkelingsteam zal de configuratie verzorgen voor het installeren van de software. Als het ontwikkelteam het proces nog niet aanlevert, schrijven we dit als Task-Based Development (TBD) in het testplan.

In- en uitstapcriteria

Het is een noodzakelijke voorwaarde waaraan moet worden voldaan voordat het testproces wordt gestart en gestopt.

Toelatingscriteria

De toelatingscriteria bevatten de volgende voorwaarden:

Het testen van de witte dozen moet worden afgerond.
Begrijp en analyseer de eis en bereid de testdocumenten voor of wanneer de testdocumenten gereed zijn.
Testgegevens moeten gereed zijn.
Build of de applicatie moet worden voorbereid
Modules of functies moeten worden toegewezen aan de verschillende testingenieurs.
De benodigde middelen moeten gereed zijn.

Uitgangscriteria

De exitcriteria bevatten de volgende voorwaarden:

Wanneer alle testgevallen zijn uitgevoerd.
De meeste testgevallen moeten dat wel zijn geslaagd .
Afhankelijk van de ernst van de bugs, wat betekent dat er geen blokkering of grote bug mag zijn, terwijl er wel enkele kleine bugs zijn.

Voordat we beginnen met het uitvoeren van functionele tests, al het bovenstaande Toelatingscriteria gevolgd moet worden. Nadat we functionele tests hebben uitgevoerd en voordat we integratietests gaan uitvoeren, wordt de Exitcriteria van het functionele testen moet worden gevolgd omdat het percentage exitcriteria wordt bepaald door de bijeenkomst met zowel de ontwikkelings- als de testmanager, omdat hun samenwerking het percentage kan bereiken. Maar als de exitcriteria van functioneel testen niet worden gevolgd, kunnen we niet verder gaan met integratietesten.

Hier op basis van de ernst van de bug betekent dat het testteam zou hebben besloten om verder te gaan voor de volgende fasen.

Testautomatisering

Hierin zullen wij het volgende beslissen:

Welke functie moet worden geautomatiseerd en niet worden geautomatiseerd?
Welke testautomatiseringstool gaan we gebruiken op welk automatiseringsframework?

Pas na de eerste release automatiseren we de testcase.

Hier rijst de vraag op welke basis Wij zullen beslissen welke functies moeten worden getest?

In de bovenstaande afbeelding kunnen we zien dat de meest gebruikte functies steeds opnieuw moeten worden getest. Stel dat we de Gmail-applicatie moeten controleren waar de essentiële functies zijn E-mail, Verzonden items en Postvak IN opstellen . We zullen deze functies dus testen, omdat het handmatig testen meer tijd kost en het ook een eentonige klus wordt.

Java breken

Nu, hoe beslissen we welke functies niet worden getest?

Veronderstellen de hulp functie van de Gmail-applicatie wordt niet steeds opnieuw getest omdat deze functies niet regelmatig worden gebruikt, dus we hoeven deze niet regelmatig te controleren.

Maar als sommige functies instabiel zijn en veel bugs bevatten , wat betekent dat we deze functies niet zullen testen, omdat deze keer op keer moeten worden getest tijdens handmatige tests.

Als er is een functie die regelmatig moet worden getest , maar we verwachten dat de vereisten voor die functie veranderen, dus we controleren dit niet omdat het wijzigen van de handmatige testgevallen comfortabeler is in vergelijking met wijzigingen in het automatiseringstestscript.

Inspanningsschatting

Hierin plannen we de inspanningen die elk teamlid moet leveren.

Test leverbaar

Dit zijn de documenten die de output vormen van het testteam en die we samen met het product aan de klant hebben overhandigd. Het omvat het volgende:

Testplan Testgevallen Testscripts RTM (Traceerbaarheidsmatrix van vereisten) Defectrapport Testuitvoeringsrapport Grafieken en statistieken Release-opmerkingen

Grafieken en statistieken

Grafiek

Hierin bespreken we de soorten grafieken we sturen het op, en we zullen ook een voorbeeld van elke grafiek leveren.

Zoals we kunnen zien, hebben we vijf verschillende grafieken die de verschillende aspecten van het testproces laten zien.

Grafiek1: Hierin laten we zien hoeveel defecten er zijn geïdentificeerd en hoeveel defecten in elke module zijn verholpen.

Grafiek 2: Figuur één laat zien hoeveel kritieke, grote en kleine defecten voor elke module zijn geïdentificeerd en hoeveel er voor hun respectieve modules zijn opgelost.

Grafiek3: In deze specifieke grafiek vertegenwoordigen we de bouw een verstandige grafiek , wat betekent dat in elke build hoeveel defecten voor elke module zijn geïdentificeerd en verholpen. Op basis van de module hebben we de bugs vastgesteld. Wij zullen toevoegen R om het aantal defecten in P en Q te tonen, en we voegen ook toe S om de defecten in P, Q en R te tonen.

Grafiek4: De testleider ontwerpt de Analyse van bugtrends grafiek die elke maand wordt gemaakt en ook naar het management wordt verzonden. En het is net als een voorspelling die aan het einde van het product wordt gedaan. En hier kunnen wij dat ook beoordeel de bugfixes zoals wij dat kunnen waarnemen boog heeft een opwaartse tendens in de onderstaande afbeelding.

Grafiek5: De Testmanager heeft dit type grafiek ontworpen. Deze grafiek is bedoeld om inzicht te krijgen in de kloof tussen de beoordeling van bugs en de daadwerkelijke bugs die zijn opgetreden. Deze grafiek helpt ook om de evaluatie van bugs in de toekomst te verbeteren.

Statistieken

Net als hierboven maken we de bugverdelingsgrafiek, die zich in figuur 1 bevindt, en met behulp van de bovengenoemde gegevens zullen we ook de statistieken ontwerpen.

Bijvoorbeeld

In de bovenstaande afbeelding bewaren we de gegevens van alle testingenieurs in een bepaald project en hoeveel defecten er zijn geïdentificeerd en verholpen. We kunnen deze gegevens ook gebruiken voor toekomstige analyses. Wanneer er een nieuwe vereiste komt, kunnen we beslissen wie de uitdagende functie voor testen aanbiedt op basis van het aantal defecten dat ze eerder hebben gevonden op basis van de bovenstaande statistieken. En we zullen in een betere situatie verkeren om te weten wie heel goed met de problematische kenmerken kan omgaan en het maximale aantal defecten kan vinden.

Release-opmerking: Het is een document dat wordt opgesteld tijdens de release van het product en wordt ondertekend door de Testmanager.

In de onderstaande afbeelding kunnen we zien dat het eindproduct is ontwikkeld en bij de klant is geïmplementeerd, en dat de nieuwste releasenaam dat is Bèta .

De Release-opmerking bestaat uit het volgende:

Handleiding.
Lijst met hangende en openstaande defecten.
Lijst met toegevoegde, gewijzigde en verwijderde functies.
Lijst van het platform (besturingssysteem, hardware, browsers) waarop het product is getest.
Platform waarin het product niet is getest.
Lijst met opgeloste bugs in de huidige release en de lijst met opgeloste bugs in de vorige release.
Installatieproces
Versies van de software

Bijvoorbeeld

Stel dat Bèta is de tweede release van de applicatie na de eerste release Alfa is vrijgegeven. Een deel van de defecten die in de eerste release zijn geïdentificeerd en die zijn opgelost in de latere release. En hier zullen we ook wijzen op de lijst met nieuw toegevoegde, gewijzigde en verwijderde functies, van de alfa-release tot de bèta-release.

Sjabloon

Dit deel bevat alle sjablonen voor de documenten die in het product zullen worden gebruikt, en alle testingenieurs zullen alleen deze sjablonen in het project gebruiken om de consistentie van het product te behouden. Hier hebben we verschillende typen templates die tijdens het gehele testproces worden gebruikt, zoals:

Sjabloon voor testcases
Sjabloon voor beoordeling van testcases
RTM-sjabloon
Sjabloon voor bugrapport
Testuitvoeringsrapport

Laten we een voorbeeld van een testplandocument bekijken

Pagina 1

Pagina3-pagina18

Pagina-20

Op pagina 1 vullen we voornamelijk alleen de Versies, auteur, opmerkingen en beoordeeld door velden, en nadat de manager het heeft goedgekeurd, zullen we de details vermelden in het Goedgekeurd door en goedkeuringsdatum velden.

Meestal wordt het testplan goedgekeurd door de Testmanager en beoordelen de testingenieurs het alleen. En als er nieuwe features komen, passen we het testplan aan en voeren we de nodige aanpassingen door Versie veld, en vervolgens wordt het opnieuw verzonden voor verdere beoordeling, update en goedkeuring van de manager. Het testplan moet worden bijgewerkt zodra er wijzigingen zijn opgetreden. Op pagina 20 staat de Referenties specificeer de details over alle documenten die we gaan gebruiken om het testplandocument te schrijven.

Opmerking:

Wie schrijft het testplan?

Testleiding →60%
Testmanager →20%
Testingenieur →20%

Daarom, zoals we hierboven kunnen zien, wordt het testplan bij 60% van het product geschreven door de testleider.

Wie beoordeelt het testplan?

Testleiding
Testmanager
Test-ingenieur
Klant
Ontwikkelingsteam

De testingenieur beoordeelt het testplan op basis van hun moduleperspectief en de testmanager beoordeelt het testplan op basis van de mening van de klant.

Wie keurt het testplan goed?

Klant
Testmanager

Wie schrijft de testcase?

Testleiding
Test-ingenieur

Wie beoordeelt de testcase?

Test-ingenieur
Testleiding
Klant
Ontwikkelingsteam

Wie keurt de testgevallen goed?

Testmanager
Testleiding
Klant

Richtlijnen voor testplannen

Vouw uw testplan samen.
Vermijd overlapping en redundantie.
Als u denkt dat u een sectie die hierboven al vermeld staat niet nodig heeft, verwijder dan die sectie en ga verder.
Wees specifiek. Als u bijvoorbeeld een softwaresysteem opgeeft als onderdeel van de testomgeving, vermeld dan de softwareversie in plaats van alleen de naam.
Vermijd lange paragrafen.
Maak waar mogelijk gebruik van lijsten en tabellen.
Werk het plan bij wanneer dat nodig is.
Gebruik geen verouderd en ongebruikt document.

Belang van testplan

Het testplan geeft richting aan ons denken. Dit is als een regelboek dat moet worden gevolgd.
Het testplan helpt bij het bepalen van de noodzakelijke inspanningen om de kwaliteit van de te testen softwareapplicatie te valideren.
Het testplan helpt die mensen de testdetails te begrijpen die verband houden met de buitenwereld, zoals ontwikkelaars, bedrijfsmanagers, klanten, enz.
Belangrijke aspecten zoals testschema, teststrategie, testscope etc. worden gedocumenteerd in het testplan, zodat het managementteam deze kan beoordelen en hergebruiken voor andere soortgelijke projecten.