Wat is Software Testen? 100+ Gratis Handmatige Testen Handleidingen

Een complete Software Testen Gids met 100+ Handmatige Testen Handleidingen met Testen Definitie, Soorten, Methoden, en Proces Details:

Wat is Software Testen?

Software testen is een proces van verifiëren en valideren van de functionaliteit van een applicatie om te vinden of het voldoet aan de gespecificeerde eisen. Het is het proces van het vinden van gebreken in een toepassing en controleer of de toepassing functioneert volgens de eisen van de eindgebruiker.

Wat is Manual Testing?

Manual Testing is een proces waarin je het gedrag van een ontwikkeld stuk code (software, module, API, functie, enz.) te vergelijken met het verwachte gedrag (Requirements).

Lijst van Manual Software Testing Tutorials

Dit is de meest diepgaande serie van tutorials over Software Testing. Ga door de onderwerpen die in deze serie zorgvuldig om de basis-en geavanceerde testtechnieken te leren.

Deze serie tutorials zou verrijken uw kennis en zal op zijn beurt, het verbeteren van uw testvaardigheden.

Practice End-to-End Handmatig Testen Gratis Training op een Live Project:

Tutorial #1: Basics van Handmatig Software Testen
Tutorial #2: Live Project Introductie
Tutorial #3: Test Scenario Schrijven
Tutorial #4: Schrijf een Test Plan Document vanaf nul
Tutorial #5: Schrijf Test Cases vanuit SRS Document
Tutorial #6: Test Uitvoering
Tutorial #7: Bug Tracking en Test Sign off
Tutorial #8: Software Testing Course

Software Testing Life-Cycle:

Tutorial #1: STLC

Web Testing:

Tutorial #1: Web Applicatie Testen
Tutorial #2: Cross Browser Testen

Test Case Management:

Tutorial #1: Test Cases
Tutorial #2: Sample Test Case Template
Tutorial #3: Requirements Traceability Matrix (RTM)
Tutorial #4: Test Coverage
Tutorial #5: Test Data Management

Test Management:

Tutorial #1: Test Strategie
Tutorial #2: Test Plan Template
Tutorial #3: Test Estimation
Tutorial #4: Test Management Tools
Tutorial #5: HP ALM Tutorial
Tutorial #6: Jira
Tutorial #7: TestLink Tutorial

Test Technieken:

Tutorial #1: Use Case Testing
Tutorial #2: State Transition testing
Tutorial #3: Boundary Value Analysis
Tutorial #4: Equivalence Partitioning
Tutorial #5: Software test methodologieën
Tutorial #6: Agile Methodologie

Defect Management:

Tutorial #1: Bug Life Cycle
Tutorial #2: Bug Reporting
Tutorial #3: Defect Priority
Tutorial #4: Bugzilla Tutorial

Functioneel Testen

Tutorial #1: Unit Testing
Tutorial #2: Sanity and Smoke Testing
Tutorial #3: Regression Testing
Tutorial #4: System Testing
Tutorial #5: Acceptatietests
Tutorial #6: Integratietests
Tutorial #7: UAT gebruikersacceptatietests

Niet-functionele tests:

Tutorial #1: Niet-functionele tests
Tutorial #2: Prestatietests
Tutorial #3: Veiligheidstests
Tutorial #4: Webapplicatie veiligheidstests
Tutorial #5: Bruikbaarheidstests
Tutorial #6: Compatibiliteitstest
Tutorial #7: Installatietest
Tutorial #8: Documentatietest

Soorten softwaretests:

Tutorial #1: Soorten tests
Tutorial #2: Black box Testing
Tutorial #3: Database Testing
Tutorial #4: End to end Testing
Tutorial #5: Exploratory Testing
Tutorial #6: Incremental Testing
Tutorial #7: Accessibility Testing
Tutorial #8: Negative Testing
Tutorial #9: Backend Testing
Tutorial #10: Alpha Testing
Tutorial #11: Beta Testing
Tutorial #12: Alpha vs Beta Testing
Tutorial #13: Gamma Testing
Tutorial #14: ERP Testing
Tutorial #15: Static and Dynamic Testing
Tutorial #16: Adhoc testing
Tutorial #17: Localization and Internationalization Testing
Tutorial #18: Automatiseringstesten
Tutorial #19: White box testing

