Meny

Hvordan håndtere dårlige krav som tester

how deal with bad requirements

Prøv Instrumentet Vårt For Å Eliminere Problemer

Det stille konferanserommet var kvelende og alle inne i det var forvirret. Hvordan kunne vi savne det , ble spørsmålet alles ansikt reflektert.

Tross alt, ikke å møte opp med noen relevant feil når brukeren prøver å duplisere den eksisterende posten og la ham gjøre det, var ikke en liten feil - Det også for et forsikringsselskap.

Etter å ha bestemt seg for å spikre problemet, spredte alle seg. Og mens man gravde ut, ble det observert at klienten aldri nevnte noe om duplikat av poster i kravdokumentet, og derfor stilte ingen relevante spørsmål eller tenkte på det.

dårlige krav

Dette var bare et eksempel.

I en karriere på mer enn 10 år , Jeg har observert mange antall tilfeller der prosjekter led på grunn av dårlige eller dårlige krav.

Men som de sier, ingenting er perfekt i denne verden, og du må takle det, og å håndtere prosjekter uten krav eller dårlige krav er et slags mareritt.

La meg forklare -

Hva du vil lære:

Hvor dårlige, dårlige og motstridende krav skaper problemer:

# 1) Ingen krav - Ingen krav innebærer antagelser og gjetninger, og det er derfor ingen tillit. Det er veldig vanskelig å teste et produkt / applikasjon uten noen grunnlinje. Og disse resulterer i mer arbeid, flere feil fra klienten og mer lidelse for prosjektet.

  • Hvordan ville du rapportere et problem om systemkrasj når det ikke er noen definisjon av hvordan oppførselen skal håndteres har vært tilgjengelig?
  • Hvordan vil du formidle at innlastingstid på 100 sekunder for hjemmesiden er uakseptabel når det ikke er noe relevant krav til ytelse?

Mer informasjon om Ingen krav og hvordan du håndterer situasjonen under testing finner du i tidligere publisert artikkel - Hvordan teste en søknad uten krav?

# 2) Dårlige krav - Sitatet, Å vite noe ufullstendig er farlig enn ikke å vite det i det hele tatt , er veldig sant når det gjelder å håndtere et dårlig krav.

Å tolke et dårlig krav og implementere det samme er en stor risiko.

  • Hvordan vil du bekrefte at forgrunnsvinduet som viser søkeresultatene er gyldig eller ikke når det eneste kravet som ble nevnt var - søkeresultatene skal være riktige, og du er ikke sikker på hvilke kriterier som skal vurderes mens du søker.
  • Hvordan vil du tolke dette - Glemt passord bør implementeres for å gjøre det lettere for brukeren å regenerere / tilbakestille glemt passord. Ukjent om hvilken arbeidsflyt kunden ønsker for glemt passord, utvikler implementerer det han / hun synes er best og konfliktene starter.

# 3) Motsettende krav - Å be noen om å gjøre to forskjellige ting samtidig, er bare å forvirre ham / henne og systemet er heller ikke noe unntak.

  • Hvordan vil du teste en applikasjon med nevnte krav er som nedenfor:
    • Søknaden skal alltid åpnes på hjemmesiden.
    • Brukere forventes å logge på for å få tilgang til applikasjonen.
  • Hva vil du bestemme prioriteten når kravdokumentet er som nedenfor:
    • Spillapplikasjonen bør fremme brukeren til neste nivå hvis brukeren scorer 1000.
    • Brukeren skal omdirigeres til gratis abonnementside når han får 1000.

Og slik skaper de dårlige, dårlige og motstridende kravene problemer.

Å være i programvareindustrien, bør det være en del av prosjektet, da noen ganger er til og med kunden ikke sikker på hva de vil ha og hvordan de skal formulere det.

Fra testperspektiv, selv om det er vanskelig å håndtere disse tvetydige eller vage kravene, er det ikke helt umulig.

La oss se på de mulige løsningene:

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

Metode nr. 1)Utforsk og lær:

Å utforske andre applikasjoner, lære om generell forventet atferd, forstå arbeidsflyt, tenke på brukervennlighet og bruke logikk er en måte å håndtere situasjonen på. Også, stole på utforskende testing vil være nyttig i denne typen situasjoner der kravene ikke er klare.

Mesteparten av tiden er det en god innsats å prioritere brukeropplevelse og bekvemmelighet når kravene ikke er klare.

Metode 2)Utnytt erfaring:

Utnytt erfaring

Domenerfaring , generell testopplevelse, problemer som tidligere har blitt møtt og personlig innsikt kan bidra til å løse forvirrende situasjoner og krav.

Metode 3)Se wireframes:

Wireframes er et slags visuelt krav der du kan finne små detaljer, og disse detaljene kan være svært nyttige for å skape det forventede bildet av produktet eller applikasjonen og hjelper deg med å dekke testaspekter på en bedre måte.

Les mer => Wireframes - Bør de virkelig testes? Og i så fall, hvordan?

Metode 4)Peer-diskusjon:

beste måten å laste ned fra youtube til mp3

Peer-diskusjon

Uansett hva forvirringen er, hvis diskutert med riktig gjeng mennesker, blir ting avklart. Alle har forskjellige erfaringer, forventninger, brukeres blikk og analysesyn, og å diskutere de dårlige kravene med jevnaldrende vil tjene en fordel ved å krystallisere forståelsen og øke selvtilliten.

Metode 5)Avklaring fra kunde:

Kunden er eieren av produktet / applikasjonen, og det er alltid lurt å henvende seg til ham når det gjelder klarhet i kravene. Men husk at det ikke er tilrådelig å angripe kunden med 100-spørsmål. Før du gjør det, kreves det noen lekser.

Prøv å finne de beste metodene som er tilgjengelige, forstå fordelene ved implementeringen, og kontakt deretter kunden med spørsmål og mulig løsning.

Konklusjon

Til slutt er løst definerte eller udefinerte krav en del av testernes liv, og vi må akseptere dem, men la oss prøve å være optimistiske og finne løsninger på det. Vi er jo testere, hjelper med å holde applikasjonene på sporet og beskytte dem mot å falle ned. YAY til oss :)

Om forfatteren: Dette inspirerende innlegget er skrevet av STH-teammedlem Bhumika M. Hun er prosjektleder med 10+ års erfaring med programvaretesting.

Glad test, som vanlig ... ..venter på dine synspunkter, kommentarer og meninger.

Anbefalt lesing

^