this scenario explains how important it is document frequently encountered errors
Tror du, at softwarefejl kun opstår en gang, og at når de løses, dukker de aldrig op igen? Jeg føler, at omkring 30% af fejlene gentager sig.
I denne artikel vil jeg dække, hvor vigtigt det er at dokumentere nogle af de hyppigt stødte fejl.
Nedenfor finder du nogle fælles områder, hvor problemer ses og en skabelon til dokumentation af dem.
Håber du finder det nyttigt!
billede kilde
Scenarie nr. 1
Koden er implementeret og klar til QA. John, testeren er klar med sine testsager. Delvis gennem test kommer han over et problem. Han føler, at det blev bemærket flere gange tidligere, men John vidste ikke, hvordan man skulle løse det.
Både John og Sheryl ledte efter Smith, der havde set den samme fejl tidligere og havde løst den før. Desværre var Smith på orlov den dag.
Hvad skal John gøre nu? Skal John prøve at nå ud til Smith for at finde en løsning, selv når Smith ikke er tilgængelig?
Derfor, hvis et miljøproblem ses gentagne gange på tværs af flere udgivelser, det er en god ide at dokumentere detaljerne og placer det på en delt placering. Dette eliminerer afhængigheden af en enkelt person og hjælper alle teammedlemmer med at finde en løsning, når dette sker.
Scenarie nr. 2
John tester en ny udgivelse og støder på en kendt fejl igen. Denne gang ved han, at der blev skabt en mangel på den i en af de tidligere udgivelser. Men spørgsmålet er: 'hvordan finder jeg defektnummeret og andre tilknyttede detaljer?'
Også i dette tilfælde, hvad tror du ville hjælpe John?
- Søg efter manglen i Fejlsporingsværktøj med beskrivelsen?
- Søg hele fortiden fejlrapporter ?
- Nærme sig hans teamleder for at få hjælp?
Dette er muligheder.
Men efter min mening, hvis sådanne problemer er veldokumenterede i et separat område og deles med holdet, tilføjer det værdi og sparer tid.
Hvad du vil lære:
- Nogle af områderne med hyppige fejl:
- Download skabeloner for at spore ofte opståede fejl
- Fordele ved at dokumentere ofte opståede fejl
- Konklusion
- Anbefalet læsning
Nogle af områderne med hyppige fejl:
1) Parameterfil - Baseret på min erfaring med Informatica-værktøjet har jeg i mange tilfælde bemærket, at param-filen peger på en forkert DB-forbindelse. Det har resulteret i de samme problemer flere gange. Hovedårsagen var, at forbindelsen blev delt mellem dev og QA. Så param-filen måtte altid opdateres efter behov for at undgå fejlen.
2) URL, der peger på forkert DB
3) Adgangsproblemer - Brugere støder på problemer, når de ikke har tilstrækkelig eller forkert adgangstilladelse til DB'en. I dette tilfælde vil et dokument, der beskriver de trin, der skal tages, eller personer / personer, der skal kontaktes, være meget nyttigt.
4) Problemer med testdata - Brug af forkert format eller dataværdier vil oftere end ikke resultere i problemer.
5) DB-problemer - DB-forbindelse timeout er et sådant almindeligt problem. Noget af nedetid er midlertidigt, planlagt, og nogle gange har vi muligvis brug for DBA's hjælp. Brugere underrettes på forhånd om planlagt vedligeholdelse, men for midlertidige fejl og løsning har testere bestemt brug for det
De fleste gentagne fejl er generelt miljøspørgsmål .
Imidlertid, kode problemer kan ikke ignoreres. Ovenstående diskussion er generisk og inkluderer ikke kodeproblemer, fordi kodeproblemer er mere specifikke for din applikation, ramme, programmeringssprog osv.
bedste program til overvågning af cpu temp
Et lille område med mangler kunne også være dataindtastning eller fejl ved menneskelig brug s .
HentSkabeloner til at spore ofte opståede fejl
Word-format
=> Download fejlsporingsskabelon (verden)
Excel-format
=> Download fejlsporingsskabelon (Excel)
Fordele ved at dokumentere ofte opståede fejl
1) Eliminerer afhængighed - I Scenarie 1 var John afhængig af Smith for opløsning. Havde der været et dokument til Johns reference, ville det ikke være tilfældet.
2) Hurtigere ekspedition - Tag scenario 2. En tester behøver ikke at gennemgå hele listen over allerede loggede fejl, hvis der var et dedikeret dokument til højfrekvente problemer.
3) Hjælper nye teammedlemmer til at være selvforsynende
4) Hjælper med at løse menneskelige fejl
Konklusion
Jeg vil sige, det er bestemt fordelagtigt at dokumentere de hyppigere problemer, da det ville være en vidunderlig reference og en værditilvækst.
Det kan blive kedeligt at dokumentere, mens testudførelse er i gang, men som en bedste praksis kan der tages grove noter under udførelsen, som senere kan opsummeres og opdateres i delte dokumenter.
Anbefalet læsning
- 10 bedste dokumentstyringssystemer til bedre arbejdsgang
- MongoDB opdater og slet dokument med eksempler
- MongoDB-forespørgselsdokument ved hjælp af Find () -metoden (eksempler)
- SharePoint-dokumentstyringssystemvejledning
- 7 typer softwarefejl, som hver tester burde vide
- Sådan tester du smartere: Udforsk mere, dokumenter mindre
- Testscenarie mod testtilfælde: Hvad er forskellen mellem disse?
- Sådan skriver du teststrategidokument (med prøve teststrategiskabelon)