Software Testing Career:

Tutorial #1: Choosing a Software Testing Career
Tutorial #2: How to Get QA Testing Job – Complete Guide
Tutorial #3: Career options for Testers
Tutorial #4: Non-IT naar Software Testing Switch
Tutorial #5: Kick Start Your Manual Testing Career
Tutorial #6: Lessons Learned from 10 Years in Testing
Tutorial #7: Survive and Progress in Testing Field

Interview Voorbereiding:

Tutorial #1: QA CV voorbereiding
Tutorial #2: Manual Testing Interview Vragen
Tutorial #3: Automation Testing Interview Vragen
Tutorial #4: QA Interview Vragen
Tutorial #5: Handle Any Job Interview
Tutorial #6: Get Testing Job as a Fresher

Testen van verschillende domeinen toepassing:

Tutorial #1: Banking Application Testing
Tutorial #2: Health Care Application Testing
Tutorial #3: Payment Gateway Testing
Tutorial #4: Test Point of Sale (POS) System
Tutorial #5: eCommerce Website Testing

Testing QA Certification:

Tutorial #1: Software Testing Certification Guide
Tutorial #2: CSTE Certification Guide
Tutorial #3: CSQA Certification Guide
Tutorial #4: ISTQB Guide
Tutorial #5: ISTQB Advanced

Advanced Manual Testing Topics:

Tutorial #1: Cyclomatic Complexity
Tutorial #2: Migration Testing
Tutorial #3: Cloud Testing
Tutorial #4: ETL Testing
Tutorial #5: Software Testing Metrics
Tutorial #6: Web Services

Bekijk nu de 1e tutorial in deze Manual Testing serie!

Inleiding tot Handmatig Software Testen

Handmatig testen is een proces waarin je het gedrag van een ontwikkeld stuk code (software, module, API, feature, etc.) vergelijkt met het verwachte gedrag (requirements).

En hoe weet je wat het verwachte gedrag is?

Dat weet je door de requirements zorgvuldig te lezen of te beluisteren en ze volledig te begrijpen. Onthoud, het volledig begrijpen van de requirements is heel erg belangrijk.

Denk jezelf als een eindgebruiker van wat je gaat testen. Daarna ben je niet meer gebonden aan het software requirement document of de woorden die erin staan. Je kunt dan de kern van de requirement begrijpen en niet alleen het gedrag van het systeem toetsen aan wat er staat of wordt verteld, maar ook aan je eigen inzicht en aan zaken die niet staan geschreven of worden verteld.

Op sommige momenten kan er sprake zijn van een gemiste requirement (onvolledige requirement) of een impliciete requirement (iets wat niet apart genoemd hoeft te worden, maar wel aan moet voldoen), en ook daar moet je op testen.

Verder hoeft een requirement niet noodzakelijkerwijs een gedocumenteerde requirement te zijn. Je kunt heel goed kennis hebben van de softwarefunctionaliteit of je kunt zelfs gissen en dan stap voor stap testen. Over het algemeen noemen we dit ad-hoc testen of exploratief testen.

Laten we eens diepgaand kijken:

Laten we eerst het feit begrijpen – Of je nu een software applicatie vergelijkt of iets anders (laten we zeggen een voertuig), het concept blijft hetzelfde. De aanpak, hulpmiddelen en prioriteiten kunnen verschillen, maar de kerndoelstelling blijft dezelfde en is SIMPEL, namelijk het vergelijken van het werkelijke gedrag met het verwachte gedrag.

Ten tweede – Testen is als een houding of mindset die van binnenuit moet komen. Vaardigheden kunnen worden aangeleerd, maar je wordt pas een succesvolle tester als je een aantal kwaliteiten standaard in je hebt. Als ik zeg dat testvaardigheden kunnen worden aangeleerd, bedoel ik gericht en formeel onderwijs rond het software testproces.

Maar wat zijn de kwaliteiten van een succesvolle tester? Je kunt erover lezen op de onderstaande link:

Lees het hier =>Qualities of Highly Effective Testers

Ik raad je sterk aan om het bovenstaande artikel door te nemen voordat je verder gaat met deze tutorial. Het zal je helpen om je karakteristieken te vergelijken met degene die verwacht worden in de rol van Software Tester.

