Meny

Hvordan utføre programvaretesting - Detaljerte prosesser og metoder med eksempler

how perform software product testing detailed process

Prøv Instrumentet Vårt For Å Eliminere Problemer

Programvareprodukter trenger sin egen unike tilnærming for å teste tilstrekkelig og riktig. Ofte behandler team dem som hvilken som helst annen programvare (dvs. interne applikasjoner bygget for en bestemt klient eller et team; ikke tilgjengelig for allmennheten; ikke-inntektsgenererende), og det er utgangspunktet for problemer.

Testing av programvareprodukter trenger en tilpasset teststil og strategi for å tilføre verdi. Programvare Produktutvikling og næring er i seg selv et komplekst økosystem og for å trives må testere tilpasse seg.

La meg ta et øyeblikk for å forklare hvorfor det er viktig, og hvorfor jeg synes produktutvikling er kompleks, komplisert og sammensatt, selv i de beste tider.

Hvordan produkttesting

Hva du vil lære:

Programvareutviklingsutfordringer:

Her er noen av utfordringene som programvareproduktutviklingsteam står overfor:

#1)Mangel på kontroll over brukerdemografi, enheter, miljøer, plattformer osv. : Programvareprodukter i motsetning til programvare som er laget for bestemte interessenter, brukes ikke i kontrollerte og forutsigbare situasjoner. Det er mange bare for mange faktorer å ta hensyn til.

#to)Tåkete produktvisjon : Produktatferd og funksjoner endres for alltid, og reisen til modenhet er ikke tydelig synlig. Eller produktet vokser for raskt til at det går ut av kontroll at team ikke vet hva som skjer.

# 3)Aggressive tidslinjer : På grunn av sterk konkurranse i programvareproduktmarkedet, må ting bevege seg i en utrolig fart, og lagene må ligge et skritt foran sine jevnaldrende. Ellers taper de sikkert konkurransen.

# 4)Frykt for å mislykkes : Programvareprodukter er vanligvis innovative. Så deres suksess er ikke alltid gitt. Dette er grunnen til at bedrifter ikke kan gå helt ut når det gjelder budsjett, teknologi, infrastruktur, etc. De må ofte holde tilbake for å få en viss immunitet mot svikt eller til og med brudd.

# 5)Mangel på tilbakemeldinger: Siden det ikke er noen interessenter eller forretningsbrukere eller klienter, er det vanskelig å forstå hva sluttbrukeren kan eller ikke liker. Bedrifter spiller hele tiden et gjetningsspill og har ofte problemer med å bygge bro over gapet mellom det de ønsker for programvaren og det kunden ønsker.

Disse utfordringene påvirker alle områder av produktutvikling, markedsføring og næring - Og de påvirker iboende produkttesting også.

For å komme videre i spillet må denne typen testing ta fem viktige punkter i betraktning:

  • Hastighet på utvikling og utgivelser
  • Kortsiktige og langsiktige produktmål for produktet
  • Konkurransens omfang og art
  • Målgrupper og deres omgivelser
  • Krav - Funksjonell, ytelse, sikkerhet, brukervennlighet, konfigurasjon, etc.

La oss forstå produktets livssyklus (dette er en generisk livssyklus og ikke spesifikk for programvareprodukter, men programvare følger et lignende mønster) før vi går nærmere inn på dette:

produktets livssyklus

En god produktteststrategi / -tilnærming bør ta hensyn til den nåværende fasen av produktet i livssyklusen.

Les også => Hvordan skrive et godt teststrategidokument

Eksempel: Et selskap XYZs produkt er en programvare for mangelfølgning kalt 'TrackFast'. Det er et nytt produkt, og den første versjonen skal lanseres som en sky og lokal løsning. TrackFast fungerer som alle andre feilhåndteringssystemer og er bygget for både mobil og internettilgang. Foreløpig er det 2 til 4 ukers sprints der produktet blir opprettet i deler. Du er på testteamet og tester ‘TrackFast’ før det møter kundene. Testingen innebærer å sjekke funksjonalitet, ytelse og sikkerhet.

hvordan du skriver en programvaretestplan

For å oppsummere, dette er parametrene du jobber med. Eller hvis du foretrekker det, er dette din sammenheng

parametrene

La oss se hvordan vi kan teste på hvert trinn. Dette er produkttest prosess, metode eller livssyklus på hvert trinn.

Trinn 1) Produktinnføring

Siden dette er første gang TrackFast skulle ut i markedet, er ideen å gjøre et godt førsteinntrykk. Så la ingen stein være urørt. Test alt og fra alle vinkler. I tillegg til det, legg grunnlaget for fremtidig testing.

