Menu

Wat is softwaretesten? 100+ gratis zelfstudies voor handmatig testen

what is software testing

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Een complete software-testgids met meer dan 100 handmatige testhandleidingen met testdefinities, typen, methoden en procesdetails:

Wat is softwaretesten?

Softwaretesten is een proces waarbij de functionaliteit van een applicatie wordt geverifieerd en gevalideerd om erachter te komen of deze voldoet aan de gespecificeerde eisen. Het is het proces van het vinden van defecten in een applicatie en het controleren waar de applicatie functioneert volgens de eisen van de eindgebruiker.

Wat is handmatig testen?

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

Wat je leert:

Lijst met handleidingen voor het handmatig testen van software

Dit is de meest diepgaande reeks tutorials over softwaretests. Doorloop de onderwerpen die in deze serie worden genoemd zorgvuldig om de basis- en geavanceerde testtechnieken te leren.

Deze reeks tutorials zou uw kennis verrijken en zal op zijn beurt uw testvaardigheden verbeteren.

Oefen end-to-end handmatig testen van gratis training op een live project:

Tutorial # 1: Basisprincipes van handmatige softwaretests
Tutorial # 2: Live Project introductie
Tutorial # 3: Testscenario schrijven
Tutorial # 4: Schrijf een testplan-document vanuit het niets
Tutorial # 5: Testcases schrijven vanuit SRS-document
Tutorial # 6: Testuitvoering
Tutorial # 7: Foutopsporing en testafmelding
Tutorial # 8: Software Testing Cursus

Software testen levenscyclus:

Tutorial # 1: STLC

Webtesten:

Tutorial # 1: Testen van webapplicaties
Tutorial # 2: Cross-browser testen

Beheer van testgevallen:

welke vr-headsets werken met xbox one

Tutorial # 1: Testgevallen
Tutorial # 2: Voorbeeld testcase-sjabloon
Tutorial # 3: Vereisten Traceerbaarheidsmatrix (RTM)
Tutorial # 4: Testdekking
Tutorial # 5: Test gegevensbeheer

Testbeheer:

Tutorial # 1: Teststrategie
Tutorial # 2: Testplan sjabloon
Tutorial # 3: Test schatting
Tutorial # 4: Test Management Tools
Tutorial # 5: HP ALM-zelfstudie
Tutorial # 6: Jira
Tutorial # 7: TestLink-zelfstudie

Technische testen:

Tutorial # 1: Gebruik casetesten
Tutorial # 2: State Transition testen
Tutorial # 3: Grenswaardeanalyse
Tutorial # 4: Equivalentiepartitionering
Tutorial # 5: Methodologieën voor het testen van software
Tutorial # 6: Agile-methodologie

Defectbeheer:

Tutorial # 1: Bug levenscyclus
Tutorial # 2: Bugrapportage
Tutorial # 3: Defect prioriteit
Tutorial # 4: Bugzilla-zelfstudie

Functioneel testen

Tutorial # 1: Testen van een eenheid
Tutorial # 2: Testen van gezond verstand en rook
Tutorial # 3: Regressietesten
Tutorial # 4: Systeemtesten
Tutorial # 5: Acceptatietesten
Tutorial # 6: Integratietesten
Tutorial # 7: UAT-gebruikersacceptatietest

Niet-functionele testen:

Tutorial # 1: Niet-functionele testen
Tutorial # 2: Prestatietests
Tutorial # 3: Beveiligingstests
Tutorial # 4: Testen van beveiliging van webapplicaties
Tutorial # 5: Bruikbaarheidstesten
Tutorial # 6: Compatibiliteitstesten
Tutorial # 7: Installatie testen
Tutorial # 8: Documentatie testen

Soorten softwaretests:

