Meny

3 Vanlige rapporteringsvaner og hvordan du kan bryte dem

3 worst defect reporting habits

Prøv Instrumentet Vårt For Å Eliminere Problemer

Mangler er alvorlige, og små feil kan være dyre.

Du vet hva du skal gjøre når du finner en feil. Du rapporterer det; enten i en Defect Tracker / Defekthåndteringsverktøy eller i et Excel-ark. De underliggende prinsippene er de samme for begge metodene.

Verktøy for feilhåndtering garanterer ikke bedre rapportering. Det er god praksis som redder dagen.

For å sette pris på det gode, må vi erkjenne hva som ikke er.

Hva du vil lære:

3 Vanlige rapporteringsvaner og hvordan du kan bryte dem

verste feil-rapporteringsvaner

Her går:

# 1) Latskap

Ikke tar deg tid til å gjøre det beste du kan.

Dette er prosess for mangelfølgning fulgte i de fleste lag:

(Merk- klikk på et hvilket som helst bilde for forstørret visning)

feilsporing

Som du kan se, gjennomgår testledningen manglene før du sender dem ut av QA-teamene.

Denne anmeldelsen inkluderer bekreftelse av:

  • Gyldighet - Er det en feil?
  • Fullstendighet - Tittel, trinn, data, skjermbilde etc.
  • Duplikater
  • Reproduserbar eller ikke ... osv.

Jeg vet førstehånds at det er umulig for en kvalitetssikring å være 100% grundig.

Så holdningen, “Jeg vil rapportere problemet slik jeg vil. QA-ledningen kan sjekke på nytt. Han kan avgjøre om feilen er gyldig / fullstendig eller ikke ”er slutten på ditt QA-team og din troverdighet.

Visste du at noen klienter har en SLA for antall akseptable ugyldige mangler? Når antallet overstiger, begynner de å straffe entreprenørene for alle ugyldige feil rapportert?

Middel: Gjør din aktsomhet og være ansvarlig for at du kan levere den. En feil kom tilbake for ikke nok informasjon, eller at det ikke er en feil? Det er ikke alltid det er utviklingsteamets feil. Det er ikke slik at de ikke vil eie problemene i applikasjonen. Det kan være en ekte QA-team-rot. Ikke la det skje.

# 2) Rushing

La oss gjøre dette med eneksempel.

Nedenfor er et skjermbilde av OpenEMR’er opprett pasientskjerm. Det er et sykehusstyringssystem med åpen kildekode.

Dette skjermbildet lar brukeren angi pasientens fødselsdato gjennom en kalenderfunksjon. Det den ikke gjør er å begrense oppføringen til å velge fra kalenderen. Det jeg mener er at du kan velge DOB som '31-Mar-1983' fra kalenderen. Senere endre den til “31. februar 1983”.

åpen-emr-kalender-funksjon

åpen-emr-feil-gjetting

Hvorfor 31. februar? Å implementere feil gjetting og prøv negative data i feltet; som er hele poenget med testing, er det ikke?

Når du er ferdig, klikker jeg på 'Opprett pasient'. Siden datoen er ugyldig, forventer jeg at systemet viser en feil og ikke oppretter pasienten. Men det skjer ikke. Det skaper pasienten som nedenfor.

Legg merke til feltene Alder og fødselsdato i skjermbildet nedenfor:

openemr-test-tester

Når du tester, kan du prøve dette et par ganger og bestemme at:

  • Det er en feil.
  • Den er reproduserbar.
  • Det er ikke en duplikat (Ta kontakt med teamet ditt for å bekrefte)
  • Du vet den nøyaktige beskrivelsen av problemet
  • Du vet også de nøyaktige trinnene som får det til å skje.

Nå som du har råvaren, er du god å gå.

Du begynner å rapportere det. Å tildele alvorlighetsgrad er et obligatorisk trinn, og teamet ditt bruker kanskje noe som ligner på følgende tabell for referanse:

Alvorlighetsgrad innvirkning
1 (kritisk) • Denne feilen er kritisk nok til å krasje systemet, forårsake filkorrupsjon eller forårsake potensielt datatap
• Det fører til unormal retur til operativsystemet (krasj eller en systemfeilmelding vises).
• Det får applikasjonen til å henge og krever omstart av systemet.
2 (høy) • Det forårsaker mangel på viktig programfunksjonalitet med løsning.
3 (middels) • Denne feilen vil forringe kvaliteten på systemet. Imidlertid er det en intelligent løsning for å oppnå ønsket funksjonalitet - for eksempel gjennom en annen skjerm.
• Denne feilen forhindrer at andre områder av produktet testes. Imidlertid kan andre områder testes uavhengig.
4 (lav) • Det er en utilstrekkelig eller uklar feilmelding som har minimal innvirkning på produktbruken.
5 (kosmetisk) • Det er en utilstrekkelig eller uklar feilmelding som ikke har noen innvirkning på produktbruken.

