Ulike Typer Estimeringsteknikker I Software Testing
Software Test Estimering er en viktig ledelsesoperasjon som brukes til å bestemme en omtrentlig tidsramme som kreves for å starte og fullføre en prosess i et kontrollert miljø.
det er avgjørende for enhver prosjektplanlegging å ikke gå forbi tidsfristene, angi budsjetter og tilgjengelige ressurser. En av de mest nyttige oppgavene her er å sjekke ressursene i lys av et forsøk på å bli brukt på testen.
Ingeniører ved UTOR utnytter ofte ulike typer estimeringsteknikker under programvaretesting. Disse metodene har blitt bekreftet som effektive av våre kunder. Derfor vil vi gå over dem, og avsløre deres spesifikke fordeler og ulemper, slik at du er informert om hvordan du best kan implementere dem.
Hva Er Estimering Av Programvaretesting?
Estimering Av Programvaretest er en prosess for å måle og administrere varigheten og handlingene som kreves for å kjøre en fullstendig test på programvaren.
Tid og innsats er betydelig enkelt å beregne for småskala oppdrag. For større prosjekter. effektive strategier må være på plass slik at ingen feil blir gjort. Hvis undervurdert eller overvurdert, testing ressurser for slike prosjekter blir enten utilstrekkelig eller misbrukt helt.
Hvordan Estimerer Team Ressurser For Testing Av Programvare?
Før testen starter, er det to svært viktige usikkerheter som alt avhenger av og må strykes ut mellom tester og klient. Disse inkluderer;
- Hva er den totale estimerte varigheten av hele prosedyren?
- hva er den totale estimerte prosedyrekostnaden i form av penger og ressurser?
Hva Er Estimert?
Tid, ressurser, kostnader og menneskelige ferdigheter bestemmes vanligvis under testestimering.
Tid
en laginnsats effektivitet vurderes vanligvis av evnen til å levere innen en angitt tidsramme, på eller før fristen.
etter å ha sjekket standard nødvendig varighet for hver del av prosjektet for hånden, prosjektledere utvikle en måte å holde å planlegge hvert prosjekt.
han sørger for at alt blir levert i tide. Av denne grunn er tidsestimering en av de viktigste faktorene for å bygge et godt omdømme blant kunder og ha et godt antall lojale kunder.
Ressurser
før et prosjekt kan påbegynnes, er det obligatorisk å sjekke tilgjengelige ressurser, de som skal inkluderes, og anbefalte erstatninger hvis noen ikke er lett tilgjengelige. Uten å sjekke for dette, er det mest sannsynlig at prosjekter ikke vil være ferdig før fristen.
Kostnad
mens du forbereder deg til en testprosess, må det estimerte budsjettet tas i full betraktning på alle fronter (både finansielle og ikke-finansielle).
den totale kostnaden må tas i betraktning for å ta hensyn til mulige utgifter og sikre at prosjektet forblir innenfor kundens fastsatte budsjett, og jobbe med det hvis det ikke er opp til.
de nevnte feltene er alle relaterte og gjensidig avhengige av seg selv. Varigheten som det vil ta, avhenger også av de tilgjengelige verktøyene og gitt budsjett.
over tid har prosedyren involvert i software test estimering blitt gjort med forskjellige prosesser, ved hjelp av ulike metoder og verktøy som har avansert med tiden av samme grunn.
integrasjonen og arbeidet med disse teknikkene har gjort gjennomsnittsprosedyren mye enklere også.
Typer Estimeringsteknikker For Programvaretesting
det er mange estimeringer og gjennomsnittsteknikker generelt, men vi vil bare se på noen få populære Ut av denne artikkelens mye.
Program evaluation and review technique (PERT)
i denne teknikken er oppgavene brutt ned i 3 underkategorier for å finne bedre tid til å bli tatt for ferdigstillelse, nemlig;
Det Optimistiske Scenariet – O; i dette tilfellet antas varighet, monetære og ressursutgifter for prosjektet å være på sitt høyeste optimale nivå. Dette betyr at individuelle medlemmer av QA-Teamet jobber på sitt aller beste kollektivt, holder seg til tid, uten press, uforutsigbare hendelser eller behovet for å besøke jobben og fortsatt levere godt arbeid også.
Det Mest Sannsynlige Scenariet – M; her er alle ting vurdert; med det kjente arbeidsscenariet og vurderer negative og positive muligheter i tankene, estimeres elementer hvordan det mest sannsynlig vil skje.
Det Pessimistiske Scenariet-P; dette vurderer det mest negative scenariet som kan være. Gjennomsnittet vil bli hengslet på antagelsen om at det utvilsomt vil være et negativt utfall som skal behandles i hver enkelt fase av hele testingen.
pros av PERT
- Ved hjelp av denne teknikken betyr at teamet arbeider med et estimat som sjekker alle mulige dødsfall og belønninger på alle fronter.
- Lag kan komme med en evaluering ganske nær virkeligheten.
- den forbereder organisasjonene for ethvert mulig utfall av byggetesten når de beregner hvert tenkelig scenario og forbereder seg tilstrekkelig til å dempe det om nødvendig.
Ulemper MED PERT
- når du står overfor en større mengde testprosjekter, vil bruk av denne form for estimat forbruke mye mer tid til å gjennomgå.
- det er stor sannsynlighet for at unøyaktige beregninger oppstår.
- verdiene som brukes her er aldri konstante og kan møtes med mange feil siden det bare er et estimat.
Ucp (User Case Point)
når noen eller noe bruker og kommuniserer med den aktuelle applikasjonen, identifiseres enheten som en aktør. Nevnte enhet er hovedsakelig dokumentert i de ikke-justerbare Bruksvektene, som påvirker prosessens kapasitet.
enhver kommunikasjon i mellom vil sikre alles engasjement fra aksjonærer til enkeltpersoner i QA-teamet gjennom de ulike sekvensene og definerte mål.
over ti forskjellige agenter påvirker hvor komplisert et prosjekt er teknisk, og om lag åtte tar en kompleks avgift på det miljømessig. Dette er i samsvar Med Funnene Fra Gustav Karner.
denne estimeringsmetoden er avhengig av å beregne flere varianter fra de såkalte aktørene, brukerboksvektene og punktene som påvirker prosessen, teknikaliteten og andre faktorer.
For det første, for å starte denne prosessen, må de kryssjekke deres respektive intricacies og påvirke prosessen. Deretter gjøres ytterligere gjennomsnitt ved å bruke formler for beregning.
etter å ha sjekket prosjektets størrelse, bestemmer de involverte hvor lang tid som kreves før den totale fullføringen av prosessen. To viktige måter å forhindre dette på er;
Ved Hjelp Av Karners metode og vurderer hvert testfall som forbruker 20 ansatte timer.
ved hjelp av selskapets rekordtid for prosjektgjennomføring, i alle fall, for å beregne statistiske gjennomsnitt og gjette varigheten for det aktuelle prosjektet.
UCP= Ikke Justerbart ucp x Teknisk Kompleksitetsfaktor x Miljøpåvirkningsfaktor.
Pros AV UCP
- hvis du trenger å jobbe på forhånd og planlegge langt på forhånd, er denne estimeringsmetoden sannsynligvis bedre som den er gjort i begynnelsen og hjelper til med beskjæring og godkjenning av budsjettstørrelser.
- ved hjelp av noen spesielle styringsverktøy er automatisk beregning av estimater mulig, noe som sparer mye tid for vurderingsteamet og letter jobben.
Ulemper VED UCP:
- hvis prosjektkravene ikke er gitt I Brukersaker, gjør det umulig å bruke denne teknikken, OG QA-Teamet må kilde for en annen metode.
- NÅR UCP er gitt, og de ikke er nøyaktige eller eksplisitte nok, er det mest sannsynlig å ende negativt med estimater langt fra ekte, da denne metoden avhenger av ikke bare å gi case poeng, men å gi klare case poeng.
Work Breakdown Structure (WBS)
her gjøres teknikken for å estimere verdier ved å dele primærprosessen i ulike underkategorier. En prediktiv beregning av gjennomsnittlig varighet på hvert trinn begynner gradvis med et grovt arbeid på de enklere av partiet, og deretter uteksaminert i både vanskelighetsgrad og korrekthet.
etter den første prosessen, velg den høyest mulige verdien du kom til og legg dem opp og få den ultimate verdien, estimere innsatsen og tiden som kreves for hver oppgave.
Fordeler MED WBS
- en åpenbar fordel med denne metoden er at det gjør det lettere å få øye på hvert minutt og nødvendige detaljer mens du deler arbeidet i mindre biter. Dette betyr at arbeidet er gjort
- det er alltid grundig og gjennomsiktig, da konklusjonene er tabulert for samme formål og enklere sporing.
Ulemper MED WBS:
- denne naturen krever vanligvis å gni sinn og teammedlemmer og interessenter for å tappe fra deres eksterne erfaring.
- Endringer i spesifikasjoner og klientbehov kan føre til foreldet og trenger teamet til å se på det og revurdere helt.
Delphi-Metoden
Delphi-metoden er ganske populær blant testteam globalt. Data fra frivillige deltakere er samlet og nøye undersøkt flere og, i ingen spesiell rekkefølge, kommer frem til en avtalt konklusjon.
Hver fase av undersøkelsen gir ny eller forbedret data tilbakemelding, som bare legger til de endelige funnene raffinement med mye fortjent tillit.
vanligvis består et team av ikke mer enn ti personer som møtes for å diskutere prosjektets kritiske funksjoner om å ta fatt på og gi sine meninger om prosjektets mulige varighet.
deretter møtes teamet igjen, og denne gangen deles meningene fra den første datoen. Dette gir medlemmene en annen tilnærming til prosjektet. Men synspunktene er ikke merket til deres forslag.
når teammedlemmene er gjennom denne fasen, vil de ha en annen enstemmig diskusjon, og sortering av meninger bringer den nye oppfatningsvinkelen i betraktning.
Dette vil fortsette til alle er enige om samme side. Selv om Den vanlige måten Å gjøre Delphi-metoden, kan dette skjemaet bli tweaked for å passe sine behov og evner.
Pros OF DELPHI
- Fordi ingen unike formler eller utstyr er nødvendige her, er det det enkleste av partiet for et lag å gjennomgå, alt som trengs er kundens spesifikasjoner og godt å gå.
- estimeringen er ganske nær nøyaktighet siden mange profesjonelle synspunkter vurderes i møte-og idedelingsprosessen.
Cons OF DELPHI
- så enkelt som det kan være å gjennomgå, kan det ta mye produktiv tid fordi oftere enn ikke.
- Det er utfordrende å komme opp med en omfattende estimering etter den første batchen av møter og dele meninger, så det tar vanligvis noen få.
- selv etter å ha brukt så mye tid, kan resultatene ikke resirkuleres. Så for hvert enkelt prosjekt som skal kjøres, starter prosessen på nytt med de nye kravene.
For Å Oppsummere
dette blogginnlegget gjennomgikk fire typer estimeringsteknikker i programvaretesting og hvor effektive de er i planleggingen av et rimelig testbudsjett.
etter vellykket estimering, kan du si sikkert riktig tilnærming til outsourcing prosjekter til qa selskaper?
her er en artikkel om hvordan du velger den beste tilnærmingen FOR qa outsourcing.
Fortell oss hvilken av disse testestimeringstaktikkene du ville implementere, og hva var din innsikt?