Tutorial # 1: Soorten testen
Tutorial # 2 ​ Black box testen
Tutorial # 3: Database testen
Tutorial # 4: End-to-end testen
Tutorial # 5: Exploratory Testing
Tutorial # 6: Incrementeel testen
Tutorial # 7: Toegankelijkheidstesten
Tutorial # 8: Negatieve tests
Tutorial # 9: Backend testen
Tutorial # 10: Alfatesten
Tutorial # 11: Beta testen
Tutorial # 12: Alpha versus bètatests
Tutorial # 13: Gamma Testing
Tutorial # 14: ERP Testing
Tutorial # 15: Statisch en dynamisch testen
Tutorial # 16: Adhoc testen
Tutorial # 17: Lokalisatie en internationaliseringstesten
Tutorial # 18: Automatiseringstesten
Tutorial # 19: White box testen

Software Testing Carrière:

Tutorial # 1: Een carrière in het testen van software kiezen
Tutorial # 2: Hoe u een taak voor QA-testen kunt krijgen - complete gids
Tutorial # 3: Carrière-opties voor testers
Tutorial # 4: Switch voor niet-IT naar software testen
Tutorial # 5: Start uw handmatige testcarrière
Tutorial # 6: Lessen die zijn opgedaan tijdens 10 jaar testen
Tutorial # 7: Overleven en vooruitgang boeken op het gebied van testen

Interview voorbereiding:

Tutorial # 1: QA Voorbereiding hervatten
Tutorial # 2: Handmatig testen van interviewvragen
Tutorial # 3: Vragen over automatiseringstesten
Tutorial # 4: QA Interview Vragen
Tutorial # 5: Behandel elk sollicitatiegesprek
Tutorial # 6: Krijg een testbaan als een frisser

Verschillende domeintoepassingen testen:

Zelfstudie # 1 ​ Testen van bankapplicaties
Tutorial # 2: Testen van toepassingen in de gezondheidszorg
Tutorial # 3: Betaalgateway testen
Tutorial # 4: Test Point of Sale (POS) -systeem
Tutorial # 5: E-commerce website testen

QA-certificering testen:

Tutorial # 1: Certificeringsgids voor softwaretests
Tutorial # 2: CSTE-certificeringsgids
Tutorial # 3: CSQA-certificeringsgids
Tutorial # 4: ISTQB-gids
Tutorial # 5: ISTQB Advanced

Geavanceerde handmatige testonderwerpen:

Tutorial # 1: Cyclomatische complexiteit
Tutorial # 2: Migratietesten
Tutorial # 3: Cloud testen
Tutorial # 4: ETL-testen
Tutorial # 5: Metrische gegevens voor softwaretests
Tutorial # 6: Webservices

Maak je klaar om de eerste tutorial in deze Manual Testing-serie te bekijken !!!

Inleiding tot handmatige softwaretests

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

En hoe weet u wat het verwachte gedrag is?

U zult het weten door de vereisten aandachtig te lezen of ernaar te luisteren en het volledig te begrijpen. Onthoud dat het heel erg belangrijk is om de vereisten volledig te begrijpen.

hoe float in java te declareren

Beschouw jezelf als een eindgebruiker van wat je gaat testen. Daarna bent u niet meer gebonden aan het document met softwarevereisten of woorden erin. U kunt dan de kernvereiste begrijpen en niet alleen het gedrag van het systeem toetsen aan wat er is geschreven of verteld, maar ook aan uw eigen begrip en aan dingen die niet zijn geschreven of verteld.

Soms kan het een gemiste vereiste (onvolledige vereiste) of een impliciete vereiste zijn (iets dat niet afzonderlijk hoeft te worden vermeld, maar waaraan moet worden voldaan), en u moet dit ook testen.

Verder hoeft een vereiste niet noodzakelijk gedocumenteerd te zijn. U kunt heel goed kennis hebben van de softwarefunctionaliteit of u kunt zelfs raden en dan stap voor stap testen. We noemen het over het algemeen ad-hoc testen of verkennende testen.

Laten we eens uitgebreid kijken:

Laten we eerst het feit begrijpen - Of u nu een softwareapplicatie of iets anders vergelijkt (laten we zeggen een voertuig), het concept blijft hetzelfde. Aanpak, tools en prioriteiten kunnen verschillen, maar het kerndoel blijft HETZELFDE en het is EENVOUDIG, d.w.z. het feitelijke gedrag vergelijken met het verwachte gedrag.

