test plan tutorial guide write software test plan document from scratch
Een ultieme gids voor het softwaretestplan-document:
Deze tutorial legt je alles uit over het Software Test Plan Document en helpt je bij het schrijven / creëren van een gedetailleerd Software Test Plan samen met het verschillen tussen testplanning en testuitvoering.
Live Project QA Training Dag 3 - Na onze lezers kennis te hebben gemaakt met de live toepassing van onze gratis online softwaretesttraining , kwamen we te weten hoe SRS te beoordelen en testscenario's te schrijven En nu is het het juiste moment om dieper in te gaan op het belangrijkste deel van de levenscyclus van softwaretests, d.w.z. Testplanning
Lijst met ALLE tutorials in deze serie:
Testplanningsdocument:
Tutorial # 1: Hoe u een testplan-document schrijft (Deze tutorial)
Tutorial # 2: Inhoud van een eenvoudig testplan-sjabloon
Tutorial # 3: Voorbeeld van een softwaretestplan
Tutorial # 4: Verschil tussen testplan en teststrategie
Tutorial # 5: Hoe u een teststrategiedocument schrijft
Tips voor het plannen van tests:
Tutorial # 6: Risicobeheer tijdens testplanning
Tutorial # 7: Wat u moet doen als er niet genoeg tijd is om te testen
Tutorial # 8: Hoe u testprojecten effectief kunt plannen en beheren
Testplanning in verschillende stadia van STLC:
Tutorial # 9: Planning van regressietests
Tutorial # 10: UAT-testplan
Tutorial # 11: Acceptatietestplan
Planning van testautomatisering:
Tutorial # 12: Automatiseringstestplan
Tutorial # 13: Planning van ERP-applicatietests
Tutorial # 14: HP ALM-testplanning
Tutorial # 15: Mindmap Test Planning
Tutorial # 16: JMeter Testplan en WorkBench
Wat je leert:
Testplan maken - de belangrijkste testfase
Deze informatieve tutorial legt u de manieren en procedures uit die betrokken zijn bij het schrijven van een testplan-document.
Aan het einde van deze tutorial hebben we een 19 pagina's uitgebreid testplan-document die speciaal is gemaakt voor het live project OrangeHRM, dat we hiervoor gratis gebruiken QA-trainingsserie
Wat is een testplan?
Testplan is een dynamisch document Het succes van een testproject hangt af van een goed geschreven Testplan-document dat altijd actueel is. Testplan is min of meer zoals een blauwdruk van hoe de testactiviteit verloopt om plaats te vinden in een project.
Hieronder vindt u enkele tips voor een testplan:
# 1) Testplan is een document dat als referentiepunt fungeert en alleen op basis daarvan wordt getest binnen het QA-team.
#twee) Het is ook een document dat we delen met de Business Analisten, Projectmanagers, het Dev-team en de andere teams. Dit helpt om de transparantie van het werk van het QA-team naar de externe teams te vergroten.
# 3) Het wordt gedocumenteerd door de QA-manager / QA-lead op basis van de input van de QA-teamleden.
# 4) Testplanning wordt doorgaans toegewezen met 1/3rdvan de tijd die nodig is voor de gehele QA-opdracht. De andere 1/3rdis voor het ontwerpen van tests en de rest is voor het uitvoeren van tests.
# 5) Dit plan is niet statisch en wordt op verzoek bijgewerkt.
# 6) Hoe gedetailleerder en uitgebreider het plan is, des te succesvoller zal de testactiviteit zijn.
STLC-proces
We zijn nu halverwege onze live-projectreeks. Laten we daarom een stap terug doen van de applicatie en eens kijken naar het Software Testing Life Cycle (STLC) -proces.
STLC kan grofweg in 3 delen worden verdeeld:
- Testplanning
- Test ontwerp
- Testuitvoering
In onze eerdere tutorial kwamen we erachter dat we in een praktisch QA-project begonnen met het SRS-review en het schrijven van testscenario's - wat eigenlijk de 2e stap is in het STLC-proces. Het testontwerp omvat de details over wat te testen en hoe te testen.
Waarom zijn we niet begonnen met testplanning?
Planning is inderdaad de eerste en belangrijkste activiteit die plaatsvindt in elk testproject.
Testplanning tijdens SDLC-fasen
| SDLC-fase | Test de planningsactiviteit |
|---|---|
| Schema's => | Test scenario voorbereiding |
| Initiëren | Idealiter zou het QA-team moeten worden betrokken terwijl de reikwijdte van het project wordt verzameld van de klant / opdrachtgever in de vorm van zakelijke vereisten. Maar in de echte wereld is dat niet het geval. Praktisch gezien is de betrokkenheid van het QA-team NIL. Aan het einde van deze fase wordt BRD afgerond en wordt een basisprojectplan opgesteld. |
| Bepalen | SRS is gemaakt op basis van de BRD. Het eerste concept van het testplan wordt gemaakt. Op dit punt is de reikwijdte van het testen niet duidelijk, aangezien het QA-team nog niet klaar is met de SRS-beoordeling. De TP in deze fase bevat dus alleen informatie over wanneer het testen gaat plaatsvinden, projectinformatie en de teaminformatie (als we die hebben). |
| Ontwerp | De SRS-beoordeling wordt uitgevoerd en de reikwijdte van de tests wordt bepaald. We hebben veel meer informatie over wat we moeten testen en een goede inschatting van het aantal testgevallen dat we zouden kunnen krijgen enz. Er wordt een tweede versie van het testplan gemaakt waarin al deze informatie is verwerkt. |
Uit bovenstaande tabel blijkt heel duidelijk dat een testplan niet zomaar een document is dat je in één keer kunt maken en vanaf dan kunt gebruiken.
Onderdelen van een plandocument
| Items in een testplansjabloon | Wat zit er in? |
|---|---|
| Toepassingsgebied => | Testscenario's / testdoelen die zullen worden gevalideerd. |
| Buiten bereik => | Meer duidelijkheid over wat we niet gaan behandelen |
| Veronderstellingen => | Alle voorwaarden die moeten gelden om succesvol verder te kunnen gaan |
| Testdocumentatie - testgevallen / testgegevens / omgeving instellen | |
| Testuitvoering | |
| Testcyclus - hoeveel cycli | |
| Start- en einddatum voor cycli | |
| Rollen en verantwoordelijkheden => | Teamleden worden vermeld |
| Wie moet wat doen | |
| module-eigenaren worden vermeld en hun contactgegevens | |
| Deliverables => | Welke documenten (testartefacten) gaan produceren op welk tijdsbestek? |
| Wat kan van elk document worden verwacht? | |
| Omgeving => | Welke omgevingsvereisten zijn er? |
| Wie krijgt de leiding? | |
| Wat te doen bij problemen? | |
| Tools => | Bijvoorbeeld JIRA voor het opsporen van fouten |
| Log in | |
| Hoe gebruik je JIRA? | |
| Defect Management => | Aan wie gaan we de gebreken melden? |
| Hoe gaan we rapporteren? | |
| Wat wordt er verwacht - bieden we een screenshot? | |
| Risico's en risicobeheer => | Risico's worden opgesomd |
| Risico's worden geanalyseerd - waarschijnlijkheid en impact worden gedocumenteerd | |
| Plannen voor risicobeperking worden opgesteld | |
| Afsluitcriteria => | Wanneer moet u stoppen met testen? |
Aangezien alle bovengenoemde informatie de meest kritische zijn voor de dagelijkse werking van een QA-project is het belangrijk om het plandocument zo nu en dan up-to-date te houden.
Voorbeeldtestplan-document voor een live project
Er is een voorbeeldtestplan-sjabloondocument gemaakt voor onze ' ORANGEHRM VERSION 3.0 - MY INFO MODULE ” Project en hieronder bijgevoegd. Kijk er eens naar. Er zijn aanvullende opmerkingen aan het document toegevoegd in het rood om de secties uit te leggen.
Dit testplan is zowel voor de functionele als voor de UAT-fasen. Het legt ook het testbeheerproces uit met behulp van de HP ALM-tool.
Download testplan voorbeeld:
Doc-indeling Klik hier om het testplan in Doc-formaat te downloaden dit is degene die we hebben gemaakt voor het OragngeHRM live-project en we gebruiken dit ook voor onze crashcursus Software Testing.
PDF-formaat Klik hier om het testplan in pdf-bestandsformaat te downloaden
Werkbladbestanden (.xls) waarnaar wordt verwezen in de bovenstaande doc / pdf-versies Download de XLS-bestanden verwezen in het bovenstaande testplan
Het bovenstaande sjabloon is zeer uitgebreid en ook gedetailleerd. Lees het daarom grondig door voor de beste resultaten.
Aangezien het plan ook goed is gemaakt en uitgelegd, gaan we door naar de volgende fase in zowel SDLC als STLC.
SDLC's code:
Terwijl de rest van het project hun tijd besteedde aan het maken van TDD's, hebben wij, QA's, het testbereik (testscenario's) geïdentificeerd en het eerste betrouwbare concept van het testplan gemaakt. De volgende fase van SDLC is om te controleren wanneer de codering plaatsvindt.
In deze fase zijn ontwikkelaars het primaire aandachtspunt voor het hele team. Een team van QA geeft zich ook over aan de allerbelangrijkste taak die niets anders is dan 'Testcase maken'
Als de testscenario's 'wat te testen' waren, dan gaan de testgevallen over 'hoe te testen'. Het maken van testcases is een overheersend onderdeel van de testontwerpfase van de STLC. De input voor het maken van een testcase zijn de testscenario's en het SRS-document.
Voor testers zoals wij, Testgevallen zijn de real deal - het zijn de dingen waarin we de meeste tijd doorbrengen. We maken ze, beoordelen ze, voeren ze uit, onderhouden ze, automatiseren ze - en nou ja, je snapt het wel. Hoe ervaren we ook zijn en welke rol we spelen in een project - we zouden nog steeds met de testcases werken.
Testplanning versus testuitvoering
Softwaretestplanning reserveert een veel betere reikwijdte in vergelijking met de STLC-fase De levering van kwaliteitssoftware wordt verzekerd door het testteam. En wat er bij het testen moet gebeuren, wordt feitelijk beslist in de testplanningsfase.
Deze sectie geeft een compleet overzicht en bevat illustraties over het belang van testplanning en de uitvoeringsfase Na het lezen begrijp je het grote belang van de planningsfase in vergelijking met de uitvoeringsfase met meer live voorbeelden en casestudy's voor illustraties
Testplanning
Hieronder staan een aantal essentiële zaken die u tijdens het plannen in acht moet nemen:
Het plannen van een test is het belangrijkste onderdeel van de testcyclus. De uitkomst van de testfase wordt bepaald door de kwaliteit en omvang van de planning die voor het testen is gedaan.
Het plannen van de test gebeurt meestal tijdens de ontwikkelingsfase om de doorlooptijd voor de uitvoering van de test te besparen in overleg met alle betrokken partijen.
Enkele belangrijke feiten die moeten worden opgemerkt, zijn onder meer:
- De planning moet parallel met de ontwikkeling worden gestart, op voorwaarde dat de vereisten zijn bevroren.
- Alle belanghebbenden zoals ontwerpers, ontwikkelaars, klanten en testers moeten worden betrokken bij het finaliseren van het plan.
- Planning kan niet worden uitgewerkt voor onbevestigde of niet-goedgekeurde zakelijke behoeften.
- Soortgelijke testplannen zullen worden toegepast op de nieuwe vereisten die het bedrijf zal stellen.
Voorbeeld 1
Het ontwikkelingsteam werkt aan een software XYZ nadat het een paar vereisten van de klanten heeft gekregen. Het testteam is bijna begonnen met de voorbereiding op de testbepalende of planningsfase. Testplanning moet worden ontworpen om te voldoen aan de initiële vereisten die door de klanten worden genoemd. Dit is gedaan door het testteam.
Geen van de andere belanghebbenden was tijdens deze fase betrokken en de planning is bevroren.
wat is de beste c ++ compiler
Het ontwikkelingsteam heeft nu enkele wijzigingen aangebracht in de bedrijfsstroom om een paar problemen in hun werk aan te pakken met goedkeuring van de klant. Nu is de software naar het testteam gekomen voor een test. Met het testplan volgens de oude bedrijfsstroom is het testteam begonnen met hun testronde. Dit had veel vertraging op de testresultaten omdat de gewijzigde bedrijfsstroom niet werd gedeeld met het testteam.
Observatie uit voorbeeld 1:
Er zijn bepaalde opmerkingen uit het bovenstaande voorbeeld.
Zij zijn:
- Het begrijpen van de nieuwe bedrijfsstroom kostte veel tijd.
- Vertragingen in projectresultaten.
- Herwerken aan planning en de andere taken in de fase.
Al deze observaties moeten worden omgezet in essentiële behoeften voor een effectief testresultaat.
Hoofdcomponenten in de planningsfase
Hieronder worden de belangrijkste componenten weergegeven die bij de planningsfase betrokken zijn.
- Teststrategie: Dit is een van de belangrijkste secties die de strategie kunnen uitleggen die tijdens het testen zal worden gebruikt.
- Testdekking: Dit is in wezen vereist en het zal conformiteit in kaart brengen van de zakelijke behoeften en de testcases, zodat men kan controleren of de volledige software is getest of niet.
- Testcycli en duur: Dit kan erg kritiek worden, afhankelijk van de ontwikkelingsronden en hun tijd voor het voltooien van elke ronde.
- Pass / Fail-criteria: Het is een zeer vereiste waarin de criteria voor slagen en mislukken worden gedefinieerd. Een paar keer wordt dit ook bepaald door de klanten.
- Zakelijke en technische vereisten: De noodzaak om de software te hebben en de doeleinden die ze dienen, zullen duidelijk worden gedefinieerd, samen met de uitleg op laag niveau.
Beperkingen
Er zijn maar weinig dingen die de softwaretestfase kunnen sturen, met name de planningsfase.
Hieronder volgen enkele gebieden:
- Eigenschappen die wel en niet te testen zijn: Dit zal duidelijk aangeven wat er getest moet worden en wat niet.
- Opschortingscriteria en hervattingsvereisten: Dit is de beslisser over de ontwikkelde software en de criteria die zijn gedefinieerd om het testen op te schorten of het testen te hervatten.
- Verantwoordelijkheden: Een tester heeft meerdere verantwoordelijkheden bij het controleren van de problemen, bugs en defecten in de te testen software. Bovendien moeten de bugs worden gevalideerd met de ontwikkelaars om ze op te lossen.
- Risico's en onvoorziene omstandigheden: Risico's die tijdens het testen zijn verbonden, moeten duidelijk worden vermeld en de juiste onvoorziene gebeurtenissen gedurende de tijd moeten zeer duidelijk worden gedefinieerd.
Casestudy # 1
Het ontwikkelteam van Voorbeeld 1 is van plan om de software XYZ in 2 fasen uit te brengen. Fase 1 heeft veel functies die moeten worden getest en enkele die niet moeten worden getest. Opnieuw is de software vrijgegeven om te testen zonder het testteam op de hoogte te houden van de features die nog ontwikkeld moeten worden.
Nu begint het testteam met de uitvoering op basis van de testplannen die ze al hebben uitgewerkt. Ze komen met een groot aantal bugs. En na validatie door het ontwikkelingsteam worden de meeste ongeldig.
Waarnemingen uit de bovenstaande casestudy:
- Ontwikkelteam om de software vrij te geven aan het testteam met release-opmerkingen en notities voor de dekking van vereisten (release-opmerkingen).
- Functies die wel en niet getest moeten worden, moeten voor het testen in rekening worden gebracht op basis van de vrijgegeven software.
- Opschortings- en hervattingscriteria voor het testen moeten correct worden gedefinieerd.
- Risico's en de noodplannen voor het niet beschikbaar zijn van de software moeten perfect in beeld worden gebracht.
Lees ook Risico's beheren tijdens de testplanningsfase
Testuitvoeringsplan
Het uitvoeren van testcases is een van de stappen in de STLC-fase. Dit zal moeten gebeuren conform de plannen die eerder zijn uitgewerkt. Daarom blijft de planning de hele testfase domineren. Hieronder ziet u een voorbeeld waarbij het testteam wordt beïnvloed door de wijzigingen in de testplannen.
Voorbeeld 2
Het testen van de software A is gestart op basis van plan 1 dat door het team is uitgewerkt. Later, als gevolg van de zakelijke behoeften en de wijzigingen, moest het testplan enkele wijzigingen ondergaan. Dit heeft er op zijn beurt toe geleid dat de testgevallen of de uitvoering moesten worden gewijzigd.
Observaties:
- Het testplan bepaalt de uitvoering van de testcase.
- Het uitvoeringsgedeelte varieert volgens het plan.
- Zolang het plan en de eisen geldig zijn, zijn de testcases ook geldig.
Manieren om problemen tijdens de uitvoering te overwinnen
Testers zullen tijdens het uitvoeren van de test vaker verschillende scenario's tegenkomen. Dit is wanneer de testers de manieren moeten begrijpen en kennen om het probleem op te lossen of op zijn minst een oplossing voor het probleem moeten vinden.
Voorbeeld # 3
Tijdens de uitvoering van de testcase van software B komt het testteam meerdere problemen tegen. Weinigen van hen zijn showstoppers. Ze hebben ontwikkelaars nodig om hen te helpen het probleem op te lossen. Dit is verschillende keren gebeurd en het resultaat hiervan is een vertraging bij het testen van de resultaten.
Observaties:
- Er is een afhankelijkheid voor het overwinnen van milieuproblemen en -kwesties.
- Een goed begrip van de omgeving is vereist voor testers.
- Veel voorkomende en bekende problemen moeten worden gedocumenteerd om ze in de toekomst te verhelpen.
Versiebeheer en -beheer
Versiebeheer en het beheer van testplannen en de testgevallen zijn erg belangrijk om de tijdige resultaten te laten zien. Dit is belangrijker en wordt vaak gedaan met behulp van een versiebeheertool.
Een versiecontroletool helpt hen niet alleen om de testplannen te controleren, maar ook bij het beheer van defecten. Wanneer er testprojecten zijn met meerdere cycli en releases, kunnen deze tools echt veel helpen bij het verlagen van de statistieken voor het ondersteunen van de testresultaten.
Lees ook Risicobeheer tijdens de testuitvoeringsfase
Verschil tussen testplanning en testuitvoering
Hierna volgen enkele belangrijke gebieden die aangeven hoe de planning zal verschillen van de testuitvoeringsfase.
| Vergelijkingsgebied | Testplanning | Testuitvoering |
|---|---|---|
| Leverbare positionering | Testplan wordt beschouwd als een belangrijk resultaat voor de testactiviteit. Dit wordt gedaan als de eerste stap in het testproces. | Dit komt als laatste banklid in de testfase. Na de uitvoering worden de defecten / bugs-status samen met de uitvoeringsstatus van de testcase gedeeld als een van de testresultaten |
| Verantwoordelijke persoon | De testmanager bereidt het testplan voor en deelt het ter beoordeling met alle belanghebbenden. | Dit wordt normaal gesproken gedaan door de tester, waarbij er rekening mee wordt gehouden dat de voorbereide testcases zijn goedgekeurd en ondertekend. |
| Belangrijkste focus | De aandachtsgebieden van het testplan zijn hoe het testen moet worden uitgevoerd, waar rekening mee moet worden gehouden en wat niet, de omgeving die kan worden gebruikt, testschema's etc. | De testuitvoering richt zich voornamelijk op de uitvoering van de testcases die worden aangeboden om op de software te testen. |
| Terugkerende of iteratieve modus | Dit is een eenmalige activiteit. Dat gezegd hebbende, het kan al dan niet aanpassingen vereisen voor de toekomstige releases van de software. | Er zijn 3 delen in dit gebied als we het hebben over iteratie. 1. Functioneel testen. 2. Regressietesten. 3. Opnieuw testen. |
| Ingangen | De input voor het maken van een testplan is echt vereist en moet worden geleverd door bedrijfsanalisten, architect, klanten enz., | Het testcase-document is de belangrijkste input. |
| Periode waarin het kan worden gestart | Het moet samen met de ontwikkelingscyclus worden gestart voor een effectief resultaat en om tijd te besparen. Maar er zijn weinig modellen zoals een watervalmodel waarbij de testfase pas begint nadat de ontwikkelingsfase is voltooid. | De uitvoering moet strikt worden gestart nadat de ontwikkeling van de software is voltooid. |
| Sluitingsperiode | Het testplan kent een dergelijke sluitingsperiode niet. Over het algemeen wordt een aftekening van alle belanghebbende partijen voor de software verstrekt. | De uitvoering voor een specifieke release of cyclus wordt als gesloten beschouwd wanneer alle testgevallen tegen de software zijn uitgevoerd. |
| Gereedschap gebruik | Er zullen niet veel tools worden gebruikt, aangezien de planningsactiviteit meer zal bestaan uit discussie en documentatie. Om eventuele wijzigingen in het plan bij te houden, gebruiken de testmanagers normaal gesproken elk versiebeheerprogramma zoals VSS of iets anders. | Het hangt af van de uitvoeringsmodus. In het geval van een handleiding wordt geen tool gebruikt voor de uitvoering. Maar voor het loggen van de defecten en het beheer zullen enkele tools worden gebruikt. In het geval van automatiseringstesten zal de uitvoering worden gedaan met behulp van tools zoals QTP, SELENIUM etc. |
| Gevolgen voor de resultaten | Dit heeft een grotere impact op alle testfasen | Dit heeft invloed op de volgende te testen cyclus of release. |
De bovenstaande illustraties hebben wellicht beter uitgelegd hoe belangrijk testplanningsactiviteiten zijn dan die van testuitvoering. Op de een of andere manier is de uitvoeringsfase een soort subset van het testplan.
Op basis van de teststrategie, aanpak en de andere zaken heeft het testplan een grotere kans om aangepast te worden om ruimte te geven aan de veranderingen. Het staat vast dat de uitvoering van een test afhangt van de testgevallen. Testcases zijn gebaseerd op de plannen. Wijzigingen in plannen zorgen dus voor wijzigingen in de testgevallen.
Maar omgekeerd hoeven veranderingen in testgevallen niet per se naar veranderingen te zoeken. Dit is een van de belangrijkste redenen waarom de planning bij blijft in vergelijking met de testuitvoeringsfase.
Onze aanstaande tutorial zal je meer uitleggen over het maken van testcases. Wat zijn ze? En hoe we ze voor ons kunnen laten werken, samen met de verschillende andere aspecten die verband houden met de testgevallen.
VOLGENDE zelfstudie=> QA-training dag-4: Testcases schrijven vanuit SRS-document
Ben jij een expert in het schrijven van een Testplan Document? Dan bent u hier aan het juiste adres om uw waardevolle tips voor verbetering te delen met de aankomende testers. Voel je vrij om je mening met ons te delen in de comments hieronder !!
Aanbevolen literatuur
- Voorbeeld van een softwaretestplan-sjabloon met indeling en inhoud
- Documentatiegids voor softwaretests (waarom het belangrijk is)
- Bronnen en downloads voor het testen van software voor QA
- Voorbeeldtestplan-document (testplanvoorbeeld met details van elk veld)
- Testuitvoering bij softwaretests: exact proces en plan met voorbeeld
- Hoe een teststrategiedocument te schrijven (met voorbeeldteststrategiesjabloon)
- Testcases schrijven vanuit SRS-document (DOWNLOAD Live Project-voorbeeldtestcases)
- Software Testcursus Syllabus - Online cursus Gedetailleerd trainingsplan