En god teststrategi på dette punktet bør inneholde følgende:

  • Tester som validerer kortsiktige mål for TrackFast. “Hva trenger den for å bli sendt riktig” bør være i forkant av testinnsatsen. Skape End to end tests (frontend, mellomvare og backend) for grundig testing av alle funksjoner
  • Tester som sammenligner TrackFast med konkurrentene (ideelt sett er dette jobben til produkteiere, men som tester kan vi legge til våre to øre. Dessuten er dette trinnet lettere hvis programvaren allerede har noen jevnaldrende. For eksempel: Det er enkelt å sammenligne TrackFast med Bugzilla eller JIRA eller andre eldre systemer . Men la oss si at jeg lager en app som gjør noe uvanlig som å kunne forutsi når en baby er sulten eller cranky :), det kan være vanskelig å finne et program som du kan bruke som en grunnlinje)
  • Plattform, nettleser og enhet kompatibilitetstester
  • Tester for enkel installasjon , sette opp og få fart på
  • Tester for ytelse, sikkerhet og brukervennlighet
  • Integrasjonstester hvis det grensesnitt med andre systemer. Et enkelt integrasjonseksempel er at system for defektsporing ofte kommuniserer med e-postklienter for å sende varsler
  • Plan for regresjon - Det er en god ide å markere eller merke kritiske tester som du tror vil være en del av fremtidige regresjonssykluser og tenke på å automatisere dem for fremtidige utgivelser
  • Planlegg for kjente problemer (skal du legge dem til i etterslaget eller håndtere dem som CR-er osv.)
  • Fleksibilitet for å endres når produktet går videre til neste livssyklusstadium.

Noen ganger kan det ta lang ventetid før produktet går ut, så bruk all den tiden du har til å gjøre en så grundig jobb som mulig.

I dette stadiet, selv om det er en del av produktet klart på slutten av 2-4 ukers sprint, resulterer oftest ikke hver sprint i sendt kode. Derfor må du aldri vurdere siste sprint testing som 'gjort og levert'. Gjenta kritiske tester med hver sprint til løslatelse. For hver sprint, test hele produktet du har til det punktet.

Trinn 2) Produktvekst

Etter den første prosjektintroduksjonen, hvis alt går bra, kan du forvente en tilstrømning av aktivitet fordi produktvekst er en fartsfylt bane. Du svømmer nå sammen med de store haiene, og med mindre du holder følge, blir du sliten.

Her blir utgivelsene kortere, forbedringene av programvaren blir flere og omfanget av regresjon blir nesten ikke håndterlig.

Produkttestingsstrategien skal fungere i det tempoet som programvareutviklingen fortsetter og bør ikke bli en flaskehals.

Disse kan hjelpe:

  • Husk prosjektets langsiktige mål. Det handler ikke om å få det over nå. Det handler om å leve med funksjonene og trives med dem.
  • Test tidlig- Vurder TDD eller BDD i stedet for å utsette testing til slutt med nye krav
  • Automatiser regresjon og styrke den - Lag en automatisert regresjonspakke på plass slik at du ikke sitter igjen med uprøvde landminer i systemet ditt
  • Hvis bedriftens / produkteierne dine vil involvere deg i testing, bør du vurdere et virksomhetsspråkbasert automatiseringsverktøy som agurk.
  • Behold brukervennligheten og nettstedsdesign sentralt i testingen. Fordi jo flere funksjoner vi legger til, desto renere bør nettstedet se ut
  • Utfør ytelse og sikkerhetstesting når en større utgivelse har skjedd, eller hvis det er gjort en betydelig endring i arkitekturen. (Ny server hentet osv.) De fleste programvaresystemer trenger ikke dette med hver utgivelse.
  • Hold kontakten med konkurransen og kjenn produktvisjonen
  • Tilpass paretesting , for umiddelbar tilbakemelding og reparasjon. Inkluder produkteieren når det er mulig
  • Planlegg for endringer og kjente problemer
  • Prøv å få tak i tilbakemeldinger fra kunder og sjekk om de er, kan spores som forbedringsforslag for å holde veksten konstant. (nok en gang, dette er ikke hovedansvaret til QA-teamet, men alle teller)

Fase 3) Produktmodning

Gratulerer med at produktet ditt har kommet så langt. På dette punktet endres ikke funksjonene så ofte. Produktteamet vil være mer fokusert på å bringe mer virksomhet eller deres markedsføringsarbeid. Produktutvikling og testing trenger imidlertid ikke og ofte ikke stoppe.