Ten tweede - Testen is als een houding of mentaliteit die van binnenuit moet komen. Vaardigheden kun je leren, maar je wordt pas een succesvolle tester als je standaard een aantal kwaliteiten in je hebt. Als ik zeg dat testvaardigheden kunnen worden geleerd, bedoel ik gericht en formeel onderwijs rond het softwaretestproces.

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

Lees het hier => Kwaliteiten van zeer effectieve testers

Ik raad ten zeerste aan om het bovenstaande artikel door te nemen voordat ik verder ga met deze tutorial. Het zal u helpen uw kenmerken te vergelijken met de kenmerken die worden verwacht in de rol van de softwaretester.

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

“Je nieuwsgierigheid, oplettendheid, discipline, logisch denken, passie voor werk en vermogen om dingen te ontleden, zijn van groot belang om een ​​destructieve en succesvolle tester te zijn. Het werkte voor mij en ik ben er sterk van overtuigd dat het ook voor jou zal werken. Als je deze kwaliteiten al hebt, dan moet het inderdaad ook voor jou werken. '

We hebben gesproken over de belangrijkste vereisten van software tester worden. Laten we nu eens kijken waarom Manual Testing een onafhankelijk bestaan ​​heeft en altijd zou hebben, met of zonder groei van Automation Testing.

Waarom is handmatig testen vereist?

Weet jij wat het beste is aan tester zijn, dat ook manuele tester?

Het is het feit dat u hier niet alleen op vaardigheden kunt vertrouwen. Je moet je denkproces hebben / ontwikkelen en verbeteren. Dit is iets dat je voor een paar dollar niet echt kunt kopen. Je moet er zelf aan werken.

Je zult wel moeten ontwikkel de gewoonte om vragen te stellen en je zult ze elke minuut moeten vragen als je aan het testen bent. Meestal zou u deze vragen aan uzelf moeten stellen dan aan anderen.

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

Laten we eens kijken naar deze eenvoudige stroom:

  • Jij doet iets ( acties uitvoeren ) terwijl je het met een bepaalde bedoeling observeert (in vergelijking met het verwachte). Nu jij observatie vaardigheden en discipline om dingen uit te voeren komt hier in beeld.
  • Voila! Wat was dat? Je hebt iets opgemerkt. Je merkte het omdat je perfect gaf aandacht voor de details voor u. Je laat het niet gaan, want je bent het nieuwsgierig ​Dit was niet in je plan dat er iets onverwachts / raars gaat gebeuren, je merkt het en je gaat het verder onderzoeken. Maar nu doe je het. Je kunt het loslaten. Maar je moet het niet laten gaan.
  • Je bent tevreden, je hebt de oorzaak, de stappen en het scenario ontdekt. Nu ga je dit goed en constructief communiceren naar het ontwikkelteam en de andere belanghebbenden in je team. Je zou het kunnen doen via een defect-opsporingsprogramma of mondeling, maar je moet er zeker van zijn dat dat zo is het constructief communiceren ​
  • Oeps! Wat als ik het op die manier doe? Wat moet ik doen als ik een juist geheel getal als invoer voer, maar met voorloopspaties? Wat nou als? … Wat nou als? … Wat nou als? Het eindigt niet gemakkelijk, het zou niet gemakkelijk moeten eindigen. Jij zal stel je voor veel situaties en scenario's en u zult inderdaad in de verleiding komen om ze ook uit te voeren.

Het onderstaande diagram geeft de levensduur van een tester weer:

Het leven van een tester

Lees de vier hierboven genoemde punten nog eens door. Is het je opgevallen dat ik het heel kort hield, maar toch het rijkste deel van het handmatig testen benadrukte? En heb je de vetgedrukte markering in een paar woorden opgemerkt? Dat zijn precies de belangrijkste eigenschappen die een manuele tester nodig heeft.

Denk je echt dat deze handelingen volledig kunnen worden vervangen door iets anders? En de populaire trend van vandaag: kan het ooit worden vervangen door automatisering?

In SDLC bij elke ontwikkelingsmethodologie blijven er maar weinig dingen constant. Als tester consumeer je de requirements, zet je ze om in testscenario's / testcases. Vervolgens voer je die testcases uit of automatiseer je ze direct (ik weet dat een paar bedrijven dat doen).

