Menu

6 basisvaardigheden die elke tester (voornamelijk frisser) zou moeten hebben

6 basic skills that every tester should have

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Software Testing of QA is het beste platform voor nieuwkomers om de IT-industrie te betreden, ondanks de misvattingen dat het een minder of lager betaalde baan is.

De belangrijkste vaardigheid die een tester nodig heeft, is de mogelijkheid om bugs te vinden ​En als je het soort persoon bent dat ervan houdt om bugs te vinden, dan zul je op dit gebied van gaan houden en groeien.

Dat gezegd hebbende, zijn er nog maar weinig vaardigheden die u kunnen helpen bugs te vinden en beter met QA-processen te werken.

Dit is het artikel dat het QA-proces laat zien zoals het in de meeste bedrijven wordt gevolgd en dat nieuwe testers uitleg geeft over testen.

In detail leer je het documentatieproces en de standaarden, het voorwerk van de tester, het testen op basis van beperkingen, het testen tijdens de gedeeltelijke ontwikkeling en tot slot het afmeldingsproces.

basisvaardigheden testen

Laten we beginnen.

Wat je leert:

# 1. Documentatie

Documentatie is essentieel voor testen. De meeste bedrijven wijzen deze taak toe aan nieuwkomers. Om te slagen, zou je moeten hebben goede woordenschat omdat de rest van zaken, zoals documentatiestandaarden, enz. niet onder uw controle staan ​​en afhankelijk zijn van de processen van het team en het bedrijf.

Zorg er ook voor dat u de waarde van het documentatieproces ziet. De voordelen zijn legio: ze helpen u bij het volgen van wijzigingen in de vereisten, het traceren van uw teststappen, het loggen van uw werk, enz.

Aanbevolen om te lezen​ Waarom documentatie belangrijk is bij het testen van software

# 2. Voorbereiding van de test

Van alle beschikbare documenten mag het volgende niet worden genegeerd. Deze worden ook wel afleverbare documenten genoemd en ze overbruggen het begrip van de klant, ontwikkelaar en tester.

volledige join versus volledige outer join

a) Testplan: brengt de teststroom van begin tot eind in kaart ​

Testplan geeft de reikwijdte en activiteiten van de testfase weer. Gemaakt door de QA-leider, moet het team bijdragen en op de hoogte blijven van alles wat in het testplan staat.

Sommige teams hebben testplannen op meerdere niveaus: Masterplan en Fasegewijs plannen.

Een testplan moet beschikken over:

  • Projectnaam en versie
  • Testplan-ID's - Maker, conceptnummer, aanmaakdatum, etc.
  • Inleiding - Overzicht van het project, de doelstelling en de beperkingen
  • Referenties - Lijst met referenties die als invoer worden gebruikt. (Zorg ervoor dat u de juiste en laatste versies gebruikt)
  • Testitems - Modules, versie, bereik, buiten bereik, etc.
  • Algemene testaanpak / teststrategie - Te gebruiken tools, foutopsporingsproces, uit te voeren testniveaus, enz.
  • Pass / Fail itemcriteria - Richtlijnen voor testuitvoering
  • Criteria voor opschorting en hervatting
  • Testresultaten - Testcase, testrapporten, bugrapport, teststatistieken, etc.
  • Details testomgeving
  • Teamrooster met informatie over het contactpunt. voor elke module of testtype
  • Testschattingen - Tijd en moeite. Budgetgegevens zijn vertrouwelijk en u vindt ze hier niet
  • Risico's en mitigatieplannen
  • Goedkeuringen
  • Andere richtlijnen

Lees ook​

b) Testscenario's:

In één regel wordt verwezen naar ‘wat te testen’ op basis van elke vereiste en meestal gedocumenteerd en bijgehouden via spreadsheets.

De meeste bevatten:

  • Module / Component / functienaam (login, admin, registratie, etc.)
  • Scenario-ID is ter referentie (bijv .: TS_Login_001)
  • Scenario Beschrijving - ‘Wat te testen’ Bijv .: valideren of inloggen gebruikers met geldige inloggegevens toestaat om succesvol in te loggen
  • Scenario Belang - Prioriteit toekennen in geval van onvoldoende tijd - Hoog / Gemiddeld / Laag
  • Vereiste-ID - voor traceerbaarheid

Verder lezen​

c) Testgevallen:

Nauwkeurige testcases geven nauwkeurige testresultaten. Spreadsheets zijn nog steeds het populaire medium voor het schrijven van testcases, vooral voor beginners, ook al passen sommige bedrijven testbeheertools aan. De basis voor het schrijven van testcases is het SRS / FRD / Req-document. Maar het is vaak niet voldoende, dus je zult veel aannames en discussies met BA / Dev-teams moeten gebruiken.

Effectieve testcases schrijven is de belangrijkste kwalificatie die een tester moet hebben. Meestal worden alle testgevallen als positief / negatief gecategoriseerd. Positieve testcase geeft geldige input en behaalt positieve resultaten. Negatieve testcase geeft ongeldige invoer en krijgt de exacte foutmelding.

