Meny

Hva er tidlig testing: Test tidlig, test ofte MEN hvordan? (En praktisk guide)

what is early testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Hva er tidlig testing?

Testing av programvare bør starte tidlig i programvarens utviklingslivssyklus. Dette hjelper til med å fange opp og eliminere feil i de tidlige stadiene av SDLC, dvs. kravsamling og designfaser. En tidlig start på testingen bidrar til å redusere antall feil og til slutt omarbeidelseskostnadene til slutt.

De forskjellige aspektene av Tidlig testing som vil hjelpe QA-ledere og -ledere mens de utvikler eller utformer teststrategidokumentet i SDLC, blir forklart her.

Vedtakelse av tidlig test vil umåtelig resultere i vellykket levering av et kvalitetsprodukt.

tidlig testing (1)

Ved slutten av denne veiledningen vil leserne, kvalitetsledere, ledere og testere ha god kunnskap om begrepene nedenfor:

som ikke er en av artiklene som testes under systemtesting?
  • Hvorfor tidlig testing i SDLC (prosjekt eller programvareutgivelse)?
  • Omfang av tidlig innsats
    • Hva skal jeg teste tidlig?
    • Start og avslutt
  • Fordeler og ulemper

La oss nå utforske nyansene i detalj !!

Hva du vil lære:

Prinsipper for testing

Figur 1 - Forenklet oversikt over prinsipper for testing

1. prinsipper for testing

For en gitt programvare eller system- eller produktutgivelse i SDLC, er det forskjellige veldefinerte metoder eller strategier for de fleste av følgende prinsipper for testing.

  • Hva er testing?
  • Hvorfor teste?
  • Hva skal jeg teste?
  • Hvordan teste?

Noen av de mest dvelende spørsmålene som mange lesere, testere, ledere og kvalitetssikringsledere vil stille eller ønsker å få mer klarhet om inkluderer imidlertid (grå område i Figur 1 )

  • Når skal du begynne å teste i en programvareutgivelse, eller når skal testing starte i et prosjekt?
  • Når skal du begynne å teste og når skal du slutte å teste?
  • Hvorfor testing bør starte tidlig i SDLC?
  • Hva er en tidlig test innen programvareutvikling?

For enkel forståelse av publikum, har jeg satt sammen alle spørsmålene om det 'grå området' under en paraply som heter Tidlig testing.

Hvorfor teste tidlig i SDLC?

La oss diskutere noen hendelser og aktiviteter som er en del av testingen.

Vanligvis tildeler Program Management Team en Program Manager (PM) til en gitt programvareutgivelse eller et prosjekt. Statsministeren i samarbeid med alle interessentene, inkludert markedsføring, utvikling, kvalitetssikring og supportteam, kommer med en utgivelsesplan

I denne veiledningen har jeg valgt Kvartalsutgivelsesplan ved hjelp av fossefallmodellen å forklare Tidlige testkonsepter i detalj.

Testplan for programvareutgivelse

De fleste av organisasjonene følger fortsatt det tradisjonelle Tidsbasert utgivelse (TBR) modeller der programvare- eller produktutgivelsene er planlagt for levering kvartalsvis eller halvårlig eller årlig.

Overveiende brukes Waterfall-modellen til å utføre slike programvareutgivelser. I noen tilfeller for en kortere utgivelsessyklus, er Agile / Scrum-modellen vedtatt.

Figur 2 - Typisk testplan for kvartalsvis utgivelse (ikke samlet prosjekt eller utgivelsesplan)

Testplan for kvartalsvis utgivelse

Virkningen av kritiske eller høye alvorlighetsfeil

Figur 3 - Typisk innvirkning av kritiske feil

Typisk innvirkning av kritiske feil

Hovedsakelig , i løpet av testen, forventes det at

  • Kritiske eller høy alvorlighetsfeil identifiseres og logges av testere.
  • Utviklere må løse disse feilene.
  • Deretter må testere verifisere løsningene.

