Menu

Sådan reproduceres en ikke-reproducerbar defekt og gør din testindsats det værd

how reproduce non reproducible defect

Prøv Vores Instrument Til At Fjerne Problemer

I verden af softwaretest , en defekt, der en gang er fundet, skal være konsekvent reproducerbar, så testeren kan rapportere med overbevisning, en udvikler kan rette med klarhed, og QA-teamet kan lukke med tillid.

hvordan kan jeg se en XML-fil

Imidlertid kommer denne proces undertiden med sit eget sæt udfordringer. Denne artikel forsøger at belyse de mørke områder med reproduktion af defekter.

Først og fremmest hvad er “ Gengivelse af en defekt '?

Hvis en bestemt sekvens af trin har landet testeren på et punkt, hvor der observeres en afvigelse i forventet adfærd, er 'trin til reproduktion' defektfeltet, der indeholder en registrering af denne nøjagtige sekvens af trin. Hvis vi støder på det samme problem, hver gang vi følger disse trin, kaldes dette den reproducerbare defekt.

reproducere en defekt

Ud over trin til reproduktion af flere beviser, såsom anvendte data, skærmbilleder eller skærmoptagede videoer kan også leveres. Hvis disse oplysninger findes inkonsekvente eller forkerte, kan fejlene blive diskonteret og markeret som ugyldige uden yderligere opløsning.

Læs mere => Hvordan får du alle dine fejl løst uden nogen 'Ugyldig fejl' -mærke?

Derfor er 'trin til reproduktion' kritisk, og følgende er nogle af de punkter, du skal huske på, når du skriver denne del af fejlrapporten:

Hvad du lærer:

Sådan skriver man defekt 'Skridt til at reproducere':

  • Vær præcis
  • Medtag nøjagtige data, der er brugt under test for nem reference
  • Trinene skal være i den nøjagtige rækkefølge
  • Nævn forudsætninger, når det er relevant
  • Skriv ikke sammensatte trin.For eksempel: Hvis scenariet kræver, at en bruger gemmer et dokument fra Microsoft Word, skal det skrives som, 'Åbn menuen Filer, og klik på indstillingen Gem'.
  • Kontroller altid dine trin for at reproducere på et nyt system, og ryd alle cookies og cachehukommelse.
  • Sørg for, at sætningerne er korte og utvetydige

Et forkert skrevet 'trin til reproduktion' kunne ikke bare bringe fejlens gyldighed i fare, men involverer også en masse spildt tid med hensyn til at finde afklaringer og svar vedrørende ting, der ikke er tydeligt nævnt.

Læs også => Hvordan man skriver en god fejlrapport

hvordan man sammenligner to filer i unix

Hvorfor er det så vigtigt at gengive en defekt?

Lad os nu finde ud af 'Hvorfor det er så vigtigt at gengive en defekt?'

gengivelse af en defekt

Taler teknisk, hvis du kan ikke gengive en fejl, du kan aldrig rette den .

Følgende er nogle af de faktorer, der bestemmer, om en mangel bliver løst:

  • Detaljeret og komplet info i fejlrapporten
  • Hvis udvikleren er i stand til at forstå den faktiske forekomst af en defekt under visse betingelser?
  • Hvis miljøet, værktøjerne og de nøjagtige applikationsversioner er tilgængelige med udviklerne, som testere rapporterer om manglen?

Hvad er 'ikke-reproducerbare' bugs / defekter?

Hver tester skal have oplevet disse situationer:

  • Hvis du observerer et problem hele dagen og i slutningen af ​​dagen, hvor du rapporterede den mangel, finder du, at det ikke er mere reproducerbart.
  • Observere et problem intermitterende, dvs. for eksempel, antag at en ny bruger ikke er i stand til at tilføje produkter til sin indkøbskurv. Dette sker 6 ud af 10 gange.
  • Problemet observeres kun, når vi genstarter applikationen.

I alle disse tilfælde er det svært at bestemme den nøjagtige tilstand og rapportere det rigtigt. Sådanne problemer / mangler tager meget tid i efterforskningen af. Disse typer problemer kan ikke ignoreres, da slutbrugeren / kunden også kan overholde dem.

insekt

hvad er venfunktion i c ++

Hvordan reproduceres en defekt?

Et par ting, der kan hjælpe er:

  • Ryd al cache og cookies mens du udfører scenariet.
  • Se og observer hvert trin.
  • Nogle gange kan det være nyttigt at reproducere en fejl, hvis man ser efter lignende fejl eller mønstre. Det vil være lettere at identificere scenariet, hvis mønsteret forstås.
  • At notere hvert trin og andre faktorer (som testdata, miljø, systemindstillinger, skærmbilleder, serverlogfiler osv.) Vil være en god praksis for let at replikere scenariet.
  • Bekræft et par gange til for at bestemme forekomsten af ​​defekt. Stol ikke på og rapporter videre på baggrund af en enkelt gangs forekomst af problemet.
  • Test med tålmodighed er nøglefaktoren, da dette kan og vil tage meget tid

Derudover:

  • Selv når du er udfører sonderende test , skal du sørge for at være opmærksom på alle konfigurationer såvel som systemopsætninger.
  • Det er godt at bruge din kreativitet til at udforske applikationen på forskellige måder og prøve nogle usædvanlige scenarier. Selv i dette tilfælde anbefales det at følge logiske sekvenser i stedet for at udføre tilfældige trin.
  • Når et problem først er observeret, er det altid en god praksis at kontrollere det samme problem i forskellige browsere / operativsystemkombinationer, forskellige enheder (understøttet). Dette hjælper med at bestemme, om problemet er et system eller en browserspecifik / enhedsspecifik.
  • Hold dig opdateret med nye tendenser og fora om forskellige typer problemer og deres begivenheder. Disse hjælper med at differentiere systemspecifikke, browserspecifikke, produktspecifikke, eksterne problemer osv.
  • I stedet for at fortsætte med at forsøge at gengive problemet, når det først opstod, kan det nogle gange hjælpe at finde løsningen at læne sig tilbage og analysere de udførte trin.
  • Diskuterer med andre teammedlemmer eller manager kan nogle gange være nyttige. Der er også et ordsprog, Erfaring tæller .
  • Deling af din skærm kan også betragtes som en mulighed bortset fra skærmbilleder og videoer for at forklare problemet for udviklerne.
  • Gengiv problemerne mere end en gang for at være sikker på, at der opstår et problem. I sådanne tilfælde vil du være sikker på din test og være i stand til at besvare forespørgsler og bekymringer hos udviklere.

Konklusion:

Med den overordnede diskussion kan det klart konkluderes, at det er meget vigtigt at 'reproducere en fejl' for at få denne fejl valideret og derefter rettet. Hvis fejlen ikke er reproducerbar, er testindsatsen, der bruges til at finde, analysere og rapportere den pågældende fejl / fejl, totalt spild.

For at forstå og reproducere en fejl er det vigtigt at have detaljerede og korrekt forklarede 'trin til reproduktion', tilstand og miljø, hvor fejlen opstod. Det er muligt at rette en ikke reproducerbar defekt, men det kan være meget tid til at forbruge såvel som en meget vanskelig opgave. En anden vigtig faktor er korrekt kommunikation uden hvilken en gyldig fejl kan ugyldiggøres.

Så for at gøre din testindsats for at finde mangler det værd, kan ovennævnte være nyttigt.

Anbefalet læsning

^