Siden denne feilen ikke krasjer systemet eller blokkerer en viktig funksjonalitet eller hindrer de andre områdene i applikasjonen fra å bli testet, kan vi gå med 'Lav'.

Ser om ikke sant?

FEIL. Fra pasientens data er alle vaksinasjoner og andre påminnelser forsinket. Dette kan være riktig eller ikke. Også for en pasient bestemmer alderen deres om de oppsøker barnelege eller allmennlege etc.

Det påvirker dosene av medisiner og mange andre behandlingsområder som vi kanskje ikke engang vet om.

open-emr-clinical-reminder

Så jeg kommer til å gå med “High”. Jeg er enig i at det er lite sannsynlig at sykehuspersonalet vil gå inn i DOB for en pasient feil. Men la det være en faktor som påvirker prioriteten til når problemet skal løses.

Jobben min som tester er å sørge for at jeg kommuniserer problemets alvor så godt jeg kan.

Middel: Ikke ha det travelt med å rapportere. Vær 100% sikker på at du forstår virkningen av problemene fra mange vinkler. Det er den beste verdien vi kan tilby testere. Vi sier ikke bare 'Noe fungerer ikke'. Vi sier også: 'Her er hva som vil skje hvis dette fortsetter å ikke fungere.' Massevis av forskjell, er det ikke?

# 3) Mangel på kreativitet

Testerne har en fantastisk mulighet til å komme med forslag til forbedring av programvaren.

I din Feilhåndteringsverktøy du kan også sende inn en feil av typen 'Enhancement Suggestion.' Det er her du kan bli kreativ.

Middel: Tenke utenfor boksen. Hvis du tror at en bestemt funksjon mangler en “Wow” -faktor, og du vet hvordan du tar den inn i den, kan du legge ideen frem. I verste fall kan det bli avvist, og det er OK. Den viktige delen er å prøve.

Bruk også denne superkraften med forsiktighet. Prøv å ikke komme med kommentarer som 'Jeg hater fargen på banneret, vær så snill å endre det.'

Her er en godeksempelav et forbedringsforslag som jeg kom over: Erstatte “E-post til forhandler” med “Chat med forhandleren” på et bilforhandlerside. Det er spådd å konvertere mer trafikk til salg.

Jeg skulle ønske jeg var så kreativ! Men kanskje vi alle kan jobbe mot det.

Her er en bonus. En sjekkliste for å frigjøre disse dårlige vanene:

1. Formidler tittelen problemet tydelig og kortfattet?
For eksempel:'Opprett pasienten fungerer ikke' er ikke en god tittel. 'Opprett pasient mislykkes selv når alle inndatafelt inneholder riktige verdier' er.

to. Hva er reproduserbarhetsgraden?
Med andre ord, skjer det alltid? Vet jeg den nøyaktige trinnrekkefølgen som vil gjenta problemet?

3. Er denne problemplattformen, nettleseren eller brukerspesifikk?

Fire. Er trinnene fullført og får deg til problemet ditt?

5 . Har jeg inkludert et skjermbilde?

6. Må jeg legge merke til skjermbildet mitt for å markere spesifikke områder?

7. Er navnet på bildefilen vedlagt beskrivende?
Ikke bruk noe som 'Untitled.jpg.' Gi det et beskrivende navn.

8. Inkluderte jeg testdataene?
For eksempel:For en mangel i en administratormodul som trenger autorisasjonslegitimasjon, inkluder dem. Utviklingsteamet har eller ikke har tilgang til QA-miljøet. Du vil ikke ha en forsinkelse og følge opp noe så grunnleggende som det.

9. Kan jeg gi noen andre detaljer for å forsterke min feil?
(Eksempel:en referanse til FRD eller en samtale med klienten osv.)

10. Forstår jeg hvor alvorlig problemet er fra forskjellige perspektiver?

elleve. Kjenner jeg årsaken til problemet? Hvis ja, har jeg bevis (kanskje loggfiler) og kan jeg inkludere det? Vær oppmerksom på at du kanskje ikke alltid vet dette eller trenger å vite dette. Men hvis du gjør det, gjør det ikke vondt å inkludere det.

12. Er feilrapporten fri for grammatikk, format, staving og tegnsetting?

j2ee intervju spørsmål for seniorutviklere

1. 3. Kjenner jeg til en måte å forbedre produktet på?

Tenker du at dette er tidkrevende? Når det først blir en vane, vil det ikke være lenger.

Rooting for better feilrapportering rutiner!

Om forfatteren: Denne artikkelen er skrevet av STH-teammedlem Swati.

Legg gjerne inn spørsmål / kommentarer nedenfor.

Anbefalt lesing

^