this scenario explains how important it is document frequently encountered errors
Tror du at programvarefeil bare oppstår en gang, og at når de løses, dukker de aldri opp igjen? Jeg føler at omtrent 30% av feilene kommer igjen.
I denne artikkelen vil jeg dekke hvor viktig det er å dokumentere noen av de ofte oppståtte feilene.
Nedenfor finner du noen fellesarealer der man ser problemer og en mal for å dokumentere dem.
Håper du vil finne det nyttig!
bilde kilde
Scenario nr. 1
Koden er distribuert og klar for QA. John, testeren er klar med testsakene sine. Delvis gjennom testing kommer han over et problem. Han føler at det ble lagt merke til flere ganger tidligere, men John visste ikke hvordan han skulle løse det.
Både John og Sheryl lette etter Smith som hadde sett den samme feilen tidligere og hadde løst den før. Dessverre hadde Smith permisjon den dagen.
Hva skal John gjøre nå? Bør John prøve å nå ut til Smith for å finne en løsning selv når Smith ikke er tilgjengelig?
Derfor, hvis et miljøproblem blir sett gjentatte ganger på tvers av flere utgivelser, det er lurt å dokumentere detaljene og plasser den på et delt sted. Dette vil eliminere avhengigheten av en enkelt person og hjelper alle teammedlemmer å finne en løsning selv når dette skjer.
Scenario nr. 2
John tester en ny utgivelse og kommer over en kjent feil igjen. Denne gangen vet han at en mangel ble opprettet for den i en av de tidligere utgivelsene. Men spørsmålet er: 'hvordan finner jeg feilnummeret og andre tilknyttede detaljer?'
Også i dette tilfellet, hva tror du vil hjelpe John?
- Søk etter feilen i Feilsporingsverktøy med beskrivelsen?
- Søk hele fortiden feilmeldinger ?
- Nærme deg teamledelsen for assistanse?
Dette er muligheter.
Men etter min mening, hvis slike problemer er godt dokumentert i et eget område og deles med teamet, gir det verdi og sparer tid.
Hva du vil lære:
- Noen av områdene med hyppige feil:
- Last ned maler for å spore ofte oppståtte feil
- Fordelene med å dokumentere ofte oppståtte feil
- Konklusjon
- Anbefalt lesing
Noen av områdene med hyppige feil:
1) Parameterfil - Basert på min erfaring med Informatica-verktøyet har jeg i mange tilfeller lagt merke til param-filen som peker på en feil DB-forbindelse. Det har resultert i de samme problemene flere ganger. Hovedårsaken var at forbindelsen ble delt mellom dev og QA. Så param-filen måtte alltid oppdateres etter behov for å unngå feilen.
2) URL som peker mot feil DB
3) Tilgangsproblemer - Brukere får problemer når de ikke har tilstrekkelig eller feil tilgangstillatelse til DB eller i dette tilfellet, vil et dokument som beskriver trinnene som skal tas eller personer / personer som skal kontaktes være veldig nyttig.
4) Testdataproblem - Bruk av feil format eller dataverdier vil oftere enn ikke føre til problemer.
5) DB-problemer - Tidsavbrudd for DB-tilkobling er et så vanlig problem. Noe av nedetiden er midlertidig, planlagt, og noen ganger trenger vi kanskje DBAs assistanse. Brukerne får beskjed på forhånd om planlagt vedlikehold, men for midlertidige feil og oppløsning trenger testerne absolutt
De fleste gjentatte feil er generelt miljøspørsmål .
Men, kode problemer kan ikke ignoreres. Diskusjonen ovenfor er generisk og inkluderer ikke kodeproblemer fordi kodeproblemer er mer spesifikke for applikasjonen din, rammeverket, programmeringsspråket osv.
type testing i programvareteknikk
Et lite område med mangler kan også være dataregistrering eller feil ved menneskelig bruk s .
nedlastingMaler for å spore ofte oppståtte feil
Word-format
=> Last ned mal for sporingssporing (verden)
Excel-format
=> Last ned feilsporingsmal (Excel)
Fordelene med å dokumentere ofte oppståtte feil
1) Eliminerer avhengighet - I Scenario 1 var John avhengig av Smith for oppløsning. Hadde det vært et dokument for Johns referanse som ikke ville være tilfelle.
2) Raskere snuoperasjon - Ta scenario 2. En tester trenger ikke å gå gjennom hele listen over allerede loggede feil hvis det var et dedikert dokument for høyfrekvente problemer.
3) Hjelper nye teammedlemmer å være selvforsynende
4) Hjelper med å løse menneskelige feil
Konklusjon
Jeg vil si at det definitivt er gunstig å dokumentere de hyppigere problemene, da det vil være en fantastisk referanse og en verdiøkning.
Det kan bli kjedelig å dokumentere mens testutførelse pågår, men som en god praksis kan det tas grove notater under utførelsen, som senere kan oppsummeres og oppdateres i delte dokumenter.
Anbefalt lesing
- 10 beste dokumenthåndteringssystemer for bedre arbeidsflyt
- MongoDB oppdater og slett dokument med eksempler
- MongoDB spørringsdokument ved hjelp av Find () -metoden (eksempler)
- SharePoint Document Management System Tutorial
- 7 typer programvarefeil som alle testere burde vite
- Hvordan teste smartere: Utforsk mer, dokumenter mindre
- Test Scenario Vs Test Case: Hva er forskjellen mellom disse?
- Hvordan skrive teststrategidokument (med eksempel på teststrategimal)