for det andre , er det allment anerkjent av mange produkt- og programvaretekniske organisasjoner at å fikse og verifisere høy alvorlighetsgrad eller kritiske feil på et veldig stort antall er

  • Tidkrevende
  • Ressurs hogging (menneske + maskin)
  • Utsatt for sikkerhet, å fikse kritiske feil berører for det meste en stor del av koden, inkludert kryssområdene.

Til slutt , hvis et stort antall av de kritiske feilene blir funnet under slutten av en gitt utgivelse, så skjer en eller flere av følgende negative utviklingstrekk.

  • Høy sannsynlighet for at testsyklusen utvides.
  • Stor sannsynlighet for at frist for utgivelse blir savnet.
  • En spesiell funksjon som har et stort antall mangler, må alle sammen trekkes ut av den spesifikke utgivelsen.
  • Kundeforpliktelser blir savnet.

Hva med de andre feilene?

Det er middels og lav prioritetsfeil som vil bli identifisert og logget av testerne. Disse må også håndteres riktig av utviklings- og QA-teamet. Dermed er det generelt en omfattende øvelse.

Det er ingen Silver Bullet

Det er et kjent faktum at ingen mengder testing kan avdekke alle feil som et programvareprodukt eller systemet har. Betydning, praktisk talt, verken er det slutt på testing eller produktet er feilfritt.

Fra ' Servicevennlighet 'Synspunkt i en Competitive and Time To Market (TTM) -modell, er det behov for å bryte den typiske tankegangen for å avdekke maksimale feil tidlig i en frigjøringssyklus, spesielt identifisering av kritiske og høy alvorlighetsfeil.

Noe av eller alle de ovennevnte vil ha en negativ innvirkning på organisasjonens virksomhet. Ved å adoptere Tidlig testing 'Ha en separat testaktivitet vil være gunstig for den generelle styringen av SDLC for et gitt prosjekt eller utgivelse.

Omfanget av tidlig innsats

Etter å ha forstått målet med å teste tidlig i forrige avsnitt med tittelen ‘ Hvorfor tidlig testing? La oss nå diskutere ' Omfanget av tidlig testinnsats ' i detalj.

Når vi introduserer Testing Early som en ny aktivitet som utelukkende skal spores i løpet av Testing-gjennomføring, anbefales det å øve på omfanget av testinnsats som forklart nedenfor

Antagelse:

  • Hele prosjekt- eller programvareutgivelsesplanen er godkjent og gjort tilgjengelig for alle interessenter.
  • Generelt teststrategidokument er utviklet, gjennomgått og godkjent av alle interessenter.
  • Funksjoner med høy, middels, lav prioritet som skal testes, er godt dokumentert.
  • Testplaner og testtilfeller for alle funksjonene er utviklet, gjennomgått og godkjent av alle interessenter.
  • Alle testplaner og testtilfeller lastes opp i et sentralt depot for sporing av utførelse av testing.
  • All menneskelig ressurs, infrastrukturutstyr og verktøy er tilgjengelig for å sette opp testbedd (e) og utføre testplaner.

Hva skal jeg teste tidlig?

Figur 4 - Samlet tilnærming til omfanget av Testing Early

4.Hva du skal teste i tidlig testing

Nærme seg

  • La oss ta en Eksempel av utgivelse XYZ som har tre funksjoner med høy prioritet A, B og C, 10 funksjoner med middels prioritet og 15 mindre (eller lav prioritet) funksjoner.
  • Funksjoner med høy prioritet er de som genererer høy inntekt og / eller standardoverholdelse og / eller konkurrenters innhenting og / eller konkurrenters ensartethet og alle disse.
  • Funksjoner med høy prioritet involverer vanligvis litt kompleks koding, et stort antall nye kodelinjer er lagt til.
  • Et stort antall nye kodelinjer kan også bety stor sannsynlighet for kryssområder.
  • Vanligvis er funksjoner med høy prioritet og / eller funksjoner som har et stort antall nye kodelinjer de beste kandidatene for å teste tidlig.
  • Det trenger ikke være en egen testplan utviklet for tidlig testaktivitet.
  • QA-ledere eller testere sammen med utviklingsledere eller små og mellomstore selskaper (fageksperter) må diskutere og bli enige om dekning av kode / test for denne testaktiviteten.
  • Identifiser passende høyprioritets testtilfeller og til og med noen middels prioriterte testtilfeller hvis du mener det er nødvendig fra hver av funksjonene Testplaner A, B og C.
  • Når de aktuelle funksjonene og delmengden av testsaker er identifisert, må du sørge for at de spores ved hjelp av testsporingsverktøyet som er vedtatt av organisasjonen.