wat is de implementatiefase in de sdlc

Raadpleeg voor meer informatie hierover:

Enkele van de algemene kenmerken die alle testgevallen hebben, zijn:

  • Scenario-ID - overgenomen uit testscenario-document
  • Testcase-ID - voor unieke identificatie en tracking. Bijv .: TC_login_001
  • Testbeschrijving - Korte uitleg van de geteste testconditie
  • Uit te voeren stappen - Gedetailleerde stapsgewijze instructies voor het testen
  • Testgegevens - Gegevens die aan de teststappen worden geleverd
  • Verwacht resultaat - Resultaat zoals verwacht
  • Werkelijk resultaat - Reactie van de AUT wanneer de test wordt uitgevoerd
  • Status - geslaagd / mislukt / niet uitgevoerd / onvolledig / geblokkeerd - beschrijft het resultaat van de test
  • Opmerkingen - naar aanvullende details
  • Uitgevoerd door - Naam tester
  • Uitvoerdatum - Datum waarop de test wordt uitgevoerd
  • Defect ID - Defect geregistreerd tegen de testcase, in het geval van een testfout
  • Configuratiedetails - OS, browser, platform, apparaatinformatie (optioneel)

Aanbevolen om te lezen​

# 3. Testproces - Welke tests moeten worden uitgevoerd?

Er is een groot aantal soorten tests, maar ze kunnen niet allemaal op die AUT worden uitgevoerd. Tijd, budget, aard van het bedrijf, aard van de applicatie en het belang van de klant zijn de belangrijkste spelers bij de keuze van de tests die op de applicatie moeten worden uitgevoerd.

Bijvoorbeeld: Als het een online handelsportaal is, zijn stresstests en belastingtests verplicht. Enkele van de testtypen die u niet mag missen, zijn:

# 4. Testen in de gedeeltelijke ontwikkelingsfase

Over het algemeen zijn er bij middelgrote en startende bedrijven beperkte tijd en middelen. Testers hier kunnen hun testproces starten voordat module-integratie plaatsvindt, wat betekent dat we unit- en intermediaire integratietests kunnen uitvoeren.

Het is belangrijk op te merken dat de resultaten van deze fasen niet als nauwkeurig kunnen worden beschouwd, dus het kan zijn dat u een algehele black box-test moet plannen zodra alles klaar is voor gebruik. Het over het hoofd zien van dat deel zou kostbaar en testen kunnen blijken, ineffectief.

# 5. Bugrapport document

Praktisch, dit is het meest kritische QA-document dat u ooit zult maken.

Dit zijn de velden die een goed bugrapport moet hebben:

  • Defect ID - Meestal een serienummer
  • Defectbeschrijving - Een regel uitleg van het probleem
  • Locatie - Module / gebied van de AUT waar het probleem is gevonden
  • Build-nummer - Versie en code build-nr.
  • Stappen om te reproduceren - Lijst met stappen die u naar het probleem leiden
  • Ernst - Stel een niveau in om de ernst van het probleem te beschrijven - Laag, gemiddeld, hoog, blokkering, enz.
  • Prioriteit - Ingesteld door ontwikkelaars om de volgorde te bepalen waarin het defect zal worden verholpen (P1, P2, P3, etc. P1 - hoogste)
  • Toegewezen aan - Eigenaar van het defect op dat moment
  • Gemeld door - Naam tester
  • Status - Verschillende status om de levenscyclusfase van de bug weer te geven
    • Nieuw - Er is een fout gevonden en deze is zojuist gerapporteerd
    • Open - gevalideerd door de QA-lead
    • Toegewezen: verzonden naar de ontwikkelaar voor toewijzing aan de respectieve ontwikkelaar
    • In uitvoering / Werk in uitvoering - Dev begon eraan te werken
    • Opgelost / opgelost - Ontwikkelaar is er klaar mee
    • Geverifieerd / gesloten - QA-team heeft opnieuw getest en heeft vastgesteld dat de bug is verholpen
    • Opnieuw testen - QA-team is het niet eens met de oplossing van Dev en zet de bug verder voor herwerk
    • Dubbel - Vergelijkbare bug bestaat al
    • Uitgesteld - Geldige bug, maar zal in latere releases worden opgelost
    • Ongeldig - Geen bug of is niet reproduceerbaar of er is niet genoeg informatie

Verder lezen​

# 6. Afmeldingsproces

Afmelden en het verzenden van de definitieve documentatie is de taak van de QA-lead / manager. Het team moet echter de bovenstaande documenten (testscenario, testgeval en defectlogdocument) indienen voor definitieve beoordelingen en audit.

Zorg ervoor dat u ze allemaal proefleest en de definitieve versies opstuurt.

Lees ook​

Gevolgtrekking

Dit is het proces dat ik uit de eerste hand heb gezien en ervaren toen ik tester was en ik hoop dat dit je een aantal nuttige tips heeft gegeven.

Eindelijk, een carrière in het testen was een absoluut genot voor mij en ik hoop dat het ook voor jou is.

Het allerbeste voor je carrière!

Aanbevolen literatuur

^