Voor degenen die geen tijd hebben om het artikel door te nemen, is hier een samenvatting:

“Je nieuwsgierigheid, oplettendheid, discipline, logisch denken, passie voor het werk en het vermogen om dingen te ontleden maakt veel uit om een Destructieve en Succesvolle Tester te zijn. Het werkte voor mij en ik ben ervan overtuigd dat het ook voor jou zal werken. Als je deze kwaliteiten al hebt, dan moet het inderdaad ook voor jou werken.”

We hebben het gehad over de belangrijkste vereisten om een software tester te worden. Laten we nu eens begrijpen waarom Manual Testing heeft en zou altijd zijn onafhankelijke bestaan met of zonder Automation Testing groei.

Waarom Manual Testing is Required?

Weet je wat is het beste ding over het feit dat een Tester, dat ook een Manual Tester?

Het is het feit dat je hier niet alleen afhankelijk kunt zijn van je skillset. Je moet je denkproces hebben/ontwikkelen en verbeteren. Dit is iets wat je niet echt voor een paar dollar kunt kopen. Je moet er zelf aan werken.

Je moet de gewoonte ontwikkelen om vragen te stellen en je moet ze elke minuut stellen als je aan het testen bent. Meestal moet je deze vragen aan jezelf stellen dan aan anderen.

Ik hoop dat je het artikel hebt doorgenomen dat ik in de vorige paragraaf heb aanbevolen (d.w.z. de kwaliteiten van zeer effectieve testers). Zo ja, dan zou je weten dat testen wordt beschouwd als een denkproces en hoe succesvol je zult zijn als tester hangt volledig af van de kwaliteiten die je als persoon bezit.

Laten we deze eenvoudige flow eens bekijken:

• Je doet iets (voert handelingen uit) terwijl je het met enige intentie observeert (vergelijkt met het verwachte). Nu komt je observatievermogen en discipline om dingen uit te voeren hier in beeld.
• Voila! Wat was dat? Je merkte iets op. Je merkte het op omdat je perfecte aandacht schonk aan de details voor je. Je laat het niet los omdat je nieuwsgierig bent. Dit was niet in uw plan dat er iets onverwachts/vreemds zal gebeuren, u zult het opmerken en u zult het verder onderzoeken. Maar nu doe je het. Je kan het laten gaan. Maar je moet het niet laten gaan.
• Je bent blij, je bent achter de oorzaak, de stappen en het scenario gekomen. Nu ga je dit goed en constructief te communiceren naar het ontwikkelteam en de andere belanghebbenden in uw team. Je zou het kunnen doen via een defect tracking tool of mondeling, maar je moet ervoor zorgen dat je het constructief communiceert.
• Oeps! Wat als ik het op die manier doe? Wat als ik het juiste gehele getal als invoer invoer, maar met voorloop spaties? Wat als? … Wat als? … Wat als? Het eindigt niet gemakkelijk, het zou niet gemakkelijk moeten eindigen. Je zult je een heleboel & scenario’s voorstellen en je zult inderdaad in de verleiding komen om ze ook uit te voeren.

Het onderstaande diagram geeft het leven van een Tester weer:

Lees die vier bullet points van hierboven nog eens door. Heb je gemerkt dat ik het heel kort heb gehouden, maar toch het rijkste deel van het leven van een manuele tester heb belicht? En is het je opgevallen dat ik een paar woorden vet heb gedrukt? Dat zijn precies de belangrijkste kwaliteiten die een manueel tester nodig heeft.

Nu, denk je echt dat deze handelingen volledig vervangen kunnen worden door iets anders? En de hete trend van vandaag – kan het ooit worden vervangen door automatisering?

In SDLC met een ontwikkelingsmethodologie, weinig dingen blijven altijd constant. Als tester consumeer je de requirements, zet je ze om in Test Scenario’s/Test Cases. Vervolgens voer je die testgevallen uit of automatiseer je ze direct (ik weet dat een paar bedrijven dat doen).

Wanneer je automatiseert, is je focus constant, namelijk het automatiseren van de geschreven stappen.

Laten we teruggaan naar het formele deel, namelijk het uitvoeren van de handmatig geschreven testgevallen.

