Hva er programvaretestmetodikk?
Testmetodikk for programvare er definert som strategier og testtyper som brukes for å bekrefte at applikasjonen under test oppfyller kundens forventninger. Testmetodikk inkluderer funksjonell og ikke-funksjonell testing for å validere AUT. Eksempler på testmetoder er Unit Testing, Integration Testing, System Testing, Performance Testing etc. Hver testmetodikk har et definert testmål, teststrategi og leveranser.
Merk : Siden programvaretesting er en integrert del av en hvilken som helst utviklingsmetode, bruker mange selskaper begrepet utviklingsmetoder og testmetoder daglig. Derfor kan testmetoder også referere til fossefall, smidig og andre QA-modeller i motsetning til definisjonen ovenfor av testmetoder. Diskusjon om forskjellige testtyper tilfører ikke leserne verdi. Derfor vil vi diskutere de forskjellige utviklingsmodellene.
I denne veiledningen vil du lære-
- Fossmodell
- Iterativ utvikling
- Agil metodikk
- Ekstrem programmering
- Hvilken programvaremetode å velge?
- Hvordan setter du opp testmetoder for programvare
Fossmodell
Hva er det?
I fossemodellen utvikler programvareutvikling seg gjennom forskjellige faser som kravanalyse, design osv. - sekvensielt .
I denne modellen begynner neste fase bare når den tidligere fasen er fullført.
Hva er testmetoden?
Den første fasen i fossemodellen er kravfasen der alle prosjektkravene er fullstendig definert før testingen startes. I løpet av denne fasen brainstormer testteamet omfanget av testing, teststrategi og utarbeider en detaljert testplan.
Først når utformingen av programvaren er fullført, vil teamet gå videre til gjennomføring av testsakene for å sikre at den utviklede programvaren oppfører seg som forventet.
I denne metoden fortsetter testteamet til neste fase bare når den forrige fasen er fullført.
Fordeler
Denne programvareingeniørmodellen er veldig enkel å planlegge og administrere. Derfor kan prosjekter, der kravene er klart definert og angitt på forhånd, enkelt testes ved hjelp av en fossemodell.
Ulemper
I fossemodellen kan du bare begynne med neste fase når den forrige fasen er fullført. Derfor kan denne modellen ikke imøtekomme ikke-planlagte hendelser og usikkerhet.
Denne metoden er ikke egnet for prosjekter der kravene endres ofte.
Iterativ utvikling
Hva er det?
I denne modellen er et stort prosjekt delt inn i små deler, og hver del er utsatt for flere iterasjoner av fossemodellen. På slutten av en iterasjon utvikles en ny modul eller en eksisterende modul forbedres. Denne modulen er integrert i programvarearkitekturen, og hele systemet testes alt sammen
Hva er testmetoden?
Så snart iterasjonen er fullført, blir hele systemet testet. Tilbakemelding fra testing er umiddelbart tilgjengelig og er innlemmet i neste syklus. Testtiden som kreves i påfølgende iterasjon kan reduseres basert på erfaringene fra tidligere iterasjoner.
Fordeler
Den viktigste fordelen med iterativ utvikling er at tilbakemeldingen fra testen er tilgjengelig umiddelbart på slutten av hver syklus.
Ulemper
Denne modellen øker kommunikasjonsomkostningene betydelig, siden det må gis tilbakemelding om leveranser, innsats osv. På slutten av hver syklus.
Agil metodikk
Hva er det?
Tradisjonelle programvareutviklingsmetoder jobber med forutsetningen om at programvarekrav forblir konstante gjennom hele prosjektet. Men med en økning i kompleksiteten gjennomgår kravene mange endringer og utvikler seg kontinuerlig. Noen ganger er kunden selv ikke sikker på hva han vil ha. Selv om den iterative modellen løser dette problemet, er den fortsatt basert på fossemodellen.
I Agile metodikk er programvare utviklet i trinnvise, raske sykluser. Interaksjoner mellom kunder, utviklere og klienter blir vektlagt i stedet for prosesser og verktøy. Den smidige metodikken fokuserer på å reagere på endring i stedet for omfattende planlegging.
Hva er testmetoden?
Inkrementell testing brukes i smidige utviklingsmetoder, og derfor blir hver utgivelse av prosjektet testet grundig. Dette sikrer at eventuelle feil i systemet blir løst før neste utgivelse.
Fordeler
Det er mulig å gjøre endringer i prosjektet når som helst for å oppfylle kravene.
Denne trinnvise testen minimerer risikoen.
Ulemper
Konstant klientinteraksjon betyr ekstra tidspress på alle interessenter, inkludert klienten selv, programvareutvikling og testteam.
Ekstrem programmering
Hva er det?
Ekstrem programmering er en type smidig metodikk som tror på korte utviklingssykluser. Et prosjekt er delt inn i enkle ingeniøroppgaver. Programmører koder et enkelt programvare og kommer tilbake til kunden for tilbakemelding. Gjennomgangspunkter fra kunden er innarbeidet, og utviklerne fortsetter med neste oppgave.
I ekstreme programmeringsutviklere jobber du vanligvis parvis.
Ekstrem programmering brukes på steder der kundenes behov endres kontinuerlig.
Hva er testmetoden?
Ekstrem programmering følger en testdrevet utvikling som er beskrevet som følger -
- Legg til en testsak i testpakken for å verifisere den nye funksjonaliteten som ennå ikke er utviklet
- Kjør alle testene, og den nye testtilfellet som legges til må åpenbart mislykkes siden funksjonaliteten ikke er kodet ennå
- Skriv litt kode for å implementere funksjonen / funksjonaliteten
- Kjør testpakken igjen. Denne gangen skal den nye testsaken passere siden funksjonen er kodet
Fordeler
Kunder som har et vagt programvaredesign i tankene, kan bruke ekstrem programmering
Kontinuerlig testing og kontinuerlig integrering av små utgivelser sørger for at programvarekoden leveres er av høy kvalitet
Ulemper
Møter mellom programvareutviklingsteamet og klienter øker tidskravene.
Hvilken programvaremetode å velge?
Det er mange tilgjengelige metoder for programvareutvikling og tilhørende testing. Hver testteknikk og metodikk er designet for et bestemt formål og har sine relative fordeler og ulemper.
Valg av en bestemt metode avhenger av mange faktorer, for eksempel prosjektets art, klientkrav, prosjektplan etc.
Fra et testperspektiv presser noen metoder på for å teste input tidlig i utviklingssyklusen, mens andre venter til en arbeidsmodell av systemet er klar.
Hvordan setter du opp testmetoder for programvare
Metodologitestmetoder bør ikke settes opp bare for å teste programvarekode. Det store bildet bør vurderes, og hovedmålet for prosjektet skal være tilfreds med testmetoden.
Planlegging
Realistisk planlegging er nøkkelen til implementering av vellykket testmetodikk, og tidsplanen skal oppfylle behovene til hvert medlem av teamet.
Definerte leveranser
For å holde alle medlemmene i teamet på samme side, bør det gis veldefinerte leveranser. Leveringene skal inneholde direkte innhold uten tvetydighet.
Test tilnærming
Når planleggingen er fullført og definerte leveranser er gjort tilgjengelig, bør testteamet kunne formulere riktig testtilnærming. Definisjonsdokumenter og utviklermøter bør indikere teamet om den beste testtilnærmingen som kan brukes til prosjektet.
Rapportering
Transparent rapportering er veldig vanskelig å oppnå, men dette trinnet bestemmer effektiviteten av testmetoden som brukes i prosjektet.