Wanneer u het automatiseert, is uw focus stabiel, namelijk het automatiseren van de geschreven stappen.

Laten we teruggaan naar het formele gedeelte, namelijk het handmatig uitvoeren van testcases.

Hierbij focus je niet alleen op het uitvoeren van de schriftelijke testcases, maar doe je daarbij ook veel verkennende toetsen. Weet je nog, je bent nieuwsgierig? En je zult het je voorstellen. En u zult niet kunnen weerstaan, u zult inderdaad doen wat u zich had voorgesteld.

De onderstaande afbeelding laat zien hoe het schrijven van testcases wordt vereenvoudigd:

Vereenvoudigd schrijven van testcases

Ik vul een formulier in en ik ben klaar met het invullen van het eerste veld. Ik ben te lui om met de muis de focus naar het volgende veld te verplaatsen. Ik druk op de ‘tab’ -toets. Ik ben ook klaar met het invullen van het volgende en laatste veld, nu moet ik op de knop Verzenden klikken, de focus ligt nog steeds op het laatste veld.

Oeps, ik druk per ongeluk op de ‘Enter’ -toets. Laat me eens kijken wat er is gebeurd. OF er is een verzendknop, ik ga erop dubbelklikken. Niet tevreden. Ik klik er meerdere keren op, te snel.

Is het je opgevallen? Er zijn zoveel mogelijke gebruikersacties, zowel bedoelde als niet-bedoelde.

U zult er niet in slagen om alle testcases te schrijven die uw aanvraag voor 100% dekken. Dit moet verkennend gebeuren.

U gaat door met het toevoegen van uw nieuwe testcases terwijl u de applicatie test. Dit zijn testcases voor bugs die u bent tegengekomen waarvoor voorheen geen testcase was geschreven. Of, terwijl u aan het testen bent, heeft iets uw denkproces op gang gebracht en heeft u nog een paar testcases die u aan uw testcase-suite wilt toevoegen en uitvoeren.

Zelfs na dit alles is er geen garantie dat er geen zijn verborgen bugs ​Software zonder bugs is een mythe. Je kunt alleen richten om het dicht bij nul te brengen, maar dat kan gewoon niet gebeuren zonder dat een menselijke geest zich voortdurend op hetzelfde richt, vergelijkbaar met maar niet beperkt tot het voorbeeldproces dat we hierboven zagen.

Op dit moment is er in ieder geval geen software die denkt als een menselijke geest, observeert als een menselijk oog, vragen stelt en antwoordt als een mens, en dan bedoelde en niet-bedoelde acties uitvoert. Zelfs als zoiets gebeurt, wiens geest, gedachten en oog zullen het dan nabootsen? Van jou of van mij? Wij mensen hebben ook niet hetzelfde recht. We zijn allemaal verschillend. Vervolgens?

Noodzaak voor handmatig testen wanneer automatisering in de buurt is:

Automatiseringstests hebben tegenwoordig zijn eigen glorie en zullen er de komende jaren nog meer hebben, maar het kan eenvoudigweg geen handmatige QA-tests vervangen (lees menselijke / verkennende tests).

Je moet het eerder hebben gehoord- ‘ U automatiseert het testen niet, u automatiseert het controleren ​Deze zin spreekt veel over waar handmatige QA-tests staan ​​met automatiseringstests. Veel grote namen over de hele wereld hebben over dit onderwerp geschreven en gesproken, dus ik zal hier niet veel nadruk op leggen.

Automatisering kan menselijke tests niet vervangen, omdat:

  • Het vereist de runtime-oordelen over alles wat er voor je ogen gebeurt (terwijl je test) en in enkele gevallen ook achter de schermen.
  • Het vereist duidelijke en constante observatie.
  • Het vereist Ondervragen.
  • Het vereist een onderzoek.
  • Het vereist redenering.
  • Het vereist ongeplande acties zoals vereist tijdens het testen.

Testen kan worden vervangen door een tool / machine die in staat is 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 tijdens runtime en in alle mogelijke contexten. Deze tool moet weer zijn zoals alle mogelijke mensen.

