for å lykkes med et prosjekt er testestimering og riktig utførelse like viktig som utviklingssyklusen. Stikker til estimering er svært viktig å bygge et godt omdømme med klienten.
Erfaring spiller en viktig rolle i å estimere «Software Testing Innsats». Arbeidet med varierte prosjekter hjelper oss med å utarbeide en nøyaktig estimering av testsyklusen.
Åpenbart kan Man Ikke bare blindt sette noen dager for enhver testoppgave. Test estimering bør være realistisk og nøyaktig.
denne opplæringen vil inneholde noen viktige tips som vil være svært nyttig å forberede nøyaktig test estimering på en svært enkel måte.
Test Estimering Prosess
«Estimering er prosessen med å finne et estimat, eller tilnærming, som er en verdi som kan brukes til noen formål, selv om inngangsdata kan være ufullstendig, usikker eller ustabil.»
vi kommer alle over forskjellige oppgaver, plikter og tidsfrister gjennom hele livet som fagfolk, nå er det to tilnærminger for å finne løsningen på et problem.
den første tilnærmingen er en reaktiv tilnærming hvor vi prøver å finne en løsning på problemet først etter at det kommer.
i den andre tilnærmingen som kan kalles En Proaktiv Tilnærming, forbereder vi oss først godt 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 dermed betraktes som en teknikk som brukes når vi tar en proaktiv tilnærming til problemet.
Dermed Estimering kan brukes til å forutsi hvor mye innsats med hensyn til tid og kostnader vil være nødvendig for å fullføre en definert oppgave. Når testteamet er i stand til å estimere problemet ved hånden, er det lettere for dem å komme opp med en løsning som ville være optimal for problemet ved hånden.
praksisen med estimering kan da defineres mer formelt som en omtrentlig beregning av den sannsynlige kostnaden for et stykke arbeid.
les også = > 7 Faktorer Som Påvirker Testestimering Av Selenium Automation Project
Grunnleggende Forutsetninger
Nedenfor Er De Grunnleggende Forutsetningene for Testestimeringsprosessen.
#1) Innsikt samlet fra å jobbe med tidligere erfaringer: Det er alltid en god praksis å tilbringe litt tid, og huske tidligere prosjekter som utgjorde utfordringer som ligner på dagens forsøk på hånden.
# 2) tilgjengelige dokumenter eller artefakter: Test management repository verktøy komme godt med i disse typer scenarier som de lagrer krav og avklaring dokumenter. Disse dokumentene kan refereres av testteamet for å klart definere omfanget av prosjektet.
# 3) Forutsetninger om type arbeid: Tidligere arbeidserfaring bidrar til å gjøre antagelser om prosjektet. Det er her ansette erfarne fagfolk betyr mest. Testing ledere kan plukke hjernen til disse menneskene til å levere de ønskede resultatene.
# 4) Beregning Av Potensielle risikoer og Trusler: Testteamet må også visualisere de potensielle risikoene og truslene og fallgruvene som ligger kan ligge for teamet i fremtiden.
#5) Bestemme om dokumentene har blitt baselined: testteamet må også avgjøre om kravene er baselined eller ikke. Hvis dokumentene ikke er baselined, er det viktig å bestemme frekvensen av endringene.
#6) alle ansvar og avhengigheter bør være klare: organisasjonen bør klart definere roller og ansvar for alle som skal utføre estimeringsprosessen.
# 7) Dokumentasjon og sporing av estimeringspostene: all relevant informasjon til estimeringsprosessen skal dokumenteres.
# 8) Aktiviteter som skal utføres under testestimeringsprosessen:
- Organiser et lag som skal utføre estimater.
- Dekomponere prosjektet i prosjektfaser og påfølgende konstituerende aktiviteter.
- Beregn estimeringen basert på tidligere prosjekter og yrkeserfaring.
- Prioritere mulige trusler og komme opp med tilnærminger for å redusere disse risikoene.
- Gjennomgå og dokumentere relevante deler av arbeidet.
- Send arbeidet til relevante interessenter.
Mest Fremtredende Testestimeringsteknikker
Noen av de viktigste teknikkene for testestimering er:
- Testpunktestimering
- arbeidsfasebasert estimering
- bruk case point estimering
Hvordan og hvor bruker vi disse teknikkene:
#1) Test Point estimering Er en enkel og lett forståelig estimering teknikk som er mye brukt på tvers av programvare testing spektrum. Iterative faser og enkelhet er de viktigste funksjonene i denne spesielle teknikken.
#2) Arbeidsfasebasert estimering er estimeringsteknikken som brukes der et gjetning estimat er gjort på en bestemt fase (normalt den korteste og enkleste av fasene) og deretter legger testteamet gradvis på andre faser i den første estimeringen og til slutt kommer opp med en passende estimering.
#3) Bruk-Case Point estimeringsteknikk er estimeringen av brukstilfellene der ujusterte aktørvekter og ujusterte bruksvekter brukes til å bestemme estimeringen av programvaretesting.
Detaljer Om Testpunktestimeringsteknikk
testpunktestimeringsteknikken gjøres ved å følge trinnene som er oppført nedenfor:
(følgende vekter, som kan variere fra prosjekt til prosjekt – kan vurderes under dette paradigmet-Noen av disse vektene er vektene for programmeringsspråket basert på kodens kompleksitet, applikasjonsvekt basert på type applikasjon og testvekter som tildeles basert på de ulike faser av programvaretesting.)
Ubehandlede Testpunkter multipliseres MED CWF for å oppnå teststørrelsen i Testpunktets Størrelse.
Produktivitetsfaktor angir hvor lang Tid en testingeniør har til å fullføre testingen av ett Testpunkt.
Testinnsats I Persontimer beregnes ved å multiplisere Testpunktstørrelsen med Produktivitetsfaktoren.
for beregning av testpunktestimeringsteknikken vurderer vi følgende variabler.
- test krav kompleksitet
- Grensesnitt med andre krav
- Totalt antall bekreftelsespoeng
- 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 testtilfelle design = Totalt Testpunkt x (1 + Justeringsfaktor For testtilfelle design)
Justert Testpunkt for testtilfelle utførelse = Totalt Testpunkt X (1 + Justeringsfaktor for testtilfelle utførelse)
totalt testpunkt (normalisert) x (1 + justeringsfaktor for testtilfelle design/utførelse) = justert testpunkt for testtilfelle design/utførelse
total innsats i Person Timer (PH) = Antall Normaliserte Test poeng / Produktivitet (I Normaliserte Test poeng per Person Timer)
Test Estimering Eksempler
La oss prøve å bruke ovennevnte formulering til en annen praktisk bruk.
Anta at vi ender med et testkrav der vi har 5 testscenarier å teste.
la Oss nå si At testscenario 1 har 5 test forventede resultater, testscenario 2 har 6 test forventede resultater, testscenario 3 bare 2 test forventede resultater, testscenario 4 9 test forventede resultater, testscenario 5 også 9 test forventede resultater, henholdsvis.
vi klassifiserer testscenariene i tre klasser, dvs. komplekse, enkle og moderate, basert på det totale antall 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 brukte 5 testpoeng for komplekse klasser, 3 for moderate og 2 for de enkle scenariene.
vi multipliserer antatte testpoeng med totalt antall forventede resultater i alle disse testscenariene. Så vi ender opp med følgende tilnærminger:
Scenario 1: 3 testpoeng * 5 test forventede resultater = Justerte testpoeng = 25
Scenario 2: 3 testpoeng * 6 test forventede resultater = Justerte testpoeng = 30
Scenario 3: 2 testpoeng * 2 test forventede resultater = Justerte testpoeng = 4
Scenario 4: 5 testpoeng * 9 test forventede resultater = Justerte testpoeng = 45
Scenario 5: 5 testpoeng * 9 test forventede resultater = Justerte testpoeng = 45
så med tanke på at vi må søke om for eksempel 5 Persontimer for hvert justerte testpunkt, ender vi opp med å få følgende omtrentlige resultat.
Testscenario 1: 25 justerte testpoeng * 5 Persontimer = 125 Persontimer
Testscenario 2: 30 justerte testpoeng * 5 Persontimer = 150 Persontimer
Testscenario 3: 4 justerte testpoeng * 5 Persontimer= 20 Persontimer
Testscenario 4: 45 justerte testpoeng * 5 Persontimer = 225 Persontimer
Testscenario 5: 45 justerte testpoeng * 5 Persontimer = 225 Persontimer
så de totale omtrentlige persontimer er: 745 Persontimer
Bruk Case Point Estimeringsmetode
på brukstilfellene Der Vi Beregner Den Samlede Testestimeringsinnsatsen Basert På Brukstilfellene Eller Kravene.
Nedenfor Er En detaljert prosess av use case point estimation method:
et eksempel på det samme er at vi i et bestemt krav har henholdsvis 5 brukstilfeller, brukstilfelle 1, brukstilfelle 2,…, brukstilfelle 5. La oss nå se på at use case 1 består av 6 aktører, use case 2 består av 15 aktører, use case 3, 4 og 5, 3, 4 og 5 aktører.
vi anser enhver brukstilfelle som involverer totalt antall skuespillere som mindre enn 5 som negativ, enhver brukstilfelle med totalt antall skuespillere er lik eller mer enn 5 og mindre enn eller lik 10 som positiv og enhver brukstilfelle med mer enn 10 skuespillere som eksepsjonell.
vi bestemte oss for å tildele 2 poeng for de eksepsjonelle brukstilfellene, 1 for de positive og -1 for de negative.
derfor kategoriserer vi brukstilfellene 1 og 5 som positive, brukstilfelle 2 som eksepsjonelle og brukstilfelle 3, 4 som negative henholdsvis basert på våre ovennevnte forutsetninger.
Så Ubearbeidet skuespiller vekter = bruk case 1 = (totalt antall skuespillere) 5 * 1 (det tildelte punktet) = 5. Tilsvarende
bruk sak 2 = 15 * 2 = 30 .
Gjenta prosessen for resten av brukstilfellene får Vi De Ubearbeidede aktørvektene = 33
ubearbeidet brukstilfelle vekt = total nr. av brukstilfeller = 5
Ubearbeidet brukstilfelle punkt = Ujusterte aktørvekter + Ujustert brukstilfelle vekt = 33 + 5 = 38
Behandlet bruk case punkt = 38 * = 26.7 Eller 28 Persontimer omtrent
Arbeidsfaseteknikken
arbeidsfaseteknikken kan beskrives i følgende trinn.
- Del ned det samlede arbeidet i faser.
- Start med den enkleste fasen og tilordne en omtrentlig estimeringsverdi til den.
- 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 avledede tilnærmingsverdier.
- Oppsummer den omtrentlige estimeringsverdien ved å legge til estimeringsverdien for gjeldende faseinnsats til den allerede eksisterende verdien.
- Fortsett med trinn 3 til 5 til alle fasene som er identifisert i første trinn, er oppbrukt.
- Godta den endelige omtrentlige estimatverdien som den ultimate.
Anta at i et krav er det 5 nødvendige faser. I den innledende fase 1 antar vi at den totale innsatsen som trengs er 35 persontimer, og så starter vi neste fase 2 som vi har 4 komparative forutsetninger for henholdsvis 35, 45, 55 og 65.
vi vurderer 65 persontimer som er maksimumsverdien her. I fase 3 , 4 ,5 kommer vi opp med estimater (12 , 33, 43 , 54) , (15 , 10 , 7 , 8) og (2, 16, 5, 13) henholdsvis. Ved å bruke nevnte prinsipp ender vi opp med henholdsvis 185 Persontimer.
jeg legger informasjon om – hvordan estimere testinnsats for enhver testoppgave, som jeg lærte av min erfaring.
9 Generelle Tips Om Hvordan Du Estimerer Testtid Nøyaktig
Faktorer Som Påvirker Estimering Av Programvaretest, Og Generelle Tips For Å Estimere Nøyaktig:
#1) Tenk På Litt Buffertid: estimeringen bør inneholde litt buffer. Men legg ikke til en buffer, noe som ikke er realistisk. Å ha en buffer i estimeringen gjør oss i stand til å takle eventuelle forsinkelser som kan oppstå. Å ha en buffer bidrar også til å sikre maksimal testdekning.
#2) Vurder Bug-Syklusen: testestimeringen inkluderer også bug-syklusen. Den faktiske testsyklusen kan ta flere dager enn estimert.
for å unngå dette, bør vi vurdere det faktum at testsyklusen avhenger av stabiliteten til bygningen. Hvis bygningen ikke er stabil, kan utviklere trenge mer tid til å fikse det, og selvfølgelig blir testsyklusen utvidet automatisk.
# 3) Tilgjengelighet Av Alle Ressursene For Estimert Periode: Testen estimering bør vurdere alle bladene planlagt av gruppemedlemmene (vanligvis lange blader) i de neste ukene eller neste månedene. Dette vil sikre at estimatene er realistiske.
estimeringen bør vurdere et fast antall ressurser for en testsyklus. Hvis antall ressurser reduseres, bør estimeringen besøkes og oppdateres tilsvarende.
# 4) Kan Vi Gjøre Parallell Testing? Har du noen tidligere versjoner av samme produkt slik at du kan sammenligne utdataene? Hvis ja, kan dette gjøre testoppgaven litt enklere. Du bør tenke på estimeringen basert på produktversjonen din.
#5) Estimater Kan Gå Galt-så besøk estimatene ofte i begynnelsen før du forplikter det: i de tidlige stadiene bør vi ofte besøke testestimatene og gjøre endringer 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 for Å Gjøre Dommer! Erfaringer fra tidligere prosjekter spiller en viktig rolle når du forbereder tidsestimater. Vi kan prøve å unngå alle vanskeligheter eller problemer som ble møtt i tidligere prosjekter. Vi kan analysere hvordan de tidligere estimatene var og hvor mye de bidro til å levere produktet til tiden.
#7) Vurder Omfanget Av Prosjektet: Vet hva som er sluttmål for prosjektet og liste over alle endelige leveranser. Faktorer som skal vurderes for små og store prosjekter varierer mye. Store prosjekter inkluderer vanligvis å sette opp en testbed, generere testdata, testskript, etc.
derfor bør estimatene være basert på alle disse faktorene. Mens for små prosjekter, typisk testsyklusen omfatter test case skriving, utførelse og regresjon.
# 8) Skal Du Utføre Belastningstesting? Hvis du trenger å sette betydelig tid i ytelsestesting deretter anslå tilsvarende. Beregninger for prosjekter som involverer belastningstesting bør vurderes annerledes.
# 9) Kjenner Du Laget Ditt? Hvis du kjenner styrken og svakhetene til personer som arbeider i teamet ditt, kan du estimere testoppgaver mer presist. Mens estimering bør man vurdere det faktum at ikke alle ressurser kan gi samme produktivitetsnivå.
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
Software test estimering er en praksis som krever involvering av erfarne fagfolk samt innføring av bransjens beste praksis som test case point og bruk case point metoder.
Det er også viktig å vedta et åpent sinn for å tilpasse de nødvendige prosessene. En vellykket implementering av disse prosessene fører til en generell forbedring i testprosessen.
dette er en gjesteartikkel Av Forfatteren «N. Sandhya Rani».
Sist Oppdatert: 29. November 2021
