how test software requirements specification
Er du klar over det 'Mesteparten av Feil i programvare skyldes ufullstendige eller unøyaktige funksjonelle krav? ” Uansett hvor godt det er skrevet, spiller ikke programvarekoden noe, og ingenting kan gjøres hvis det er uklarheter i kravene.
Denne artikkelen om programvarekravspesifikasjon (SRS) sier at krav må være klare, spesifikke, målbare og komplette uten motsetninger.
Det er bedre å fange kravene uklarheter og fikse dem i den tidlige utviklingslivssyklusen.
Kostnadene ved å fikse feilen etter fullført utvikling eller produktutgivelse er for høye. Så det er viktig å ha kravanalyse og fange disse uriktige kravene før designspesifikasjoner og prosjektgjennomføringsfaser av SDLC.
Hva du vil lære:
Hvordan måle funksjonelle SRS-dokumenter?
Vi må definere noen standardtester for å måle kravene. Når hvert krav er bestått gjennom disse testene, kan du evaluere og fryse funksjonskravene.
La oss ta en eksempel, du jobber med et nettbasert program. Kravet er som følger: 'Nettapplikasjon skal kunne tjene brukerspørsmålene så tidlig som mulig'
Hvordan vil du fryse kravet i dette tilfellet?
Hva vil være dine kravtilfredshetskriterier? For å få svaret, still dette spørsmålet til interessentene: Hvor mye responstid er ok for deg? Hvis de sier, vil vi godta svaret hvis det er innen to sekunder, så er dette kravet ditt. Frys dette kravet og ha samme fremgangsmåte for neste krav også.
Vi har nettopp lært hvordan vi måler kravene og fryser dem i fasene Design, Implementering og Testing.
La oss ta et annet eksempel: Jeg jobbet med et nettbasert prosjekt. Kunden (interessenter) spesifiserte prosjektkravene i den innledende fasen av prosjektutviklingen. Lederen min sirkulerte alle kravene i teamet for gjennomgang. Da vi startet diskusjonen om disse kravene, ble vi bare sjokkert!
Alle hadde sin egen oppfatning om kravene. Vi fant mange uklarheter i ‘vilkårene’ spesifisert i kravdokumentene, som senere ble sendt til klienten for gjennomgang / avklaring.
Klienten brukte mange tvetydige termer, som hadde mange forskjellige betydninger, noe som gjorde det vanskelig for oss å analysere den eksakte betydningen. Den neste versjonen av kravdokumentet fra klienten var klar nok til å fryse for designfasen.
c ++ røye til int
Fra dette eksemplet lærte vi at 'Krav skal være klare og konsekvente'
Neste kriterier for testing av kravspesifikasjonen er 'Oppdag manglende krav', la oss ta en titt på den.
Oppdag manglende krav
Mange ganger får prosjektdesignerne ikke en klar ide om hver spesifikke modul, og de antar ganske enkelt noen krav i designfasen. Ethvert krav bør ikke være basert på antakelser. Kravene skal være fullstendige og dekke alle aspekter av systemet under utvikling.
Spesifikasjonene skal angi begge typer krav, dvs. hvilket system skal gjøre og hva det ikke bør.
Generelt bruker jeg min egen metode for å avdekke de uspesifiserte kravene. Når jeg leser Programvarekravspesifikasjonsdokument (SRS) , Jeg noterer min egen forståelse av kravene som er spesifisert, pluss andre krav som SRS-dokumentet skal dekke.
Dette hjelper meg med å stille spørsmålene om de uspesifiserte kravene og dermed gjøre det tydeligere.
For å kontrollere fullstendigheten av kravene, del inn kravene i tre seksjoner, 'Må implementere' krav, krav som ikke er spesifisert, men som er 'antatt' og den tredje typen er 'fantasi' type krav. Sjekk om alle kravene er oppfylt før programvaredesignfasen.
Sjekk om kravene er knyttet til prosjektmålet
Noen ganger har interessenter sin egen kompetanse, som de forventer å komme i systemet under utvikling. De tror ikke engang om dette kravet vil være relevant for prosjektet. Sørg for å identifisere slike krav. Prøv å unngå alle irrelevante krav i den første fasen av prosjektutviklingssyklusen.
Hvis ikke mulig, så still spørsmålene til interessenter som hvorfor vil du implementere dette spesifikke kravet? Dette vil beskrive det spesifikke kravet i detalj, og dermed gjøre det lettere for utformingen av systemet med tanke på det fremtidige omfanget.
Men hvordan avgjøre om kravene er relevante eller ikke?
Enkelt svar: Sett prosjektmålet og still dette spørsmålet: Hvis ikke implementering av dette kravet vil føre til problemer med å nå vårt spesifiserte mål? Hvis ikke, er dette et irrelevant krav. Spør interessentene om de virkelig ønsker å implementere denne typen krav.
Kort sagt, kravspesifikasjon (SRS) -dokumentet bør adressere følgende:
- Prosjektfunksjonalitet (Hva skal gjøres og hva som ikke skal gjøres).
- Programvare, maskinvaregrensesnitt og brukergrensesnitt.
- Systemkorrekthet, sikkerhet og ytelseskriterier.
- Implementeringsproblemer (risiko) hvis noen.
Konklusjon
Jeg har dekket nesten alle aspekter av kravmåling. For å være spesifikk om kravene, vil jeg oppsummere kravtesting i en setning:
'Kravene skal være klare og spesifikke uten usikkerhet, kravene skal kunne måles i forhold til spesifikke verdier, kravene skal kunne testes med noen evalueringskriterier for hvert krav, og kravene skal være fullstendige, uten motsetninger
Testing bør starte i kravfasen for å unngå ytterligere kravrelaterte feil. Kommunisere mer og mer med dine interessenter for å avklare alle kravene før du starter prosjektdesign og implementering.
Har du noen erfaring med å teste programvarekrav?
Del dem gjerne i kommentarene nedenfor.
Anbefalt lesing
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Programvaretesting QA Assistant Job
- Destruktiv testing og ikke-destruktiv testing
- Mind Mapping i programvaretesting - måter å gjøre testing morsommere!
- Hvordan teste en søknad uten krav?
- Programvare Testing Course: Hvilket programvare Testing Institute skal jeg delta?
- Velge programvaretesting som din karriere
- Programvaretesting Teknisk innhold Writer Freelancer Jobb