Meny

Hur man hanterar dåliga krav som testare

how deal with bad requirements

Prova Vårt Instrument För Att Eliminera Problem

Det tysta konferensrummet kvävde och alla i det var förvirrade. Hur kunde vi missa det? , återspeglades frågan allas ansikte.

När allt kommer omkring att inte dyka upp med något relevant fel när användaren försöker duplicera den befintliga posten och låta honom göra det var inte ett litet fel - Det också för ett försäkringsbolag.

Efter att ha beslutat att spika upp frågan spridda alla sig. Och medan man grävde ut sågs det att kunden aldrig nämnde någonting om duplicering av poster i kravdokumentet och därför ställde ingen relevanta frågor eller tänkte på det.

dåliga krav

Detta var bara ett exempel.

I en karriär på mer än 10 år , Jag har observerat många antal fall där projekt led på grund av dåliga eller dåliga krav.

Men som de säger är ingenting perfekt i den här världen och du kommer att behöva ta itu med det och att hantera projekt utan krav eller dåliga krav är en mardröm.

Låt mig förklara -

Vad du kommer att lära dig:

Hur dåliga, dåliga och motstridiga krav skapar problem:

# 1) Inga krav - Inga krav innebär antaganden och gissningar och därför finns det inget förtroende. Det är mycket svårt att testa en produkt / applikation utan någon baslinje. Och dessa resulterar i mer arbete, fler buggar från klienten och mer lidande för projektet.

  • Hur skulle du rapportera ett problem om systemkrasch när det inte finns någon definition av hur beteendet ska hanteras har varit tillgängligt?
  • Hur skulle du förmedla att laddningstid på 100 sekunder för hemsidan är oacceptabel när det inte finns något relevant krav på prestanda?

Mer information om Inga krav och hur man hanterar situationen under testning finns i tidigare publicerad artikel - Hur testar jag en ansökan utan krav?

# 2) Dåliga krav - Citatet, Att veta något ofullständigt är farligt än att inte veta det alls , är mycket sant när det gäller att hantera ett dåligt krav.

Att tolka ett dåligt krav och genomföra detsamma är en stor risk.

  • Hur skulle du bekräfta att popup-fönstret som visar sökresultat är giltigt eller inte när det enda kravet som nämns var - sökresultaten ska vara korrekta och du är inte säker på vilka kriterier som ska beaktas vid sökning.
  • Hur skulle du tolka detta - Glömt lösenord bör implementeras för att underlätta för användaren att regenerera / återställa glömt lösenord. Okänt om vilket arbetsflöde kunden vill ha för glömt lösenord, utvecklare implementerar det han / hon tycker är bäst och konflikterna börjar.

# 3) Motstridiga krav - Att be någon att göra två olika saker samtidigt är att bara förvirra honom / henne och systemet är inte ett undantag.

  • Hur skulle du testa en ansökan med nämnda krav är som nedan:
    • Ansökan ska alltid öppnas på hemsidan.
    • Användare förväntas logga in för att komma åt applikationen.
  • Vad skulle du bestämma prioriteten när kravdokumentet är enligt nedan:
    • Spelapplikationen bör främja användaren till nästa nivå om användaren får 1000.
    • Användaren ska omdirigeras till en gratis prenumerationssida när han fått 1000.

Och det är så de dåliga, dåliga och motstridiga kraven skapar problem.

Att vara i mjukvaruindustrin bör det vara en del av projektet eftersom ibland till och med kunden inte är säker på exakt vad de vill ha och hur de ska formulera det.

Ur testperspektiv, även om det är svårt att hantera dessa tvetydiga eller vaga krav, är det inte helt omöjligt.

Låt oss titta på de möjliga lösningarna:

Dåliga krav och hur man hanterar dem som testare:

Metod nr 1)Utforska och lär dig:

Att utforska andra applikationer, lära sig om allmänt förväntat beteende, förstå arbetsflöde, tänka på användarnas bekvämlighet och tillämpa logik är ett sätt att hantera situationen. Också, förlitar sig på utforskande testning skulle vara till hjälp i denna typ av situationer där kraven inte är klara.

För det mesta är det bra att prioritera användarupplevelse och bekvämlighet när kraven inte är klara.

Metod nr 2)Använd erfarenhet:

Använd erfarenhet

Domänupplevelse , övergripande testupplevelse, tidigare problem och personlig insikt kan hjälpa till att hantera förvirrande situationer och krav.

Metod # 3)Se trådramar:

Trådramar är ett slags visuellt krav där du kan hitta små detaljer och dessa detaljer kan vara till stor hjälp för att skapa den förväntade bilden av produkten eller applikationen och hjälper till att täcka testaspekter på ett bättre sätt.

Läs mer => Trådramar - borde de verkligen testas? Och i så fall, hur?

Metod # 4)Peer-diskussion:

c ++ genererar slumptal mellan 1 och 10

Peer-diskussion

Oavsett vad förvirringen är, om det diskuteras med rätt folkmassa klargörs saker. Alla har olika upplevelser, förväntningar, användarögon och analysvy och att diskutera dessa dåliga krav med kamrater kommer att tjäna en fördel med att kristallisera förståelsen och öka självförtroendet.

Metod nr 5)Förtydligande från kund:

Kunden är ägaren till produkten / applikationen och det är alltid klokt att kontakta honom när det gäller tydlighet i kraven. Men kom ihåg att det inte är tillrådligt att attackera kunden med 100-tals frågor. Innan du gör det krävs lite läxor.

Försök ta reda på bästa praxis, förstå fördelarna med implementeringen och kontakta kunden med frågor och möjlig lösning.

Slutsats

Slutligen är löst definierade eller odefinierade krav en del av testarens liv och vi måste acceptera dem men låt oss försöka vara optimistiska och bestämma lösningar på det. När allt kommer omkring är vi testare, hjälper till att hålla applikationerna på rätt spår och skydda dem från att falla ner. YAY till oss :)

Om författaren: Det här inspirerande inlägget är skrivet av STH-teammedlem Bhumika M. Hon är projektledare och har 10+ års erfarenhet av programvarutestning.

Lycklig testning, som vanligt ... .. väntar på dina åsikter, kommentarer och åsikter.

Rekommenderad läsning

^