Kortom, menselijke tests kunnen niet worden vervangen. Misschien zal een sci-fi film uit Hollywood over een paar jaar er dichtbij komen, maar in het echte leven zie ik het pas een paar honderd jaar aankomen, dat kan ik me voorstellen. Ik zal het niet voor altijd afschrijven omdat ik geloof in eindeloze mogelijkheden.

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

= >> Aanbevolen literatuur - Beste servicebedrijven voor handmatige tests

Hoe automatisering een aanvulling vormt op handmatige tests?

Ik zei eerder en ik zeg het nogmaals dat automatisering niet meer kan worden genegeerd. In de wereld waar continue integratie, continue levering en continue implementatie verplichte dingen worden, kan continu testen niet stilzitten. We moeten manieren vinden om dit te doen.

Meestal helpt het op de lange termijn niet om steeds meer personeel in te zetten voor deze taak. Daarom moet de tester (testleider / architect / manager) voorzichtig beslissen wat er moet worden geautomatiseerd en wat er nog handmatig moet gebeuren.

Het wordt uitermate belangrijk om zeer nauwkeurige tests / controles te laten schrijven, zodat ze kunnen worden geautomatiseerd zonder enige afwijking van de oorspronkelijke verwachting en kunnen worden gebruikt terwijl het product terugloopt als onderdeel van ‘Continuous Testing’.

Notitie: Het woord continu van de term ‘Continu testen’ wordt onderworpen aan voorwaardelijke en logische aanroepen, vergelijkbaar met de andere termen die we hierboven hebben gebruikt met hetzelfde voorvoegsel. Continu betekent in deze context steeds vaker, sneller dan gisteren. Hoewel het in betekenis is, kan het heel goed elke seconde of nanoseconde betekenen.

Zonder een perfecte match van menselijke testers en geautomatiseerde controles (tests met precieze stappen, verwacht resultaat en exitcriteria van genoemde test gedocumenteerd), is het bereiken van continu testen erg moeilijk en dit zal op zijn beurt zorgen voor continue integratie, continue levering en continue implementatie moeilijker.

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

Voorbeeld:

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

Inlogfunctionaliteit moet dan uw eerste geautomatiseerde controle zijn en uw automatiseringssuite mag niet de volgende controle uitvoeren waarbij inloggen een vereiste is, zoals het posten van een status. U weet heel goed dat het zal mislukken. Laat het dus sneller falen, publiceer de resultaten sneller zodat het defect sneller kan worden verholpen.

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

Selecteer testcases die, indien geautomatiseerd, aanzienlijk zullen profiteren voor menselijke testers en heeft een goed investeringsrendement. Overigens is er een algemene regel die zegt dat je moet proberen al je Priority 1-testcases te automatiseren en indien mogelijk dan Priority 2.

Automatisering is niet eenvoudig te implementeren en kost veel tijd, dus het is aan te raden om gevallen met lage prioriteit niet te automatiseren, in ieder geval tot het moment dat u klaar bent met de hoge gevallen. Door te selecteren wat te automatiseren en erop te focussen, verbetert de kwaliteit van de applicatie bij continu gebruik en onderhoud.

Gevolgtrekking

Ik hoop dat u inmiddels begrepen heeft waarom en hoe slecht handmatige / menselijke tests nodig zijn om kwaliteitsproducten te leveren en hoe automatisering dit aanvult.

Het belang van handmatige QA-testen accepteren en weten waarom het speciaal is, is de allereerste stap om een ​​uitstekende handmatige tester te worden.

In onze aanstaande tutorials voor handmatig testen, zullen we een generieke benadering behandelen voor het uitvoeren van handmatige tests, hoe dit naast automatisering zal bestaan ​​en ook vele andere belangrijke aspecten.

Ik ben er zeker van dat je een enorme kennis van softwaretests zult opdoen als je de volledige lijst met tutorials in deze serie doorloopt.

hoe je een java-project start in eclipse

We horen graag van je. Voel je vrij om je mening / suggesties te geven in de comments hieronder.

Aanbevolen literatuur

^