software test estimation techniques
For å lykkes med ethvert prosjekt, er testestimering og riktig utførelse like viktig som utviklingssyklusen. Å holde seg til estimeringen er veldig viktig for å bygge et godt omdømme hos klienten.
Erfaring spiller en viktig rolle i estimeringen av 'Software Testing Insats'. Å jobbe med varierte prosjekter hjelper til med å utarbeide en nøyaktig estimering av testsyklusen. Åpenbart kan man ikke bare blindt legge et antall dager for noen testoppgaver. Testestimering skal være realistisk og nøyaktig.
I denne artikkelen prøver jeg å sette noen punkter på en veldig enkel måte, som er nyttige for å utarbeide nøyaktig testestimering.
Hva du vil lære:
- Kort beskrivelse av testestimeringsprosessen
- Eksempler på testestimering
- 9 generelle tips om hvordan du estimerer testtiden nøyaktig
- Konklusjon
- Anbefalt lesing
Kort beskrivelse av testestimeringsprosessen
'Estimering er prosessen med å finne et estimat, eller tilnærming, som er en verdi som kan brukes til et eller annet formål, selv om inndata kan være ufullstendige, usikre eller ustabile.' [Referanse: Wikipedia ]
Vi kommer alle over forskjellige oppgaver og plikter og tidsfrister gjennom våre liv som fagpersoner, nå er det to tilnærminger for å finne en løsning på et problem.
En første tilnærming er en reaktiv tilnærming der vi prøver å finne en løsning på det aktuelle problemet først etter at det ankommer.
I den andre tilnærmingen som kan kalles en proaktiv tilnærming hvor vi først forbereder oss i god tid før problemet kommer med våre tidligere erfaringer og deretter med vår tidligere erfaring, prøver vi å finne en løsning på utfordringen når den kommer.
Estimering kan således betraktes som en teknikk som brukes når vi tar en proaktiv tilnærming til problemet.
Dermed kan estimering brukes til å forutsi hvor mye innsats med hensyn til tid og kostnader som kreves for å fullføre en definert oppgave.
Når testteamet er i stand til å gjøre et estimat av det aktuelle problemet, er det lettere for dem å komme opp med en løsning som vil være optimal for problemet.
Praksisen med estimering kan defineres da mer formelt som en omtrentlig beregning av den sannsynlige kostnaden for et stykke arbeid.
Les også=> 7 faktorer som påvirker testestimering av selen automatiseringsprosjekt
De grunnleggende forutsetningene for testestimeringsprosessen
# 1) Innsikt samlet fra arbeid med tidligere erfaring : Det er alltid en god praksis å bruke litt tid på å huske tidligere prosjekter som ga utfordringer som ligner på den nåværende innsatsen.
# 2) De tilgjengelige dokumentene eller gjenstandene: De verktøy for testadministrasjonsregister kommer inn hendig i denne typen scenarier da de lagrer krav og avklaringsdokumenter. Disse dokumentene kan henvises av testteamet for å tydelig definere omfanget av prosjektet.
# 3) Antakelser om type arbeid: Tidligere arbeidserfaring hjelper til med å gjøre antakelser om prosjektet. Det er her ansettelse av erfarne fagpersoner betyr mest.
Testledere kan plukke opp hjernen til disse menneskene for å levere de ønskede resultatene.
# 4) Beregning av potensielle risikoer og trusler: Testteamet må også visualisere potensielle risikoer og trusler og fallgruver som kan ligge for teamet i fremtiden.
# 5) Bestemme om dokumentene er basert på linjen: Testteamet må også avgjøre om kravene har vært utgangspunkt eller ikke. Hvis dokumentene ikke er i utgangspunktet, er det viktig å fastslå hyppigheten av endringene.
# 6) Alt ansvar og avhengighet bør være tydelig: Organisasjonen bør tydelig definere roller og ansvar for alle personene som vil utføre estimeringsprosessen.
# 7) Dokumentasjon og sporing av estimeringsposter: All relevant informasjon til estimeringsprosessen skal dokumenteres.
# 8) Aktiviteter som kreves utført under testestimeringsprosessen
- Organiser teamet som vil utføre estimeringer
- Nedbryt prosjektet i prosjektfaser og påfølgende grunnleggende aktiviteter
- Beregn estimeringen basert på tidligere prosjekter og profesjonell erfaring
- Prioriter mulige trusler og finn tilnærminger for å redusere risikoen
- Gjennomgå og dokumentere den aktuelle delen av arbeidet
- Send arbeidet til relevante interessenter
De mest fremtredende testestimeringsteknikkene
Noen av de viktigste teknikkene for testestimering er:
- Estimering av testpunkt
- Arbeidsfasebasert estimering
- Bruk estimering av sakspunkter
Hvordan og hvor vi bruker disse teknikkene:
# 1) Estimering av testpunkt er en enkel og lett forståelig estimeringsteknikk som brukes mye på tvers av programvaretestingsspekteret. Iterative faser og enkelhet er de viktigste egenskapene til denne spesielle teknikken.
automatisert testverktøy for webapplikasjoner
Nr. 2) Arbeidsfasebasert estimering er estimeringsteknikken som brukes der et gjetningsestimat blir laget på en bestemt fase (vanligvis den korteste og enkleste av fasene), og deretter legger testteamet gradvis til andre faser i den opprinnelige estimeringen og til slutt kommer opp med en passende estimering.
# 3) Beregningsteknikk for Use-Case Point er beregningen på brukstilfeller der den ujusterte aktørvekten og ikke-justerte bruksfallvekten brukes til å bestemme estimeringen av programvaretestingen.
Detaljer om teknikk for estimering av testpunkt
Testpunktestimeringsteknikken gjøres ved å følge de oppførte trinnene: -
(Følgende vekter som kan variere fra prosjekt til prosjekt, kan vurderes under dette paradigmet - Noen av disse vektene er vekten for programmeringsspråket basert på kompleksiteten i koden, applikasjonsvekten basert på applikasjonstypen og testvektene som er tildelt basert på de forskjellige fasene av programvaretesting.)
Ubehandlede testpunkter multipliseres med CWF for å oppnå teststørrelsen i testpunktets størrelse.
Produktivitetsfaktoren indikerer hvor lang tid en testingeniør har fullført testen av ett testpunkt
Testinnsats i persontimer beregnes ved å multiplisere testpunktstørrelsen med produktivitetsfaktoren.
For beregning av testpunktestimeringsteknikken vurderer vi følgende variabler.
- Testkravets kompleksitet
- Grensesnitt med andre krav
- Totalt antall bekreftelsespunkter
- Baseline testdata
Vi må da vurdere vektvektorer for hver av datavariablene og organisere dem på følgende måte.
Justeringsfaktor = Gjennomsnitt av (produkt av kompleksitetsvekt og faktorvekt) / 30
Justeringstestpunkt for testkassedesign = Totalt testpunkt X (1 + Justeringsfaktor for testkassedesign)
hva er testplan i qa
Justert testpunkt for utførelse av testtilfelle = totalt testpunkt X (1 + justeringsfaktor for utførelse av testsak)
Totalt testpunkt (normalisert) X (1 + Justeringsfaktor for testsakdesign / utførelse) = Justert testpunkt for testsakdesign / utføring
Total innsats i persontimer (PH) = antall normaliserte testpunkter / produktivitet (i normaliserte testpunkter per personstid)
Eksempler på testestimering
La oss prøve å bruke formuleringen ovenfor i en annen praktisk bruk.
Anta at vi ender med et testkrav der vi har 5 testscenarier å teste.
Si nå Testscenario 1 har 5 forventede testresultater, testscenario 2 6 test forventede resultater, testscenario 3 bare 2 test forventede resultater, testscenario 4 9 test forventede resultater, testscenario 5 også 9 test forventede resultater.
Så vi klassifiserer testscenariene i tre klasser, dvs. komplekse, enkle og moderate, basert på det totale antallet forventede resultater som er tilstede i disse tre klassene.
Komplekse klasser vil ha mer enn 7 forventede resultater, mens de enkle vil bestå av mindre enn 5 forventede resultater, og de moderate scenariene vil bestå av mellom 4 og 7 forventede resultater.
Vi klassifiserer dermed testscenario 1 og testscenario 2 som moderate scenarier, scenario 5 og scenario 6 som komplekse og testscenario 3 som enkle.
Vi vil nå bruke testpoeng på alle disse scenariene. Vi bruker 5 testpoeng for komplekse klasser, 3 for moderate og 2 for de enkle scenariene.
Vi multipliserer de antatte testpunktene med det totale antallet forventede resultater i alle disse testscenariene. Så vi ender opp med følgende tilnærminger.
Scenario 1: 3 testpunkter * 5 test forventede resultater = Justerte testpunkter = 25
Scenario 2: 3 testpunkter * 6 test forventede resultater = Justerte testpunkter = 30
Scenario 3: 2 testpunkter * 2 test forventede resultater = Justerte testpunkter = 4
Scenario 4: 5 testpunkter * 9 test forventede resultater = Justerte testpunkter = 45
Scenario 5: 5 testpunkter * 9 test forventede resultater = Justerte testpunkter = 45
Så med tanke på at vi må søke om å si 5 person timer for hvert justerte testpunkt, ender vi opp med å få følgende omtrentlige resultat.
Testscenario 1: 25 justerte testpunkter * 5 Personstimer = 125 Personstimer
Testscenario 2: 30 justerte testpunkter * 5 Personstimer = 150 Personstimer
Testscenario 3: 4 justerte testpunkter * 5 Personstimer = 20 Personstimer
Testscenario 4: 45 justerte testpunkter * 5 Personstimer = 225 Personstimer
Testscenario 5: 45 justerte testpunkter * 5 Personstimer = 225 Personstimer
Så totale tilnærmet antall timer er: 745 timer
Bruk metode for estimering av sakspunkt
Use-Case Point Method er basert på brukstilfellene der vi beregner den samlede testestimeringsinnsatsen basert på brukssakene eller kravene.
Her er den detaljerte prosessen med estimeringsmetoden Use case point:
Et eksempel på det samme er at i et bestemt krav sier vi at vi har henholdsvis 5 brukssaker, brukssak 1, brukssak 2, ..., brukssak 5. La oss nå vurdere at brukstilfelle 1 består av 6 aktører, brukstilfelle 2 består av 15 aktører, henholdsvis brukstilfeller 3, 4 og 5, 3, 4 og 5 aktører.
Vi anser ethvert brukstilfelle som involverer det totale antallet aktører som mindre enn 5 som negativt, ethvert brukstilfelle med det totale antallet aktører er lik eller mer enn 5 og mindre enn eller lik 10 som positivt og enhver brukssak med mer enn 10 skuespillere som eksepsjonelle.
Vi bestemmer oss for å tildele 2 poeng til de eksepsjonelle brukssakene, 1 til de positive og -1 for de negative.
Dermed kategoriserer vi brukssakene 1 og 5 som positive, brukstilfelle 2 som eksepsjonelle og brukstilfeller 3, 4 som negative henholdsvis basert på våre ovennevnte forutsetninger.
Så den ubehandlede skuespilleren vekter = Use case 1 = (totalt antall aktører) 5 * 1 (det tildelte punktet) = 5. Tilsvarende
Bruk tilfelle 2 = 15 * 2 = 30.
Gjentar prosessen for resten av brukssakene, mottar vi ubehandlede aktørvekter = 33
Ubehandlet brukstilbudsvekt = totalnr. av brukstilfeller = 5
Ubehandlet bruksfallspunkt = Ujustert aktørvekt + Ujustert brukssaksvekt = 33 + 5 = 38
Behandlet brukstilfellepunkt = 38 * [0,65+ (0,01 * 50] = 26,7 eller 28 person timer omtrent
Arbeidsfase sammenbruddsteknikk
Nedbrytningsteknikken for arbeidsfasen kan beskrives i de følgende trinnene.
- Del opp det samlede arbeidet i faser.
- Begynn med den enkleste fasen og tilordne en omtrentlig estimeringsverdi.
- Fortsett deretter med å identifisere neste mulige fase som kan påbegynnes når denne fasen er fullført.
- Utled et mulig sett med tilnærmingsverdier som kan brukes på denne fasen, og velg maksimumsverdien blant alle de avledede tilnærmingsverdiene.
- Oppsummere den tilnærmede estimeringsverdien ved å legge til den nåværende faseinnsats estimeringsverdien til den allerede eksisterende verdien.
- Fortsett trinn 3 til 5 til alle fasene som er identifisert i første trinn er oppbrukt.
- Godta den endelige omtrentlige estimeringsverdien som den ultimate.
Anta at i et krav er det 5 nødvendige faser. Så i den innledende fase 1 antar vi at den totale innsatsen som trengs er 35 arbeidstimer, og så begynner vi neste fase 2 som vi har fire komparative antagelser om henholdsvis 35, 45, 55 og 65.
Så vi vurderer 65 person-timer som er den maksimale verdien her. I fase 3, 4, 5 kommer vi med estimater (henholdsvis 12, 33, 43, 54), (15, 10, 7, 8) og (2, 16, 5, 13). Ved å anvende det nevnte prinsippet ender vi med henholdsvis 185 person timer.
Jeg legger informasjon om - Hvordan estimere testinnsats for en hvilken som helst testoppgave, som jeg lærte av min erfaring.
9 generelle tips om hvordan du estimerer testtiden nøyaktig
Faktorer som påvirker estimering av programvaretest og generelle tips for å estimere nøyaktig:
# 1) Tenk på litt buffertid
Beregningen bør inneholde noe buffer. Men ikke legg til en buffer, som ikke er realistisk. Å ha en buffer i beregningen gjør det mulig å takle eventuelle forsinkelser som kan oppstå. Å ha en buffer bidrar også til å sikre maksimal testdekning.
# 2) Tenk på bugsyklusen
Testestimasjonen inkluderer også bugsyklusen. Den faktiske testsyklusen kan ta flere dager enn beregnet. For å unngå dette, bør vi vurdere det faktum at testsyklusen avhenger av stabiliteten til bygningen. Hvis bygningen ikke er stabil, kan det hende at utviklere trenger mer tid på å fikse, og selvfølgelig utvides testsyklusen automatisk.
# 3) Tilgjengelighet av alle ressursene i estimert periode
Testestimatet bør ta hensyn til alle bladene som er planlagt av teammedlemmene (vanligvis lange løv) i løpet av de neste ukene eller de neste månedene. Dette vil sikre at estimatene er realistiske.
Estimasjonen bør ta hensyn til et fast antall ressurser for en testsyklus. Hvis antall ressurser reduseres, bør estimatet besøkes på nytt og oppdateres tilsvarende.
# 4) Kan vi gjøre paralleltesting?
Har du noen tidligere versjoner av det samme produktet slik at du kan sammenligne utdataene? Hvis ja, kan dette gjøre testoppgaven litt lettere. Du bør tenke på estimeringen basert på produktversjonen din.
# 5) Anslag kan gå galt - Så besøk estimatene ofte i de innledende trinnene før du begår det.
I de tidlige stadiene bør vi ofte besøke testestimatene på nytt og foreta en endring om nødvendig. Vi bør ikke utvide estimeringen når vi fryser den med mindre det er store endringer i kravene.
# 6) Tenk på din tidligere erfaring med å dømme!
Erfaringer fra tidligere prosjekter spiller en viktig rolle mens de utarbeider tidsestimater. Vi kan prøve å unngå alle vanskeligheter eller problemer som tidligere prosjekter sto overfor. Vi kan analysere hvordan de tidligere estimatene var og hvor mye de bidro til å levere produktet i tide.
# 7) Tenk på omfanget av prosjektet
Vet hva som er det endelige målet for prosjektet og listen over alle endelige resultater. Faktorer som skal vurderes for små og store prosjekter er forskjellige.
Det store prosjektet inkluderer vanligvis å sette opp en testbed, generere testdata, testskript osv. Derfor må estimatene baseres på alle disse faktorene. Mens det i små prosjekter vanligvis inkluderer testsyklus skriving, gjennomføring og regresjon.
# 8) Skal du utføre lastetesting?
Hvis du trenger å bruke betydelig tid på ytelsestesting, estimer deretter. Anslag for prosjekter, som involverer belastningstesting, bør vurderes annerledes.
hva er en .swf-fil
# 9) Kjenner du teamet ditt?
Hvis du kjenner styrkene og svakhetene til enkeltpersoner som jobber i teamet ditt, kan du estimere testoppgaver mer presist. Mens man estimerer, bør man vurdere det faktum at alle ressurser kanskje ikke gir det samme produktivitetsnivået. Noen mennesker kan utføre raskere sammenlignet med andre. Selv om dette ikke er en viktig faktor, legger det opp til den totale forsinkelsen i leveranser.
Konklusjon
Estimering av programvaretest er praksis som krever involvering av erfarne fagpersoner, samt innføring av bransjens beste praksis som test case point og bruker case point-metoder.
Det er også viktig for å ta i bruk et åpent sinn for å tilpasse de nødvendige prosessene. En vellykket implementering av disse prosessene fører til en total forbedring i testprosessen.
Dette er en gjesteartikkel av forfatteren “N. Sandhya Rani ”.
Anbefalt lesing
- Beste QA Software Testing Services fra SoftwareTestingHelp
- QA Outsourcing Guide: Software Testing Outsourcing Companies
- Alpha Testing og Beta Testing (En komplett guide)
- Perfekt programvaretest CV-guide (med programvaretester CV-prøve)
- Software Testing Jobs: En komplett guide til QA Testing Jobs
- Agile Estimation Techniques: En sann estimering i et smidig prosjekt
- 68 viktige ressurser for å være en vellykket tester (ikke gå glipp av det!)
- Typer programvaretesting: Ulike testtyper med detaljer