Menu

3 strategieën voor het omgaan met een blocker-defect

3 strategies dealing with blocker defect

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Blocker-defecten voegen tonnen drama toe aan anders reguliere testdagen.

In dit artikel wil ik enkele stappen bespreken die een tester kan nemen om ermee om te gaan.

Ik ga ervan uit dat onze dierbare lezers de ernst en prioriteit van defecten al diep begrijpen. Een korte samenvatting nodig? Kijk hier eens naar.

Betekent dit altijd dat we volledig moeten stoppen met testen als we een blocker-probleem tegenkomen?

In sommige gevallen 'Ja', maar misschien niet altijd. Er kunnen gevallen zijn waarin enige testactiviteit mogelijk is.

Omgaan met blocker defect

beeld bron

Hieronder staan ​​enkele situaties die ik heb meegemaakt in mijn carrière als tester. Ik ben er sterk van overtuigd dat de onderstaande stappen (later geconsolideerd in een stroomschema) moeten worden gevolgd om dit proces eenvoudiger te maken.

Laten we meteen beginnen.

Stappen die u moet nemen als u een blocker-defect tegenkomt

Stap 1: Wanneer u een probleem tegenkomt, investeer dan tijd om de oorzaak te achterhalen.

Ik ben er sterk van overtuigd dat ons werk als tester niet ophoudt het melden van defecten ​Als de tijd het toelaat, moeten we onderzoeken wat het probleem had kunnen veroorzaken. We kunnen misschien niet altijd het exacte probleemgebied aangeven, maar proberen het probleem zo veel mogelijk op te lossen. Dezelfde details kunnen in het defect worden bijgewerkt als aanvullende opmerkingen.

Ik heb dit veel gedaan in mijn projecten en dit heeft geresulteerd in een snelle oplossing. De voordelen van oorzaakanalyse zijn:

  • Omdat het een toegevoegde waarde is, kan dit zeker een betere richting geven aan de ontwikkelaar voor het oplossen van bugs.
  • Ook kan de QA-tester herkennen of dit probleem zelf is gecreëerd (problemen met gegevensinvoer of menselijk gebruik) en, zo ja, kan het worden opgelost door de tester zelf. Wanneer dergelijke fouten aan ontwikkelaars worden gerapporteerd zonder dat wij dit aan de QA-kant controleren, is dat zo beschouwd als een non-issue en kan een negatieve reputatie voor de tester creëren.

Dus ik stel voor dat we altijd aan ons einde een dubbele controle uitvoeren voordat we een defect registreren.

Hier zijn enkele real-time voorbeelden van mijn projecten die de bovenstaande punten zullen versterken:

Ik werkte aan een project waarbij we voor onze tests een bestand op een bepaalde locatie moesten neerzetten. Hernoem het zodat het overeenkomt met de naam in de configuratie. Een geplande taak zou het gegevensbestand ophalen en de gegevens in het systeem laden. Daarna zouden we de gegevens in de database en de front-end valideren.

beste spionageprogramma's voor mobiele telefoons

Vroeger kwamen we problemen tegen waarbij de taak zou worden uitgevoerd, maar de gegevens niet konden worden geladen, en bij onderzoek kwam dit doordat de tester de naam niet had gewijzigd tijdens het neerzetten van het bestand op de locatie.

Dit was een blokkering voor ons, maar niet iets dat de aandacht van de ontwikkelaar vereiste. We moesten op details letten en zulke kleine foutjes vermijden.

Hieronder volgen enkele veelvoorkomende categorieën, hoofdoorzaken en oplossingen:

# 1) Hosts-bestand Kwestie - Stel dat uw hosts-bestand parameters bevat die onjuist zijn en het probleem veroorzaken. In dit geval kunt u het hostbestand zelf bijwerken of hulp zoeken bij iemand die toegang heeft om bij te werken en door te gaan met het uitvoeren van de test.

Een defect voor hetzelfde moet worden gemeld, zodat ontwikkelaars het zullen onderzoeken, maar met de tijdelijke oplossing kan het functionele testen nog steeds worden voortgezet.

Notitie: Vraag uw projectteams of het OK is dat het QA-team deze wijzigingen aanbrengt voordat u dit doet.