Hier richt je je niet alleen op het uitvoeren van de geschreven testgevallen, maar voer je ook veel verkennende tests uit terwijl je dat doet. Weet je nog, je bent nieuwsgierig? En je zult je voorstellen. En je zult het niet kunnen laten, je zult inderdaad doen wat je je hebt voorgesteld.

Het onderstaande beeld geeft weer hoe Test Case schrijven wordt vereenvoudigd:

Ik ben een formulier aan het invullen, en ik ben klaar met het invullen van het eerste veld. Ik ben te lui om de muis te pakken om de focus naar het volgende veld te verplaatsen. Ik druk op de ’tab’ toets. Ik ben klaar met het invullen van het volgende en laatste veld ook, nu moet ik klikken op de knop Submit, de focus is nog steeds op het laatste veld.

Oeps, ik heb per ongeluk op de ‘Enter’ toets gedrukt. Laat me eens kijken wat er gebeurd is. OF er is een submit knop, ik ga er dubbel op klikken. Niet tevreden. Ik klik er meerdere keren op, te snel.

Heb je het gemerkt? Er zijn zoveel mogelijke gebruikersacties, zowel bedoelde als niet-bedoelde.

Het zal je niet lukken om alle testgevallen te schrijven die je te testen applicatie voor 100% afdekken. Dit moet gebeuren op een verkennende manier.

Je gaat door met het toevoegen van je nieuwe testgevallen als je de applicatie test. Dit zullen testgevallen zijn voor bugs die je bent tegengekomen waarvoor eerder geen testgeval was geschreven. Of, terwijl u test, iets geactiveerd uw denkproces en je hebt een paar meer testgevallen die u wilt toevoegen aan uw test case suite en uit te voeren.

Zelfs na dit alles, is er geen garantie dat er geen verborgen bugs zijn. Software met nul bugs is een Mythe. Je kunt er alleen naar streven om het in de buurt van NUL te brengen, maar dat kan gewoon niet gebeuren zonder een menselijke geest die voortdurend op hetzelfde is gericht, vergelijkbaar met maar niet beperkt tot het voorbeeldproces dat we hierboven zagen.

Tot op heden bestaat er tenminste geen software die denkt als een menselijke geest, observeert als een menselijk oog, vragen stelt en antwoordt als een mens en vervolgens bedoelde en niet-bedoelde acties uitvoert. Zelfs als zoiets gebeurt, wiens geest, gedachten en ogen zal het dan nabootsen? De jouwe of de mijne? Wij, mensen, zijn ook niet gelijk. We zijn allemaal verschillend.

Noodzaak van handmatig testen als automatisering in de buurt is:

Automatisch testen heeft zijn eigen deel van de glorie deze dagen en zal nog meer in de komende jaren, maar het kan gewoon niet vervangen handmatig QA-testen (lees menselijke / verkennende testen).

U moet eerder hebben gehoord – ‘Je hoeft niet te automatiseren testen, je automatiseert controleren’. Deze zin spreekt veel over waar handmatige QA testen staat met Automation testen rond. Veel grote namen over de hele wereld hebben geschreven en gesproken over dit onderwerp, dus ik zal niet veel nadruk op deze.

Automatisering kan niet vervangen Human Testing, omdat:

• Het vereist de runtime oordelen over alles wat er gebeurt voor je ogen (terwijl je test) en in een paar gevallen achter de schermen ook.
• Het vraagt om duidelijke en constante observatie.
• Het vraagt om vragen stellen.
• Het vereist een onderzoek.
• Het vereist redeneren.
• Het vereist ongeplande acties zoals vereist tijdens het testen.

Testen kan worden vervangen door een tool/machine die in staat zal zijn om de details te absorberen, ze te verwerken, acties te bevelen en ze uit te voeren als een menselijke geest en mens, en dit alles op runtime en in alle mogelijke contexten. Dit hulpmiddel moet weer zijn als alle mogelijke mensen.

Dus in het kort, menselijk testen kan niet worden vervangen. Misschien dat een of andere Hollywood sci-fi flick over een paar jaar er dicht bij in de buurt komt, maar in het echte leven zie ik het nog wel een paar honderd jaar niet komen, voor zover ik me dat kan voorstellen. Ik zal het niet voor altijd afschrijven, want ik geloof in eindeloze mogelijkheden.

