Menu

De kunst van het rapporteren van fouten: hoe u uw bugs op de markt kunt brengen en verhelpen?

  • Hoofd
  • Bug Defect Tracking
  • De kunst van het rapporteren van fouten: hoe u uw bugs op de markt kunt brengen en verhelpen?

art bug reporting

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Waarom is Marketing a Bug nodig?

De eerste dingen die in me opkomen als ik begin met het schrijven van dit artikel zijn de woorden van Cem Kaner ​ 'De beste tester is niet degene die de meeste bugs vindt of die de meeste programmeurs in verlegenheid brengt. De beste tester is degene die de meeste bugs laat verhelpen. '

Nu - wat is het verschil tussen het vinden van de meeste bugs en de meeste bugs verholpen krijgen ​

Is het niet duidelijk dat een bug die is ingelogd in een bug management systeem moet worden opgelost door de ontwikkelaar? Het antwoord is nee. Factoren zoals tijd om het product op de markt te brengen, tijd om het project op tijd af te ronden en ontwikkelaars die eraan werken onpraktische strakke schema's enz. dwingen bedrijven om het product vrij te geven met weinig bugs die de gebruikers niet grotendeels zullen beïnvloeden.

Bugrapportage art

(beeld bron ​

Wie geeft het vertrouwen aan het management door te beweren dat de bugs in het product geen invloed zullen hebben op het vertrouwen, de betrouwbaarheid en de belangen van belanghebbenden van de klant? - De testingenieur of het testteam - het is de taak van elke testingenieur om bugs te verhelpen die een negatieve invloed kunnen hebben op de productkwaliteit.

De prioriteit van de bug hangt naar mijn mening grotendeels af van hoe een probleem door de tester wordt gepresenteerd aan de ontwikkel- en managementteams.

Zie het als adverteren of marketing voor het probleem - dit omvat 2 stappen:

  1. Schrijf of rapporteer bugs correct
  2. Weet alles over de bug, zodat verdere details beter kunnen worden uitgelegd

Wat je leert:

De kunst van het rapporteren van bugs

Ja, bugrapportage is een kunst ​De manier waarop een bug wordt geschreven, toont de technische vaardigheid, domeinexpertise en communicatiemogelijkheden van een testingenieur.

Meestal moet een bug de volgende informatie bevatten:

  • Bug Samenvatting
  • stappen om te reproduceren
  • Bijlagen (momentopname, logboekbestanden enz.)
  • Reproduceerbaarheid van fouten
  • Bug-ernst
  • Softwareversie, omgevingsinformatie
  • Overige informatie op basis van organisatorische vereisten.

Een belangrijke opmerking: Graaf altijd dieper om de hoofdoorzaak van het probleem te vinden en meld het. Een eenvoudige inlogfout met de juiste combinatie van gebruikersnaam en wachtwoord kan bijvoorbeeld verband houden met verschillende redenen, zoals:

  1. Inloggegevens zijn helemaal niet gevalideerd
  2. Problemen met netwerkonderbrekingen bij inloggen op afstand
  3. Het systeem kan alle CAPS beschouwen als niet-CAPS.

Dus als tester zou je in staat moeten zijn om de verschillen te ontcijferen terwijl je de bug samenvattingen volgt:

  • 'Kan niet inloggen met de juiste gebruikersnaam en wachtwoord'
  • 'Kan niet inloggen met de juiste gebruikersnaam en wachtwoord, als de gebruikersnaam of het wachtwoord een combinatie van CAPS- en niet-CAPS-alfabetten bevat.'

Dit laatste is een zeer duidelijke omschrijving van het probleem en ondubbelzinnig. Hiermee vergroot u niet alleen uw geloofwaardigheid als tester, maar rapporteert u ook het daadwerkelijke probleem in plaats van een symptoom.

Laten we nu eens kijken naar elk veld dat bij een bugrapport betrokken is, en de belangrijke aspecten van elk ervan bespreken:

# 1. Bug Samenvatting

Een bugsamenvatting zou een snelle momentopname moeten geven van wat precies het probleem is. Het moet nauwkeurig en goed geregisseerd zijn.

Voorbeeld ​

Afgezien van de theorie, zal ik proberen uit te leggen met voorbeelden.

Laten we een eenvoudige inlogmodule aannemen. Laten we aannemen dat het probleem is: een nieuwe gebruiker die een website bezoekt, kan niet inloggen met zijn standaardwachtwoord. Toen ik hetzelfde scenario voorlegde aan veel van de studenten die ik in de beginfase van de training heb opgeleid, waren er verschillende antwoorden als een foutoverzicht. Hieronder vindt u enkele voorbeelden van hoe de samenvatting eruit zag:

handmatige testinterviewvragen voor ervaren

​ Nieuwe gebruiker kan niet inloggen '

'Gebruikersaanmelding werkt niet zoals verwacht'

'Gebruiker kan niet inloggen met het juiste wachtwoord'

bugsamenvatting fout en goed

Kunt u uit de bovenstaande voorbeelden één stelling kiezen die het probleem werkelijk beschrijft? Ik denk het niet. De samenvatting moet altijd volledige informatie geven over het mislukte scenario.

Beschouw de volgende verklaring:

'Nieuwe gebruiker kan niet inloggen met het standaardwachtwoord dat is opgegeven via e-mail of sms'

Zoals u kunt zien, kan een ontwikkelaar uit de bovenstaande verklaring duidelijk begrijpen wat het probleem is en waar het probleem is.

Probeer dus de juiste woorden te vinden om de samenvatting te beschrijven die de informatie direct zou geven. Generieke uitspraken als 'werkt niet goed', 'werkt niet zoals verwacht' enz. Moeten worden vermeden.

# 2. Stappen om te reproduceren en bijlagen

Niet-reproduceerbare bugs gaan altijd op de achtergrond, ook al kunnen ze significant zijn. Let er daarom goed op dat u de stappen correct en beschrijvend schrijft.

De stappen moeten nauwkeurig zijn en precies hetzelfde als degene die tot het probleem hebben geleid. Voor functionaliteitgerelateerde bugs is het volgende voorbeeld het beste voorbeeld.

Voorbeeld ​

Beschouw hetzelfde probleem als vermeld in de vorige sectie.

  1. Maak een nieuwe gebruiker aan met de optie Aanmelden op de startpagina. (Voorbeeld gebruikersnaam: HelloUser)
  2. Er wordt een e-mail en een sms ontvangen met een standaardwachtwoord. De e-mail-ID en het mobiele nummer voor sms worden verstrekt tijdens het aanmaken van de gebruiker in stap 1. (Voorbeeld e-mail: HelloUser@hello.com , Voorbeeld mobiel nummer: 444-222-1123)
  3. Selecteer de aanmeldingsoptie op de startpagina.
  4. Geef in het tekstveld gebruikersnaam de voorbeeldgebruikersnaam op die u in stap 1 hebt opgegeven.
  5. Geef in het wachtwoordveld het standaardwachtwoord op dat u via e-mail of sms ontvangt.
  6. Klik op de knop Aanmelden
  7. Verwacht resultaat: De gebruiker moet kunnen inloggen met de opgegeven gebruikersnaam en wachtwoord en naar de gebruikersaccountpagina gaan.
  8. Werkelijke resultaat: Het bericht 'Ongeldige gebruikersnaam / wachtwoord' wordt weergegeven.

defectrapport stappen

Als een van de informatie niet in het bovenstaande voorbeeld wordt verstrekt, dan wel resulteren in hiaten in de communicatie en de ontwikkelaar zal het probleem niet kunnen reproduceren. De stappen moeten specifiek en gedetailleerd zijn met de voorbeeldgegevens die u tijdens het testen gebruikt.

Geef indien mogelijk of waar van toepassing een momentopname van wat u precies op het scherm ziet. Op deze manier geeft het niet alleen een goed beeld van het probleem aan de ontwikkelaars, maar ook een bewijs van uw testresultaat.

De niet-functioneel testgevallen zoals stress-, stabiliteits- of prestatietestgevallen, naast de bovenstaande details, kan informatie over het scenario dat de stress voor het systeem veroorzaakt, worden gerapporteerd zoals het is. Bovendien zijn er maar weinig systemen die logboeken rapporteren voor elke bewerking die wordt uitgevoerd. Logboeken zijn doorgaans afdrukinstructies die door de ontwikkelaars in hun code worden verstrekt. Telkens wanneer een module wordt uitgevoerd, worden de bijbehorende logboeken afgedrukt of weergegeven. Als er logboeken beschikbaar zijn, zou dat ontwikkelaars in grote mate helpen bij het reproduceren van het probleem.

# 3. Bug reproduceerbaarheid

Een probleem dat groot of klein is, krijgt voorrang op basis van de reproduceerbaarheid. Het is altijd, soms, zelden of zelfs maar één keer te zien. Een probleem dat als 'altijd' wordt weergegeven, krijgt een hogere prioriteit dan de rest.

kan een defect niet reproduceren

Het is dus de taak van een testingenieur om het scenario exact te volgen voor het probleem dat altijd wordt gereproduceerd. Soms zijn er enkele problemen die een testingenieur niet in de hand heeft, waardoor een probleem slechts een paar keer wordt gereproduceerd, maar in meerdere tests. Vermeld in dergelijke gevallen altijd het aantal proeven, een bepaald scenario wordt uitgevoerd samen met het aantal keren dat het probleem tijdens die proeven wordt gezien.

Dit zou op zijn beurt de geloofwaardigheid van het door u genoemde bugrapport vergroten. Nogmaals, dit zou uw reputatie als tester verbeteren. Ik zal je later vertellen waarom je een goede reputatie hebt.

# 4. Bug-ernst

Severity is ongetwijfeld een van de grootste beïnvloeders voor het prioriteren van de bug.

Hieronder volgen de verschillende categorieën van ernst. Houd er rekening mee dat dit slechts algemene voorbeelden zijn en dat het van bedrijf tot bedrijf verschilt.

  1. Severity 1 - Show Stopper - voor bugs die catastrofaal zijn, kan de gebruiker de software niet blijven gebruiken zonder te worden verholpen en is er geen mogelijke oplossing
  2. Severity 2 - High - voor bugs vergelijkbaar met Severity 1, maar er is een oplossing
  3. Ernst 3 - Gemiddeld
  4. Ernst 4 - Laag
  5. Ernst 5 - Triviaal.

Laten we bijvoorbeeld twee vergelijkbare problemen vergelijken.

In onze settopboxen geven maar weinig serviceproviders de frequentie-informatie van de service zoals momenteel is afgestemd. Laten we aannemen dat de frequentie wordt weergegeven als 100 MHz in plaats van 100,20 MHz. Dit heeft mogelijk geen invloed op het bekijken van de services door de gebruiker, maar kan wel van invloed zijn op de controlediagnostiek van de set-tops. Daarom kan dit worden gepresenteerd als een probleem met Severity 3.

Uitgaande van een soortgelijk probleem in het bankdomein: als uw rekeningsaldo wordt weergegeven als $ 100 in plaats van $ 100,20, stelt u zich de impact van het probleem voor. Dit moet een Severity -1 defect zijn. Zoals u in beide gevallen kunt zien, lijkt het probleem sterk op dat de gebruikersinterface de cijfers achter de komma niet weergeeft. Maar de impact verschilt per domein.

Efficiënte deelname aan vergaderingen met softwareversiecontrole

Gewoonlijk heeft elke organisatie zijn eigen proces om bugs te onderzoeken en prioriteiten te stellen. Over het algemeen zou er tijdens het project met specifieke tussenpozen een vergadering plaatsvinden om de bugs te bespreken en dezelfde prioriteit te geven.

Het proces tijdens dergelijke bijeenkomsten is als volgt:

  1. Vraag de lijst met bugs uit het bugbeheersysteem op basis van de ernst.
  2. Bekijk de samenvatting en bespreek de impact van de bug op de ervaring van de gebruiker bij het gebruik van een softwareproduct.
  3. Stel op basis van de risico- en impactbeoordeling de prioriteit in en wijs de bug toe aan een geschikte ontwikkelaar om deze te verhelpen.

Tijdens stap 2 is het absoluut noodzakelijk dat elke testingenieur pleit voor de impact van de bug op de gebruikerservaring als de bug niet de prioriteit krijgt die hij verdient. Het zijn immers wij testingenieurs die rekening houden met het standpunt van een gebruiker om testcases te schrijven en het product te testen.

Beschouw het bovenstaande voorbeeldprobleem van het niet weergeven van de cijfers achter de komma in een bankdomein. Voor een ontwikkelaar lijkt het misschien een minder ernstig probleem. Hij zou kunnen zeggen dat hij, in plaats van de variabele als een geheel getal te declareren, dat als een drijvende komma zou verklaren om het probleem op te lossen en dus minder ernstig.

Maar als tester is het jouw rol om de situatie van de klant uit te leggen. Uw punt zou moeten zijn hoe de gebruiker in dit scenario zou klagen. De tester zou moeten zeggen dat dit paniek zal veroorzaken bij de gebruikers omdat de klant zijn geld in centen verliest.

Gevolgen van het niet correct vermarkten van een bug

Als een bug niet op de juiste manier op de markt wordt gebracht, ontstaan ​​er problemen als:

  • Onjuiste prioriteit voor defecten
  • Vertraging bij het oplossen van de belangrijke problemen
  • Productvrijgave met ernstige defecten
  • Negatieve feedback van klanten
  • Merkwaarde devalueren

Gevolgen van het niet correct vermarkten van een bug

Afgezien van alle hierboven genoemde redenen, is het erg belangrijk om uw reputatie als testingenieur ​Het is meer zoals het ontwikkelen van een merkwaarde voor jezelf.

Als u in de beginfase van uw carrière uw aantal 'Kan niet reproduceren' of 'Meer informatie nodig' of 'Geen geldige bug' of wijzigingen in ernst zo laag mogelijk kunt houden, zullen uw bugs op een bepaald moment niet worden onderzocht. helemaal en ze zouden rechtstreeks worden toegewezen aan de juiste ontwikkelaar om te worden opgelost.

Om een ​​dergelijke merkwaarde te ontwikkelen en het vertrouwen van uw team en de ontwikkelings- / of managementteams te winnen, moet u een aantal technische vaardigheden ontwikkelen op het gebied van het testen van kennis, domein- en communicatieve vaardigheden.

Gevolgtrekking

Elk product of elke dienst, groot of klein, zal altijd mislukken zonder goede reclame. Als een merk eenmaal is gevestigd, kan elk klein product een superhit zijn bij het publiek.

Dat gezegd hebbende, te veel reclame voor een product kan ook reputatieschade veroorzaken.

Een bug moet dus altijd op een duidelijke, beknopte en precieze manier worden geschreven, zodat het een exacte locatie van de bug in de uitgebreide / uitgebreide softwarekaart geeft. Ik herhaal dat dit niet alleen de kwaliteit van de software verbetert, maar ook de kosten voor het testen en ontwikkelen van de software aanzienlijk verlaagt.

Het is nu niet te laat! Laten we doorgaan en bugs meteen verhelpen!

beste gratis video-omzetter voor Windows 7

Aanbevolen literatuur

^