Borte er dagene da middelmådig testing var trenden. I dagens verden må bedrifter utføre detaljert testing.Fra planlegging og forskning til utførelse og vedlikehold spiller hver fase en avgjørende rolle i å teste et produkt.

SDLC handler om å sikre produktets kvalitet. Hvert program har forskjellige attributter som pålitelighet, funksjonalitet og ytelse. OG STLC hjelper til med å forbedre disse egenskapene og letter levering av et ideelt sluttprodukt.

et produkt av høy kvalitet gir lavere vedlikeholdskostnader på lang sikt. Stabiliteten til et program eller programvare er et must for å lokke nye brukere. Bortsett fra det, konsekvent pålitelige produkter også bidra til å holde eksisterende klientell. For et produkt å bo i riket av virksomheten, er det viktig å fokusere på HVER fase AV STLC.

Faser Av Programvaretesting Livssyklus

Validering av hver modul av programvare eller applikasjon er et must for å sikre produktpresisjon og nøyaktighet. Siden programvaretesting i seg selv er en forseggjort prosess, utfører testere det i faser. Kompleksiteter kan dukke opp hvis testing mangler organisasjon. Kompleksiteten kan inkludere uløste feil, uoppdagede regresjonsfeil, eller i verste fall en modul som hoppet over testing fordi fristen kom nærmere.

Hver fase av STLC har et bestemt mål og leveranser. Det innebærer initiering, utførelse og avslutning av testprosessen.

La oss ta en titt på ulike faser av programvaretestens livssyklus i detalj.

Kravanalyse

dine verdifulle programvaretestere må se, studere og analysere tilgjengelige spesifikasjoner og krav. Visse krav gir resultater ved å mate dem med inngangsdata. Disse kravene er testbare krav. Testere studerer både funksjonelle og ikke-funksjonelle krav. Etter det må de plukke ut testbare krav.

Aktiviteter i denne fasen inkluderer brainstorming for kravanalyse og identifisering og prioritering av testkrav. De inkluderer også å plukke ut krav til både automatisert og manuell testing.

Det er noen ting du har test selv om det ikke er eksplisitt nevnt. Et klikk på en aktiv knapp bør gjøre noe, et tekstfelt for telefonnummer bør ikke godta alfabeter sendt. Disse tingene er universelle og bør alltid testes. Men i kravanalysefasen handler det om å vite mer spesifikke detaljer om produktet. Du må lære hvordan produktet skal være i sin ideelle tilstand.

for å oppsummere:

• Forstå forventet utgang fra produktet.
• Identifiser eventuelle smutthull i spesifikasjonene.
• Samle prioriteringer.
• Utføre automatisering feasibility sjekker.

Testplanlegging

det andre trinnet er testplanlegging, OG QA-teamet lager denne planen etter å ha analysert alle nødvendige testkrav. De skisserer omfanget og målene etter å ha forstått produktdomenet. Teamet analyserer deretter de involverte risikoene og definerer tidsplaner og testmiljøer for å lage en strategi.

etter det fullfører ledelsen verktøyene og tildeler roller og ansvar til enkeltpersoner. En omtrentlig tidslinje er også definert ved hvilken testingen av hver modul skal fullføres.

for å oppsummere:

• Forbered testplan dokumentasjon.
• Beregn tid og innsats.
• Sluttføre på verktøy og plattform.
• Tilordne oppgaver til grupper og enkeltpersoner.
• Identifiser treningskrav

Test Case Design og Utvikling

etter utvikling og planlegging er det på tide å la kreativiteten flyte! Basert på testplanen, testere designe og utvikle testtilfeller. Testtilfeller bør være omfattende og bør dekke nesten alle mulige tilfeller. Alle gjeldende permutasjoner og kombinasjoner bør samles. Du kan prioritere disse testtilfellene ved å undersøke hvilke av dem som er mest vanlige eller hvilke av dem som vil påvirke produktet mest.

Neste kommer verifisering og validering av spesifiserte krav i dokumentasjonstrinnet. Også gjennomgang, oppdatering og godkjenning av automatiseringsskript og testtilfeller er viktige prosesser i dette stadiet. Denne fasen inkluderer også å definere ulike testforhold med inngangsdata og forventede resultater.

for å oppsummere:

• Forskning og samle mulige handlinger på produktet.
• Opprett testtilfeller.
• Prioritere testtilfeller.
• Forbered automatiserte skript for testtilfeller.

Testmiljø Oppsett

Testaktiviteter trenger visse miljøfaktorer-som servere, rammer, maskinvare og programvare—for å utføre utviklede testtilfeller. Programvare-og maskinvarekonfigurasjon, sammen med testdataoppsett, er hovedkomponentene i denne fasen. Og det er obligatorisk å røyke test og å utstyre testere med feilrapporteringsverktøy.

i utviklerfellesskapet er det vanlig å høre «det kjørte på systemet mitt, men det kjører ikke på ditt». Derfor er det viktig at testmiljøet dekker alle miljøer som brukeren vil bruke.

noen funksjoner som fungerer I Google Chrome, fungerer For Eksempel ikke I Internet Explorer. Arbeidet med funksjoner varierer også basert på programvare og maskinvarekrav. En funksjon kan fungere jevnt på 4 GB RAM, men kan skape problemer med 1 GB RAM. Forskning på miljøer som brukes av sluttbrukere, vil hjelpe deg med å prioritere testmiljøene dine.