Op een aparte noot, zelfs als het echt gebeurt na een paar honderd jaar, het beeld dat ik me kan voorstellen is dat van een enge wereld zeker. Age of Transformers. 🙂

=>> Recommended Reading – Best Manual Testing Service Companies

Hoe Automatisering Manual Testing aanvult?

Ik heb al eerder gezegd en ik zeg het nu weer: Automatisering kan niet meer genegeerd worden. In de wereld waar continue integratie, continue levering en continue inzet verplicht worden, kan continu testen niet stilzitten. We moeten manieren vinden om het te doen.

Merendeel van de tijd, het inzetten van meer en meer arbeidskrachten helpt niet op de lange termijn voor deze taak. Daarom moet de Tester (Test Lead/Architect/Manager) voorzichtig beslissen over wat te automatiseren en wat nog steeds handmatig moet worden gedaan.

Het wordt uiterst belangrijk om zeer precieze tests/controles te hebben geschreven, zodat ze kunnen worden geautomatiseerd zonder enige afwijking van de oorspronkelijke verwachting en kunnen worden gebruikt tijdens het regresseren van het product als onderdeel van ‘Continu Testen’.

Note: Het woord continu uit de term ‘Continu Testen’ is onderhevig aan voorwaardelijke en logische oproepen, vergelijkbaar met de andere termen die we hierboven gebruikten met hetzelfde voorvoegsel. Continu betekent in deze context meer en vaker, sneller dan gisteren. Terwijl het in betekenis heel goed elke seconde of Nano-seconde kan betekenen.

Zonder het hebben van een perfecte match van Menselijke Testers en geautomatiseerde controles (tests met precieze stappen, verwacht resultaat en exit criteria van genoemde test gedocumenteerd), is het bereiken van Continu Testen erg moeilijk en dit, op zijn beurt, zal continue integratie, continue levering en continue implementatie moeilijker maken.

Ik heb met opzet de term exit criteria van een test hierboven gebruikt. Onze automatiseringspakken kunnen niet meer lijken op de traditionele. We moeten ervoor zorgen dat als ze falen, ze snel falen. En om ze snel te laten falen, moeten ook de exit-criteria worden geautomatiseerd.

Voorbeeld:

Laten we zeggen dat er een blocker defect is, waardoor ik niet kan inloggen op Facebook.

Login-functionaliteit moet dan uw eerste geautomatiseerde controle zijn en uw automatiseringspakket moet niet de volgende controle uitvoeren waarbij inloggen een vereiste is, zoals het posten van een status. Je weet heel goed dat het zal mislukken. Dus laat het sneller mislukken, publiceer de resultaten sneller, zodat het defect sneller kan worden opgelost.

Het volgende is weer iets dat je eerder gehoord moet hebben – Je kunt en moet niet proberen om alles te automatiseren.

Selecteer testgevallen die, indien geautomatiseerd, aanzienlijk voordeel opleveren voor de menselijke testers en een goede Return on Investment hebben. Voor die kwestie, is er een algemene regel die zegt dat u zou moeten proberen om al uw Prioriteit 1 testgevallen te automatiseren en indien mogelijk dan Prioriteit 2.

Automatisering is niet gemakkelijk te implementeren en is tijdrovend, zodat het wordt geadviseerd om het automatiseren van lage prioriteitsgevallen te vermijden ten minste tot de tijd dat u klaar bent met de hoge degenen. Het selecteren van wat te automatiseren en zich daarop te concentreren verbetert de kwaliteit van de applicatie wanneer het continu wordt gebruikt en onderhouden.

Conclusie

Ik hoop dat je inmiddels hebt begrepen waarom en hoezeer handmatig/menselijk testen nodig is om Kwaliteitsproducten af te leveren en hoe Automatisering dit aanvult.

Het belang van QA handmatig testen accepteren en weten waarom het speciaal is, is de allereerste stap op weg naar het zijn van een uitstekende handmatige tester.

In onze komende handmatige test tutorials, zullen we een algemene aanpak voor het doen van Manual Testing, hoe het zal coëxisteren met Automatisering en vele andere belangrijke aspecten ook.

Ik ben er zeker van dat u immense kennis van Software Testing te krijgen als je eenmaal door te gaan de hele lijst van tutorials in deze serie.