Menu

Sådan håndteres dårlige krav som tester

how deal with bad requirements

Prøv Vores Instrument Til At Fjerne Problemer

Det tavse konferencelokale var kvalt og alle inde i det var forvirrede. Hvordan kunne vi gå glip af det? , blev spørgsmålet om alles ansigt afspejlet.

Når alt kommer til alt ikke at dukke op med nogen relevant fejl, når brugeren forsøger at duplikere den eksisterende post og lade ham gøre det, var det ikke en lille fejl - det også for et forsikringsselskab.

Efter at have besluttet at negle problemet, spredte alle sig. Og mens man gravede ud, blev det observeret, at klienten aldrig nævnte noget om duplikat af poster i kravdokumentet, og derfor stillede ingen relevante spørgsmål eller tænkte over det.

dårlige krav

Dette var bare et eksempel.

I en karriere på mere end 10 år , Jeg har observeret mange antal tilfælde, hvor projekter led på grund af dårlige eller dårlige krav.

Men som de siger, intet er perfekt i denne verden, og du bliver nødt til at håndtere det, og at håndtere projekter uden krav eller dårlige krav er et slags mareridt.

Lad mig forklare -

Hvad du vil lære:

Hvor dårlige, dårlige og modstridende krav skaber besvær:

# 1) Ingen krav - Ingen krav indebærer antagelser og gæt, og derfor er der ingen tillid. Det er meget vanskeligt at teste et produkt / en applikation uden nogen baseline. Og disse resulterer i mere arbejde, flere fejl fra klienten og mere lidelse for projektet.

  • Hvordan ville du rapporter et problem om systemnedbrud, når der ikke er nogen definition af, hvordan adfærden skal håndteres, har været tilgængelig?
  • Hvordan vil du formidle, at indlæsningstid på 100 sekunder til startsiden er uacceptabel, når der ikke er noget relevant krav til ydeevne?

Flere oplysninger om Ingen krav og hvordan man håndterer situationen under test kan findes i tidligere offentliggjorte artikler - Hvordan testes en ansøgning uden krav?

# 2) Dårlige krav - Citatet, At vide noget ufuldstændigt er farligt end slet ikke at vide det , er meget sandt, når det kommer til at håndtere et dårligt krav.

At fortolke et dårligt krav og implementere det samme er en stor risiko.

  • Hvordan ville du bekræfte, at pop op-vinduet, der viser søgeresultater, er gyldig eller ikke, når det eneste krav, der blev nævnt, var - søgeresultaterne skal være korrekte, og du er ikke sikker på, hvilke kriterier der skal overvejes under søgning.
  • Hvordan ville du fortolke dette - Glemt kodeord skal implementeres for at gøre det lettere for brugeren at regenerere / nulstille glemt kodeord. Ukendt om hvilket arbejdsflow kunden ønsker for glemt kodeord, udvikler implementerer det, han / hun synes er bedst, og konflikterne starter.

# 3) Modstridende krav - At bede nogen om at gøre to forskellige ting på samme tid er bare at få ham / hende forvirret, og systemet er heller ikke en undtagelse.

  • Hvordan vil du teste en ansøgning med de nævnte krav er som nedenfor:
    • Ansøgning skal altid åbnes på startsiden.
    • Brugere forventes at logge ind for at få adgang til applikationen.
  • Hvad ville du beslutte prioriteten, når kravdokumentet er som nedenfor:
    • Spilapplikationen skal fremme brugeren til næste niveau, hvis brugeren scorer 1000.
    • Brugeren skal omdirigere til gratis abonnementside, når han får 1000.

Og det er sådan, de dårlige, dårlige og modstridende krav skaber besvær.

At være i softwareindustrien, bør det være en del af projektet, da nogle gange endda kunden ikke er sikker på, hvad de nøjagtigt vil have, og hvordan de skal formulere det.

Fra testperspektiv, selvom det er svært at håndtere disse tvetydige eller vage krav, er det ikke helt umuligt.

Lad os se på de mulige løsninger:

Dårlige krav, og hvordan man håndterer dem som tester:

Metode nr. 1)Udforsk og lær:

At udforske andre applikationer, lære om generel forventet adfærd, forstå arbejdsgang, tænke på brugervenlighed og anvende logik er en måde at håndtere situationen på. Også, stole på sonderende test ville være nyttigt i denne slags situationer, hvor kravene ikke er klare.

For det meste er det en god indsats at prioritere brugeroplevelse og bekvemmelighed, når kravene ikke er klare.

Metode nr. 2)Udnyt erfaring:

Udnyt erfaring

Domæneoplevelse , den samlede testoplevelse, problemer i fortiden og personlig indsigt kan hjælpe med at løse forvirrende situationer og krav.

Metode nr. 3)Se wireframes:

Wireframes er en slags visuelt krav, hvor du kan finde små detaljer, og disse detaljer kan være meget nyttige til at skabe det forventede billede af produktet eller applikationen og hjælper med at dække testaspekter på en bedre måde.

Læs mere => Wireframes - Bør de virkelig testes? Og hvis ja, hvordan?

Metode nr.4)Peer-diskussion:

qa spørgsmål og svar fra analytikerinterview

Peer-diskussion

Uanset hvad forvirringen er, hvis det diskuteres med den rigtige flok mennesker, bliver tingene afklaret. Alle bærer forskellige oplevelser, forventninger, brugerens øje og analysesyn og at diskutere disse dårlige krav med jævnaldrende vil tjene en fordel ved at krystallisere forståelsen og øge selvtilliden.

Metode nr. 5)Afklaring fra kunde:

Kunden er ejer af produktet / applikationen, og det er altid klogt at henvende sig til ham, når det gælder klarhed i kravene. Men husk, det er ikke tilrådeligt at angribe kunden med 100'ers spørgsmål. Før du gør det, kræves nogle lektier.

Prøv at finde ud af de bedste tilgængelige fremgangsmåder, forstå fordelene ved implementeringen, og kontakt derefter kunden med spørgsmål og mulig løsning.

Konklusion

Endelig er løst definerede eller udefinerede krav en del af testernes liv, og vi er nødt til at acceptere dem, men lad os prøve at være optimistiske og finde løsninger på det. Når alt kommer til alt er vi testere, hjælper med at holde applikationerne på rette spor og beskytte dem mod at falde fladt. YAY til os :)

Om forfatteren: Dette inspirerende indlæg er skrevet af STH-teammedlem Bhumika M. Hun er en projektleder med 10+ års erfaring med softwaretest.

Glad test, som sædvanlig ... ..venter på dine synspunkter, kommentarer og meninger.

Anbefalet læsning

^