det er jobben TIL QA-lederen som overvåker teamet for å ta vare på å sette opp testmiljøet.

for å oppsummere:

• Forstå minimumskravene
• List ned programvare og maskinvare som kreves for ulike ytelsesnivåer.
• Prioriter testmiljøer
• Oppsett testmiljøer
• Røyktest de bygde miljøene

Testutførelse

et program er klart for testing når laget er ferdig med alle tidligere faser. I henhold til testplanen utfører testerne testtilfeller. De identifiserer også, oppdager og logger feilene, og rapporterer dermed feilene. Teamet er også ansvarlig for å sammenligne forventede resultater med det virkelige resultatet. Hvis noen feil blir funnet, må de dokumenteres for å gi det videre til utviklingslaget for en løsning.

når utviklingsteamet fjerner en feil, begynner regresjonstesting. Regresjonstesting er å sikre at programvaren eller applikasjonen fungerer selv etter distribusjon av en endring. Når testing etter en bug fix, teste hele produktet på nytt. Fordi en løsning for en feil kan skape en feil på en annen del av produktet. Og fordi de samme testene må kjøres igjen og igjen etter hver reparasjon og distribusjon, anbefales det å bruke skript eller automatiserte testverktøy.

For å oppsummere:

• Kjør testtilfeller.
• Identifiser avvik fra forventet oppførsel av produktet.
• Logg mislykkede tilfeller med detaljer
• Test igjen etter feilrettinger.

Test Closure

Og det bringer oss til den siste fasen AV STLC: test closure.

slutten av testutførelsen og levering av sluttproduktet markerer starten på testens lukkefase. QA-teamet sjekker testresultatene og diskuterer dem med andre lagmedlemmer. Noen andre faktorer de vurderer er produktkvalitet, testdekning og prosjektkostnad. Hvis det er avvik fra estimerte verdier, kan det gjøres ytterligere analyser for å identifisere hva som ikke gikk som forventet.

det er en viktig praksis for testere å komme sammen og diskutere konklusjonen etter testing. Eventuelle problemer som står overfor under testing, kan feil i strategier diskuteres her. Du kan også arbeide med å komme opp med en bedre tilnærming for testing basert på erfaringene under testing. Hvis Du følger DevOps eller canary release praksis, er testing hyppig. Du kan bestemme hvor ofte du skal sende rapporter og hvilke detaljer du skal nevne når du sender rapporter til ulike interessenter.

Bortsett fra det, vurderer teamet også testmålinger, oppfyllelse av mål og overholdelse av tidsfrister. Når de har en total forståelse av hva som skjedde, kan de evaluere hele teststrategien og prosessen.

for å oppsummere:

• Kontroller at alle tester er fullført.
• Evaluer faktorer som kvalitet, testdekning, tidslinje og kostnad.
• Dokument konklusjonen.
• Diskuter læringen og finn ut om testprosessen kan forbedres.
• Forbered test lukkingsrapport.

Hva Er Inn-Og Utgangskriteriene for Testing?

alle seks faser av en programvaretestings livssyklus har inngangs – eller utgangskriterier knyttet til dem. Testere må fullføre utførelsen av testtilfellene innen en fast tid. De må også opprettholde kvaliteten, funksjonaliteten og effektiviteten til sluttproduktet. Derfor er det et must å definere inngangs-og utgangskriterier. Det er det vi skal gjøre nå.

Inngangskriterier

Inngangskriterier angir hvilke krav laget må ta seg av før testprosedyren starter. Før testing begynner, er det obligatorisk å krysse av alle krav.

det er noen pågående aktiviteter og forhold som må være tilstede før testingen begynner. Først trenger du innspill fra utviklingsteamet. Du vil også undersøke testplanen, testtilfeller og data, testmiljøet og koden din.

Avslutningskriterier

Avslutningskriterier angir kravene og handlingene som skal fullføres før testingen avsluttes. Med andre ord, de inkluderer elementer for å krysse av oppgavelisten og prosesser for å fullføre før testingen stopper.

Avslutningskriterier vil inkludere identifisering av feil med høy prioritet. Du må få dem løst med en gang. Testere må passere ulike testtilfeller og sikre full funksjonell dekning.

Konklusjon

bare å identifisere feil i den siste fasen AV EN SDLC er ikke en effektiv praksis lenger. Det finnes ulike andre daglige aktiviteter et firma har å fokusere på. Å bruke for mye av din dyrebare tid til å teste og fikse feil kan hemme effektiviteten. Tross alt, vil du ta mer tid til å generere mindre produksjon.

for å lette testprosessen er det viktig å utnytte tid og ressurser effektivt. Etter en systematisk STLC resulterer ikke bare i rask feilretting, men det forbedrer også produktkvaliteten. Ved å øke kundetilfredsheten får du ØKT ROI og forbedret merkevaretilstedeværelse.

dette innlegget ble skrevet Av Arnab Roy Chowdhury. Arnab er EN UI utvikler av yrke og en blogging entusiast. Han har sterk kompetanse i de nyeste UI / UX trender, prosjektmetoder, testing og skripting.

Hva skal du lese neste

Hva Er Shift Left Testing? En Guide Til Å Forbedre DIN QA