Tips: Samarbeid er nøkkelen! Under tidlig testaktivitet må både utviklings- og QA-teamene samarbeide tett for å sikre at de oppsatte målene oppnås med kvalitetsresultater.

Start og avslutt på tidlig test

Det er viktig at både utviklings- og QA-teamet brainstormer og godtar alle tilnærmingene til hele den tidlige testaktiviteten, inkludert start- og avslutningsdato, slik at alle er på samme side.

Oppføringskriterier for start

  • Prosent av fullføring av integrasjonstesting
  • Antall åpne feil
  • Ingen blokkerere som starter tidlig test

Aktivitetsfase

  • Spore fremgang
  • Antall koder faller under denne testingen
  • Feilrettingsmetode
  • Feilbekreftelsesmetode
  • Registrer disse testresultatene

Utgangskriterier

  • Overlever aktiviteter til neste testfase (vanligvis funksjonstesting).
  • Løsning av uløste feil funnet under tidlig test.
  • Oppløsning av blokkerere hvis noen for neste fase av testen.
  • Publiser tidlige testresultater.

Fordeler og ulemper

Hvert nytt initiativ eller aktivitet har sine egne fordeler og ulemper.

La oss utforske fordeler og ulemper ved denne testtilnærmingen.

Fordeler

  • Ideelt egnet for Waterfall-modellen.
  • Hjelper med å avdekke kritiske feil tidlig i testsyklusen.
  • Identifisering av kritiske feil tidlig i en utgivelsessyklus.
  • Hjelper utviklingsteamet med å stabilisere koden tidlig.
  • Hjelper med å minimere sikkerheten på grunn av feilrettinger.
  • Hjelper utviklingsteamet med å identifisere sårbarheter på tvers av kryssområder i detalj tidlig i utgivelsessyklusen.
  • Ledelsesteamet kan ta hensiktsmessige forretningsbeslutninger med omhu på uløste kritiske feil i den aktuelle utgivelsen eller et prosjekt.
  • Hjelper med å utvide testdekning og sykle effektivt.
  • Hjelper med å distribuere ressurser for utvikling og testing effektivt og effektivt.

Ulemper

  • Ikke ideell for Agile / Scrum-modell. Imidlertid kan slike modeller ta i bruk tidlig test i sprints med passende justeringer.
  • Det er en sjanse for redusert Integrasjonstesting av utviklingsteamet.

Konklusjon

Kunder eller sluttbrukere kjøper eller bruker vedlikeholdsprodukt eller et system eller en løsning. Validering av programvare som kjører på slike systemer eller produkter for brukervennlighet er det primære kravet

Nøkkelkomponenter i prinsippene for testing som hvorfor teste? Hva er testing? Hva skal jeg teste? Hvordan teste? er stort sett godt definert og forstått. Imidlertid er det noen dvelende spørsmål som stadig dukker opp i tankene til leserne, testerne, lederne og lederne om begreper som tidlig testing.

Vedtakelse av tidlig testing som en integrert aktivitet i den overordnede testplanen for et gitt programvareprosjekt eller en utgivelse, er til stor fordel for organisasjonen å levere et robust kvalifisert produkt eller et system.

Har du noen gang innsett viktigheten av tidlig testing i karrieren din? Del gjerne dine tanker og erfaringer i kommentarfeltet nedenfor !!

Anbefalt lesing

^