# 2) Configuratie - Vaak hebben we configuratieproblemen geconstateerd, zoals het niet wijzen naar de juiste omgeving of andere installatieproblemen, die blokkeerproblemen zijn. Ook in dergelijke gevallen kunnen testers wijzigingen aanbrengen en doorgaan met testen.

Notitie: Vraag nogmaals toestemming voordat u dit doet.

# 3) Probleem met code - Als u denkt dat het probleem te wijten is aan code, kunnen de testers niet veel doen. Registreer een blocker-defect en wacht tot de fix verder gaat met testen.

gradenboog end-to-end testraamwerk voor angularjs-apps

# 4) Implementatieprobleem - Slechte implementatie is een andere veelvoorkomende oorzaak van blocker-problemen en deze kunnen tijdens de gezondheidstest worden opgemerkt. Ook hier dient het testen direct gestopt te worden totdat er een nieuwe build is ontvangen.

# 5) Omgeving omlaag - Als de omgeving niet werkt, stel dat de database geen verbinding maakt met de server of dat de URL niet werkt in het geval van websites; testers kunnen in deze gevallen niet veel anders dan een defect melden en wachten tot het systeem operationeel is.

Als er een tijdelijke oplossing bestaat, gebruik deze dan om door te gaan met testen. De enige manier om te vinden, of die tijdelijke oplossing bestaat, is door de hoofdoorzaak te onderzoeken. Vaker wel dan niet, is er misschien een alternatief.

Stap 2: Het is heel gemakkelijk om in een oneindige lus te vallen bij het onderzoeken van de hoofdoorzaak. Zorg er dus voor dat het niet de hele dag en alle moeite kost.

Hier zijn enkele tips:

  • Vind een balans en herken het stoppunt als je daar aankomt.
  • De ervaring en expertise van een tester zijn essentieel voor een succesvolle RCA. Het is echter een goed idee om het team en de teamleider er indien nodig bij te betrekken.
  • Als u denkt dat RCA tijdrovend is, moet u het probleem eerst onmiddellijk melden en zo veel mogelijk informatie verstrekken. Een screenshot is altijd handig.
  • Volg indien nodig op. Stuur een e-mail naar de manager of ontwikkelaar om het kritieke probleem onder de aandacht te brengen.
  • Ga door met het oplossen van problemen nadat u de benodigde partijen hebt gewaarschuwd.

Reden waarom blokkeringsgebreken onmiddellijk moeten worden gemeld:

  • Het management moet op de hoogte worden gebracht van alle uitvaltijden als het probleem een ​​showstopper-defect is. Deze informatie moet worden doorgegeven aan de klant en kan ook vragen om updates van het projectplan (QA-tijdlijnen), wijzigingen in de te leveren producten, enz.
  • Elke vertraging in QA-resultaten moet worden ondersteund met bewijs. Het is dus altijd beter om zo snel mogelijk te communiceren in plaats van te wachten tot het einde van de dag.

Stap 3: Nu we naar de laatste stap gaan sinds we klaar zijn met het analyseren van het probleem en het communiceren, wat is de volgende stap?

  • Als het probleem de toegang tot een functioneel gebied blokkeert, controleer dan of dit gevolgen heeft voor andere gebieden
  • Als de front-end-app niet werkt, controleer dan of het testen van de backend / middleware / database kan worden voortgezet.
  • Als er geen testuitvoering kan plaatsvinden, probeer dan werk aan wat documentatie gerelateerd aan uw project.
  • U kunt ook proberen identificeer gebieden voor automatisering als u veel werk handmatig herhaalt. Automatisering hoeft niet altijd een tool te gebruiken. Stel dat het genereren van rapporten een eentonige taak voor u is, dat is een gebied dat kan worden geautomatiseerd door eenvoudige Excel-macro's en dergelijke.
  • Besteed tijd aan het kennen van open source-tools die in uw project kunnen worden geïmplementeerd
  • Last but not least , werk aan innovatie, de mantra die momenteel de wereld regeert!

Tenslotte , het stroomschema dat de hele discussie samenvat!

Stroomdiagram: stappen om een ​​blocker-defect aan te pakken

blocker defect

Auteur : Dit geweldige artikel is geschreven door STH-teamlid Priya R.

Welke stappen onderneemt u als u een blocker-defect tegenkomt?

Aanbevolen literatuur

^