Meny

3 Vanligaste rapporteringsvanor och hur man bryter dem

3 worst defect reporting habits

Prova Vårt Instrument För Att Eliminera Problem

Fel är allvarliga affärer och små misstag kan vara dyra.

Du vet vad du ska göra när du hittar en defekt. Du rapporterar det; antingen i en Defektspårare / Verktyg för defekthantering eller i ett Excel-ark. De underliggande principerna är desamma för båda metoderna.

Verktyg för defekthantering garanterar inte bättre rapportering. Det är god praxis som räddar dagen.

För att uppskatta det goda måste vi inse vad som inte är.

Vad du kommer att lära dig:

3 Vanligaste rapporteringsvanor och hur man bryter dem

värsta-fel-rapportering-vanor

Här kommer:

# 1) Lata

Ta dig inte tid att göra det bästa du kan.

Det här är process för spårning av defekter följt i de flesta lag:

(Notera- klicka på valfri bild för förstorad vy)

felsökning

Som du kan se granskar testledningen bristerna innan de skickas ut från QA-lagen.

Denna recension inkluderar bekräftelse av:

  • Giltighet - Är det ett fel?
  • Fullständighet - Titel, steg, data, skärmdump etc.
  • Dubbletter
  • Reproducerbar eller inte ... etc.

Jag vet själv att det är omöjligt för en QA-ledning att vara 100% grundlig.

Så, attityden, ”Jag kommer att rapportera problemet som jag vill. QA-ledningen kan kontrollera igen. Han kan avgöra om defekten är giltig / fullständig eller inte ”är slutet på ditt QA-team och din trovärdighet.

Visste du att vissa kunder har en SLA för antalet godtagbara ogiltiga fel? När numret överstiger, börjar de straffa entreprenörerna för varje ogiltigt fel som rapporterats?

Avhjälpa: Gör din due diligence och vara ansvarig för din leverans. En defekt kom tillbaka för inte tillräckligt med information eller att det inte är ett fel? Det kanske inte alltid är utvecklingsteamets fel. Det är inte så att de inte vill äga problemen i applikationen. Det kan vara en äkta QA-team-mess-up. Låt inte det hända.

# 2) rusar

Låt oss göra detta med enexempel.

Nedan visas en skärmdump av OpenEMR skapa patientskärm. Det är ett öppen källkodshanteringssystem.

Den här skärmen låter användaren ange patientens födelsedatum via en kalenderfunktion. Vad den inte gör är att begränsa posten till att välja från kalendern. Vad jag menar är att du kan välja DOB som säg '31-Mar-1983' från kalendern. Senare ändra den till '31 feb 1983'.

öppna-emr-kalender-funktionen

open-emr-error-guessing

Varför den 31 februari? Att genomföra fel gissning och prova negativa data i fältet; vilket är hela poängen med att testa, eller hur?

När jag är klar klickar jag på 'Skapa patient'. Eftersom datumet är ogiltigt förväntar jag mig att systemet visar ett fel och inte skapar patienten. Men det händer inte. Det skapar patienten enligt nedan.

Observera fälten ålder och födelsedatum på skärmen nedan:

openemr-test-testare

När du testar kan du prova detta några gånger och bestämma att:

  • Det är ett fel.
  • Det är reproducerbart.
  • Det är inte en duplikat (kontakta ditt team för att bekräfta)
  • Du vet den exakta beskrivningen av problemet
  • Du vet också de exakta stegen som får det att hända.

Nu när du har råvaran är du redo att gå.

Du börjar rapportera det. Att tilldela defektens svårighetsgrad är ett obligatoriskt steg och ditt team kan använda något som liknar följande tabell för referens:

Allvarlighetsgrad Påverkan
1 (kritisk) • Detta fel är tillräckligt kritiskt för att krascha i systemet, orsaka filskada eller orsaka potentiell dataförlust
• Det orsakar onormal återgång till operativsystemet (krasch eller ett systemfelmeddelande visas).
• Det gör att applikationen hänger och kräver att systemet startas om.
2 (hög) • Det orsakar brist på vital programfunktionalitet med lösningen.
3 (Medium) • Detta fel kommer att försämra systemets kvalitet. Det finns dock en intelligent lösning för att uppnå önskad funktionalitet - till exempel via en annan skärm.
• Detta fel förhindrar att andra delar av produkten testas. Men andra områden kan testas oberoende.
4 (låg) • Det finns ett otillräckligt eller oklart felmeddelande som har minimal inverkan på produktanvändningen.
5 (kosmetisk) • Det finns ett otillräckligt eller oklart felmeddelande som inte påverkar produktanvändningen.