Derfor kan testteamet:

  • Arbeid med å modne teststrategien din. På dette tidspunktet må regresjonspakker, testdesignmetoder og testadministrasjonspraksis fungere som veloljede maskiner.
  • Fokuser på de finere detaljene. For generelt fungerer produktet og gjør det bra, men som de sier - ‘ Gud er i detaljene ’ - finn til og med de minste av problemene som kan forbedre kvaliteten på systemet
  • Vurder tilbakemeldinger fra kunder
  • Test ytelse og sikkerhet med jevne mellomrom
  • Ta hensyn til de nye enhetene, plattformene og nettleserne som kan ha kommet i markedet sist du testet
  • Test brukerhåndboken og ofte stilte spørsmål siden du nå har tid og du har råd til.
  • Eksperimenter med nye produkttestverktøy, tjenester eller en prosess, for nå kan du.
  • Test installasjonsprosessen med hver utgivelse, uansett hvor liten den måtte være, og få statistikk over hvor enkelt eller vanskelig det er for sluttbrukeren.

Uansett hva du gjør, ikke bli selvtilfreds.

gratis tidsklokke programvare for pc

Trinn 4) Produktnedgang / sirkling tilbake til produktvekst

Produkteierne og bedriftene er smarte i disse dager og vet godt at de ikke kan holde produktet det samme og forventer at brukerne skal være lojale. Ting beveger seg for fort, og det samme gjør produkter.

Så TrackFast kan ikke lene seg tilbake og slappe av. Hvis den trenger å ha en fortsatt tilstedeværelse på markedet og være leder, må den utvikle seg. Liker det eller hater det, Facebook startet som et enkelt sosialt nettverk for å koble mennesker sammen, og det er en stor programvareplattform i seg selv som integreres med en million andre ting og holder seg oppdatert.

TrackFast må også utvikle seg. Etter å ha bevist at det er et pålitelig og effektivt feilsporingssystem, må det utvikle seg ellers vil det avta. Så, selskapet XYZ bestemmer seg for å forbedre TrackFast ved å gjøre det til et generelt billettsystem som kan brukes til å spore eventuelle hendelser eller saker fra virksomheten annet enn IT / testteam (noe som JIRA) og ikke bare for mangler i programvareutviklingsprosessen. .

Hjulet har gjort en hel sving, og du behandler systemet som et helt nytt og følger strategien vi diskuterte i delen Produktintroduksjon. Først nå er du mer erfaren og kjent med øvelsen. Men husk, med hver nye sving kommer en ny utfordring. Så vær skarp :)

Hva gjør deg til en vellykket produkttester?

  • Produkttestere må ha en god forretningsforståelse, forståelse for raske leveringsutviklingsmodeller og bør være essetestere som ikke er redde for å eksperimentere med verktøy og bli litt kodere selv om det er nødvendig. Disse tingene kan ha en positiv innvirkning på alle typer tester, men de er en absolutt nødvendighet i denne typen tester.
  • En annen viktig egenskap er at en produkttester må tro på produktet og vil virkelig at det skal lykkes. Når jeg som tester tenker at programvaren er total søppel, er det lite håp om at jeg vil gjøre noe for å gjøre det bedre.
  • Del produkt / bedriftseiers visjon . Med mindre du vet hvor produktet skal og hvordan det skal utvikle seg, vil testingen være superbegrenset.
  • Tverrfunksjonelle ferdigheter er fordelaktige - Vite hvordan du tester DB, hvordan du tar ytelsesverdier, hvordan du aktiverer sikkerhetssertifikater, hvordan du distribuerer osv. Vær nysgjerrig og utforsk .
  • Sett ingen grenser - ikke tro at det å evaluere brukerhåndboken eller sjekke vanlige spørsmål ikke er din jobb, og en teknisk forfatter bør ta seg av den. Vel, de burde og de vil. Men når du ser på det som en innside som en som kjenner produktet ut og inn, er tilbakemeldingene dine veldig nyttige.
  • Søk tilbakemeldinger fra sluttbrukere. Det neste store settet med mennesker som tester etter deg er brukere i sanntid. Vet og forstå hva slags problemer de står overfor. Dette hjelper deg med å forbedre testdesignet ditt, så neste gang du vet hva du skal gjøre for å unngå disse problemene.
  • Arbeid raskt og vær en beslutningstaker
  • Unngå teknisk gjeld . I en rask utviklings- og testsituasjon er det enkelt å teste utforskende eksklusivt og miste referanserammen for fremtidige utgivelser. Ikke la dette skje. Vedlikehold skjelettdokumentasjon slik at du kan spore, spore og måle

Den største forskjellen mellom testprogramvare bygget som en tjeneste og programvare bygget som et produkt er at - i den første, når teststrategien er nådd, blir den brukt på alle påfølgende tester.

For et produkt må teststrategien imidlertid endres avhengig av den nåværende livssyklusfasen produktet er i og endringene i markedsdynamikken (nye enheter, nye nettlesere osv.). Produkttestingsstrategi må være mye mer fleksibel for å endres.

Om forfatteren: Denne artikkelen er publisert av STH-teammedlem Swati S.

Vi håper denne artikkelen har vært nyttig. Du kan gjerne legge inn kommentarer, spørsmål og tilbakemeldinger nedenfor.

Anbefalt lesing

^