7 principles software testing
Syv prinsipper for programvaretesting: Inkludert flere detaljer om mangelklynging, Pareto-prinsipp og plantevernmiddelparadoks.
Jeg er sikker på at alle er klar over Syv prinsipper for programvaretesting ”.
Disse grunnleggende testprinsippene hjelper testteamene til å utnytte tid og krefter på å gjøre testprosessen effektiv. I denne artikkelen vil vi lære i detalj om to prinsipper, dvs. Feilklynging, Pareto-prinsipp og plantevernmiddelparadoks .
Hva du vil lære:
- Syv prinsipper for programvaretesting
Syv prinsipper for programvaretesting
Før vi får en grundig titt på disse to prinsippene, la oss kort forstå de syv prinsippene for programvaretesting.
La oss utforske !!
# 1) Testing viser tilstedeværelsen av feil
Hver applikasjon eller hvert produkt slippes ut i produksjon etter tilstrekkelig mengde testing av forskjellige team eller passerer gjennom forskjellige faser som systemintegrasjonstesting, brukertest og betatesting etc.
Så har du noen gang sett eller hørt fra noen av testteamet at de har testet programvaren fullt ut, og at det ikke er noen feil i programvaren ? I stedet for det bekrefter hvert testteam at programvaren oppfyller alle forretningskrav og at den fungerer i henhold til sluttbrukerens behov.
I programvaretestingsindustrien vil ingen si at det er det ingen feil i programvaren, noe som er ganske sant, ettersom testing ikke kan bevise at programvaren er feilfri eller feilfri.
Målet med testing er imidlertid å finne flere og flere skjulte feil ved hjelp av forskjellige teknikker og metoder. Testing kan avdekke uoppdagede feil, og hvis ingen feil blir funnet, betyr det ikke at programvaren er feilfri.
Eksempel 1 :
Vurder en banksøknad, denne applikasjonen er grundig testet og gjennomgår forskjellige faser av testing som SIT, UAT etc., og for øyeblikket er det ikke identifisert feil i systemet.
Imidlertid kan det være en mulighet for at den faktiske kunden i produksjonsmiljøet prøver en funksjonalitet som sjelden brukes i banksystemet, og testerne overså den funksjonaliteten, og det ble derfor ikke funnet noen feil til dags dato, eller koden har aldri blitt rørt av utviklere. .
Eksempel 2:
Vi har sett flere annonser for såper, tannkrem, håndvask eller desinfiserende spray osv. På TV.
Tenk på en håndvaskannonse som sier på fjernsynet at 99% bakterier kan fjernes hvis den spesifikke håndvask brukes. Dette viser tydelig at produktet ikke er 100% bakteriefritt. I testkonseptet vårt kan vi altså si at ingen programvare er feilfri.
# 2) Tidlig testing
Testere må involvere seg i et tidlig stadium av programvareutviklingens livssyklus (SDLC). Dermed kan feilene i løpet av kravanalysefasen eller eventuelle dokumentasjonsfeil identifiseres. Kostnadene ved å fikse slike feil er veldig mindre sammenlignet med de som er funnet i de senere stadiene av testingen.
Tenk på bildet nedenfor som viser hvordan kostnadene ved å fikse feil blir økt når testene beveger seg mot live produksjon.
[bilde kilde ]
Ovennevnte bilde viser at kostnadene som kreves for å fikse en feil som ble funnet under Kravsanalysen, er mindre, og de fortsetter å øke når vi beveger oss mot test- eller vedlikeholdsfasen.
Nå er spørsmålet hvor tidlig skal testingen starte ?
Når kravene er avsluttet, må testerne involvere for testing. Testing skal utføres på kravdokumenter, spesifikasjoner eller andre typer dokumenter, slik at hvis krav er feil definert, kan det løses umiddelbart i stedet for å fikse dem i utviklingsfasen.
# 3) Uttømmende testing er ikke mulig
Det er ikke mulig å teste alle funksjonene med alle gyldige og ugyldige kombinasjoner av inndata under faktisk testing. I stedet for denne tilnærmingen vurderes testing av noen få kombinasjoner basert på prioritering ved bruk av forskjellige teknikker.
Uttømmende testing vil ta ubegrenset innsats, og de fleste av disse anstrengelsene er ineffektive. Prosjektets tidslinjer tillater heller ikke testing av så mange antall kombinasjoner. Derfor anbefales det å teste inngangsdata ved hjelp av forskjellige metoder som ekvivalenspartisjonering og grenseverdianalyse.
For eksempel ,Hvis vi antar at vi har et inntastingsfelt som bare godtar alfabeter, spesialtegn og tall fra 0 til 1000. Tenk deg hvor mange kombinasjoner som vil vises for testing, det er ikke mulig å teste alle kombinasjoner for hver inngangstype.
Testinnsatsen som kreves for å teste vil være enorm, og det vil også påvirke prosjektets tidslinje og kostnad. Derfor sies det alltid at uttømmende testing praktisk talt ikke er mulig.
# 4) Testing er kontekstavhengig
Det er flere domener tilgjengelig i markedet som bank, forsikring, medisinsk, reise, reklame osv., Og hvert domene har en rekke applikasjoner. Også for hvert domene har applikasjonene forskjellige krav, funksjoner, forskjellige testformål, risiko, teknikker etc.
Ulike domener testes forskjellig, og dermed er testing utelukkende basert på domenet eller applikasjonens kontekst.
For eksempel ,å teste en banksøknad er annerledes enn å teste noen e-handel eller annonseringsapplikasjon. Risikoen forbundet med hver type applikasjon er forskjellig, og det er derfor ikke effektivt å bruke samme metode, teknikk og testtype for å teste alle typer applikasjoner.
# 5) Feilklynging
Under testing kan det hende at de fleste feilene som er funnet er relatert til et lite antall moduler. Det kan være flere grunner til dette, ettersom modulene kan være kompliserte, koding relatert til slike moduler kan være komplisert etc.
Dette er Pareto-prinsippet for programvaretesting der 80% av problemene finnes i 20% av modulene. Vi vil lære mer om defektklynging og Pareto-prinsipp senere i denne artikkelen.
# 6) Pesticidparadoks
Pesticide Paradox-prinsippet sier at hvis det samme settet med testtilfeller blir utført gang på gang i løpet av tidsperioden, er ikke disse settene med tester i stand til å identifisere nye feil i systemet.
For å overvinne dette 'plantevernmidlet paradoks', må settet med testtilfeller gjennomgås regelmessig og revideres. Om nødvendig kan et nytt sett med testtilfeller legges til og eksisterende testtilfeller kan slettes hvis de ikke er i stand til å finne flere feil fra systemet.
# 7) Fravær av feil
Hvis programvaren er testet fullstendig, og hvis ingen feil blir funnet før utgivelsen, kan vi si at programvaren er 99% feilfri. Men hva om denne programvaren blir testet mot gale krav? I slike tilfeller vil ikke til og med å finne feil og fikse dem i tide ikke hjelpe, siden testing utføres på feil krav som ikke er i samsvar med sluttbrukerens behov.
For eksempel, anta at applikasjonen er relatert til et e-handelsnettsted og kravene til 'Handlekurv eller handlekurv' -funksjonalitet som blir tolket og testet feil. Her hjelper ikke å finne flere feil å flytte applikasjonen til neste fase eller i produksjonsmiljøet.
Dette er de syv prinsippene for programvaretesting.
La oss nå utforske Defektklynging, Pareto-prinsipp og plantevernmiddelparadoks i detalj .
Feilklynging
Mens testingen av hvilken som helst programvare kommer testerne for det meste over en situasjon der de fleste feilene som er funnet er relatert til noen spesifikk funksjonalitet, og resten av funksjonene vil ha et lavere antall feil.
Feilklynging betyr et lite antall moduler som inneholder de fleste feilene. I utgangspunktet er manglene ikke fordelt jevnt over hele applikasjonen, men defekter er konsentrert eller sentralisert over to eller tre funksjoner.
Noen ganger er det mulig på grunn av applikasjonens kompleksitet, koding kan være kompleks eller vanskelig, en utvikler kan gjøre en feil som bare kan påvirke en bestemt funksjonalitet eller modul.
Feilklynging er basert på “ Pareto-prinsippet ”Som også er kjent som 80-20 regel . Det betyr at 80% av feilene som er funnet skyldes 20% av modulene i applikasjonen. Konseptet med Pareto Principle ble opprinnelig definert av en italiensk økonom – Vilfrodo Pareto .
Hvis testere ser på 100 feil, vil det ikke være klart om det er noen underliggende betydning mot de 100 feilene. Men hvis disse 100 feilene er kategorisert på noen spesifikke kriterier, kan det være mulig for testerne å forstå at et stort antall feil bare tilhører noen få spesifikke moduler.
For eksempel ,la oss se på bildet nedenfor som er testet for en av banksøknadene, og det viser at de fleste av manglene er relatert til funksjonen 'Overdraft'. Resten av funksjonene som kontosammendrag, pengeoverføring, stående instruksjon etc. har begrenset antall feil.
[bilde kilde ]
Ovennevnte bilde sier at det er 18 feil rundt Overdraft-funksjonaliteten av de totale 32 defektene, noe som betyr at 60% av manglene er funnet i 'Overdraft' -modulen.
Derfor konsentrerer testere seg mest om dette området under utførelse for å finne flere og flere feil. Det anbefales at testerne skal ha et lignende fokus på de andre modulene også under testingen.
Når en og samme kode eller modul blir testet, igjen og igjen, ved hjelp av et sett med testtilfeller enn under de første iterasjonene, er antallet mangler høyt, men etter en del iterasjon vil antall teller betydelig reduseres. Feilklynging indikerer at det defekte utsatte området skal testes grundig under regresjonstesting.
Pesticidparadoks
Når en av modulene viser seg å ha flere feil, legger testerne ytterligere anstrengelser for å teste den modulen.
Etter noen få iterasjoner av test blir kvaliteten på koden forbedret, og mangeltellingen begynner å synke, ettersom de fleste feilene er løst av utviklingsteamet, siden utviklerne også er forsiktige mens de koder en bestemt modul der testerne fant flere feil.
Derfor blir de fleste feilene på et tidspunkt oppdaget og løst slik at ingen nye feil blir funnet i den modulen.
Noen ganger kan det imidlertid skje at mens du er ekstra forsiktig under koding på en bestemt modul (her i vårt tilfelle ' Overtræk ”-Modulen), kan utvikleren forsømme de andre modulene for å kode den riktig, eller endringene som er gjort i den aktuelle modulen, kan ha en negativ innvirkning på andre funksjoner som kontosammendrag, pengeoverføring og stående instruksjoner.
Når testerne bruker det samme settet med testtilfeller for å utføre modulen der de fleste feilene blir funnet (Overdraft-modul), er testtilfellene ikke så effektive for å finne nye feil etter å ha løst disse manglene av utviklerne. Som end-to-end-flyt av Overdraft blir modulen testet grundig, og utviklerne har også skrevet koden for den modulen forsiktig.
Det er nødvendig å revidere og oppdatere disse testtilfellene. Det er også en god ide å legge til nye testtilfeller slik at nye og flere mangler kan bli funnet i forskjellige områder av programvare eller applikasjon.
Forebyggende metoder for plantevernmiddel paradoks
Det er to alternativer som vi kan forhindre Pesticide Paradox som vist nedenfor:
til) Skriv et nytt sett med testtilfeller som vil fokusere på forskjellige områder eller moduler (annet enn tidligere defekt utsatt modul - Eksempel: “Overdraft”) av programvaren.
b) Forbered nye testtilfeller og legg til eksisterende testtilfeller.
I “ metode A ”, Kan testere finne flere feil i de andre modulene der de ikke var fokusert under den tidligere testen, eller utviklerne ikke var ekstra forsiktige under kodingen.
I eksemplet vårt ovenfor kan testere finne flere feil i modulene Kontosammendrag, Overføring av penger eller Stående instruksjoner ved hjelp av det nye settet med testtilfeller.
Men det kan hende at testerne kan forsømme den tidligere modulen ( Eksempel: “Overdraft”) der de fleste feilene ble funnet i den tidligere iterasjonen, og dette kan være en risiko ettersom denne modulen (Overdraft) kan ha blitt injisert med de nye feilene etter koding av de andre modulene.
I “ metode B ”, Nye testtilfeller blir utarbeidet slik at nye potensielle mangler kan bli funnet i resten av modulene.
Her i vårt eksempel vil nyopprettede testtilfeller kunne hjelpe til med å identifisere mangler i modulene som Kontosammendrag, Overføring av penger og Stående instruksjon. Imidlertid kan testere ikke ignorere de tidligere defekte utsatte modulene ( Eksempel: “Overtræk”) ettersom disse nye testtilfellene blir slått sammen med eksisterende testtilfeller.
De eksisterende testsakene var mer fokusert på “Overdraft” -modulen og de nye testsakene var fokusert på de andre modulene. Derfor blir alle sett med testtilfeller utført minst en gang til og med en kodeendring skjer på en hvilken som helst modul. Dette vil sikre at riktig regresjon blir utført, og feilen kan identifiseres på grunn av denne kodeendringen.
Ved å bruke den andre tilnærmingen, går det totale antallet tester betydelig høyt og resulterer i mer innsats og tid som kreves for utførelse. Dette vil åpenbart påvirke prosjektets tidslinjer og viktigst av alt også prosjektbudsjettet.
Derfor, for å løse dette problemet, kan de overflødige testtilfellene bli gjennomgått og deretter fjernet. Det er mange testsaker som blir ubrukelige etter å ha lagt til nye testsaker og endret eksisterende testsaker.
Det er nødvendig å sjekke hvilke testsaker som mislykkes for å identifisere manglene i de siste 5 iterasjonene (la oss anta 5 iterasjoner) og hvilke testsaker som ikke er så viktige. Det kan også være slik at enkeltstrømmen dekket i noen få testtilfeller kan dekkes i en annen ende til slutt-testtilfeller, og de testtilfellene som har enkeltstrøm kan fjernes.
Dette vil igjen redusere det totale antallet testsaker.
For eksempel ,Vi har 50 testtilfeller for å dekke en bestemt modul, og vi har sett at av disse 50 testtilfellene mislyktes 20 testtilfeller i å oppdage en ny defekt i løpet av de siste få iterasjonene (la oss anta 5 iterasjoner). Så disse 20 testsakene må gjennomgås grundig, og vi må sjekke hvor viktige disse testtilfellene er, og det kan tas en beslutning om vi skal beholde de 20 testsakene eller fjerne dem.
Før du fjerner en testtilfelle, må du kontrollere at funksjonalitetsflyten dekket i disse testtilfellene er dekket i en annen testtilfelle. Denne prosessen må følges på tvers av alle modulene, slik at det totale antallet tester av prøver blir betydelig redusert. Dette vil sikre at det totale antallet tester blir redusert, men det er fortsatt 100% kravdekning.
Det betyr at alle de gjenværende testsakene dekker alle forretningskravene, og det er derfor ikke noe kompromiss med kvaliteten.
Konklusjon
Programvaretesting er et viktig skritt i SDLC, da det verifiserer om programvaren fungerer som den endelige brukeren trenger eller ikke.
Testing identifiserer så mye feil som mulig. Derfor, for å utføre testing effektivt og effektivt, bør alle være klar over og faktisk forstå de syv prinsippene for programvaretesting tydelig, og de er kjent som pilarene for testing.
De fleste testere har implementert og opplevd disse prinsippene under faktisk testing.
programvare skrevet i c ++
Generelt betyr begrepet prinsipp reglene eller lovene som må følges. Derfor må alle i programvaretestindustrien følge disse syv prinsippene, og hvis noen ignorerer noen av disse prinsippene, kan det koste enormt for prosjektet.
Glad lesning !!
Anbefalt lesing
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Programvaretesting QA Assistant Job
- Programvare Testing Course: Hvilket programvare Testing Institute skal jeg delta?
- Velge programvaretesting som din karriere
- Programvaretesting Teknisk innhold Writer Freelancer Jobb
- Hva er feilbasert testteknikk?
- Noen interessante intervjusspørsmål om programvaretesting
- Programvaretestkurs Tilbakemelding og anmeldelser