Eftersom denna defekt inte kraschar systemet eller blockerar en vital funktion eller förhindrar att andra delar av applikationen testas, kan vi gå med 'Låg'.

Ser ungefär ut?

FEL. Från patientens data är alla vaccinationer och andra påminnelser försenade. Detta kan eller kanske inte stämmer. Dessutom bestämmer deras ålder för en patient om de träffar en barnläkare eller en allmänläkare etc.

Det påverkar doserna av läkemedel och många andra behandlingsområden som vi kanske inte ens känner till.

open-emr-clinical-reminder

Så jag ska gå med “Hög”. Jag håller med om att det är osannolikt att sjukhuspersonalen kommer in i DOB för en patient fel. Men låt det vara en faktor som påverkar prioriteten när problemet ska åtgärdas.

Mitt jobb som testare är att se till att jag kommunicerar allvaret med problemet så bra jag kan.

Avhjälpa: Ha inte bråttom att rapportera. Var 100% säker på att du förstår effekterna av problemen från många vinklar. Det är det bästa värdet som vi testare kan erbjuda. Vi säger inte bara ”Något fungerar inte”. Vi säger också, 'Här är vad som kommer att hända om detta fortsätter att inte fungera.' Massor av skillnad, eller hur?

# 3) Brist på kreativitet

Testarna har en underbar möjlighet att lägga fram förslag för att förbättra programvaran.

I din Verktyg för defekthantering Du kan också skicka in en defekt av typen 'Förbättringsförslag.' Det är här du kan bli kreativ.

Avhjälpa: Tänk utanför lådan. Om du tror att en viss funktion saknar en 'Wow' -faktor och du vet hur du tar med den, lägg idéen fram. I värsta fall kan det avvisas och det är OK. Den viktiga delen är att försöka.

Använd också denna superkraft med försiktighet. Försök att inte göra kommentarer som 'Jag hatar färgen på bannern, ändra den.'

Här är en braexempelav ett förbättringsförslag som jag stötte på: Ersätt 'E-post till återförsäljare' med 'Chatta med återförsäljaren' på en bilhandlare. Det förutspås konvertera mer trafik till försäljning.

Jag önskar att jag var så kreativ! Men kanske kan vi alla arbeta för det.

Här är en bonus. En checklista för att frigöra dessa dåliga vanor:

1. Förmedlar min titel problemet tydligt och koncist?
Till exempel:”Skapa patient fungerar inte” är ingen bra titel. ”Skapa patient misslyckas även när alla inmatningsfält innehåller korrekta värden” är.

2. Hur stor är reproducerbarheten?
Med andra ord, händer det alltid? Vet jag den exakta sekvensen av steg som kommer att upprepa problemet?

3. Är detta problemplattform, webbläsare eller användarspecifikt?

Fyra. Är stegen färdiga och tar dig till ditt problem?

5 . Har jag en skärmdump inkluderad?

6. Behöver jag kommentera min skärmdump för att markera vissa områden?

7. Är namnet på bildfilen beskrivande?
Använd inte något som 'Untitled.jpg.' Ge det ett beskrivande namn.

8. Inkluderade jag testdata?
Till exempel:För en defekt i en administratörsmodul som behöver behörighetsuppgifter, inkludera dem. Utvecklingsteamet har eller kanske inte har tillgång till QA-miljön. Du vill inte ha en fördröjning och följa upp något så grundläggande som det.

9. Kan jag ge några andra detaljer för att förstärka min defekt?
(Exempel:en hänvisning till FRD eller en konversation med klienten, etc)

10. Förstår jag hur svårt problemet är ur olika perspektiv?

elva. Vet jag orsaken till problemet? Om ja, har jag bevis (kanske loggfiler) och kan jag inkludera det? Observera att du kanske inte alltid vet detta eller behöver veta detta. Men om du gör det skadar det inte att inkludera det.

12. Är felrapporten fri från grammatik, format, stavning och skiljetecken?

bästa pc-reparationsprogramvara för Windows 10

13. Känner jag till ett sätt att förbättra produkten?

Tror du att det här är tidskrävande? När det väl är vana kommer det inte att vara längre.

Rotar för bättre felrapportering rutiner!

Om författaren: Denna artikel är skriven av STH-teammedlem Swati.

Skicka gärna dina frågor / kommentarer nedan.

Rekommenderad läsning

^