Hva er estimering av programvaretest?
Testestimering er en ledelsesaktivitet som tilnærmer seg hvor lang tid en oppgave vil ta å fullføre. Å estimere innsatsen for testen er en av de viktigste og viktige oppgavene i Testledelse.
Hvorfor testestimering?
To spørsmål du kan forvente av kundene dine når du diskuterer potensielle testoppdrag er
For små prosjekter er disse spørsmålene relativt enkle å svare på. Men for det store prosjektet som Testing Guru99 Bank-nettstedet, må du tenke hardt på å svare på disse spørsmålene.
I denne veiledningen vil du lære-
- Hva er estimering av programvaretest?
- Hvorfor testestimering?
- Hva skal jeg estimere?
- Hvordan estimere?
- Trinn 1) Del hele prosjektoppgaven i deloppgaver
- Trinn 2) Tildel hver oppgave til teammedlemmet
- Trinn 3) Anslagsestimering for oppgaver
- Metode 1) Funksjonspunktmetode
- Metode 2) Trepunktsestimering
- Trinn 4) Valider estimeringen
- Testmetoder for beste praksis
- Andre teknikker
Hva skal jeg estimere?
- Ressurser: Det kreves ressurser for å utføre prosjektoppgaver. De kan være mennesker, utstyr, fasiliteter, finansiering eller noe annet som er definert som er nødvendig for å fullføre en prosjektaktivitet.
- Tider: Tid er den mest verdifulle ressursen i et prosjekt. Hvert prosjekt har frist til levering.
- Menneskelige ferdigheter: Menneskelige ferdigheter betyr kunnskapen og opplevelsen til teammedlemmene. De påvirker etter ditt estimat. For eksempel vil et team, hvis medlemmer har lave testferdigheter, ta mer tid på å fullføre prosjektet enn det teamet som har høytestende ferdigheter.
- Kostnad: Kostnad er prosjektbudsjettet . Generelt sett betyr det hvor mye penger det tar å fullføre prosjektet.
Hvordan estimere?
Liste over estimerte teknikker for programvaretest
- Arbeidsfordelingsstruktur
- 3-punkts programvaretestestimeringsteknikk
- Wideband Delphi-teknikk
- Funksjonspunkt / testpunktanalyse
- Bruk - Case Point Method
- Prosentvis fordeling
- Ad-hoc-metode
Følgende er 4-trinnsprosessen for å komme til et estimat
Du vil lære hvordan du kombinerer disse teknikkene for å finne estimatet for Guru99 Banks casestudie.
Trinn 1) Del hele prosjektoppgaven i deloppgaver
Oppgave er et stykke arbeid som er gitt til noen. For å gjøre dette kan du bruke Work Breakdown Structure- teknikken.
I denne teknikken er et komplekst prosjekt delt inn i moduler. Modulene er delt inn i delmoduler. Hver delmodul er videre delt inn i funksjonalitet. Det betyr å dele hele prosjektoppgaven i de minste oppgavene.
Bruk Work Break Down-strukturen til å dele ut Guru99 Bank-prosjektet i 5 mindre oppgaver-
Etter det kan du bryte ut hver oppgave til deloppgaven. Hensikten med denne aktiviteten er å lage en så detaljert oppgave som mulig .
| Oppgave | Underoppgave |
|---|---|
| Analyser spesifikasjon av programvarekrav | Undersøk spesifikasjonene for myke krav |
| Intervju med utvikleren og andre interessenter for å vite mer om nettstedet | |
| Opprett testspesifikasjonen | Design testscenarier |
| Lag testtilfeller | |
| Gjennomgå og revidere testsaker | |
| Utfør testsakene | Bygg opp testmiljøet |
| Utfør testsakene | |
| Gjennomgå testutførelsesresultatene | |
| Rapporter feilene | |
| Opprett feilrapporter | |
| Rapporter feilene |
Trinn 2) Tildel hver oppgave til teammedlemmet
I dette trinnet tildeles hver oppgave det rette medlemmet i prosjektgruppen. Du kan tilordne oppgaven som følger
| Oppgave | Medlemmer |
|---|---|
| Analyser spesifikasjon av programvarekrav | Alle medlemmene |
| Lag testspesifikasjonen | Tester / testanalytiker |
| Bygg opp testmiljøet | Test administrator |
| Utfør testsakene | Tester, testadministrator |
| Rapporter feil | Tester |
Trinn 3) Anslagsestimering for oppgaver
Det er to teknikker du kan bruke for å estimere innsatsen for oppgaver
- Funksjonell punktmetode
- Trepunktsestimering
Metode 1) Funksjonspunktmetode
I denne metoden estimerer Test Manager størrelse, varighet og kostnad for oppgavene
Trinn A) Beregn størrelsen på oppgaven
I trinn 1 har du allerede brutt hele prosjektoppgaven i liten oppgave ved å bruke WBS-metoden. Nå estimerer du størrelsen på disse oppgavene. La oss trene med en bestemt oppgave " Lag testspesifikasjonen "
Størrelsen på denne oppgaven avhenger av den funksjonelle størrelsen på systemet som testes. Den funksjonelle størrelsen gjenspeiler mengden funksjonalitet som er relevant for brukeren. Jo mer antall funksjonalitet, jo mer komplekst er systemet.
Før du starter den faktiske estimeringen av oppgavene, er funksjonelle punkter delt inn i tre grupper som Complex , Medium Simple som følger:
Basert på komplekset av programvarefunksjoner, må Test Manger gi nok vekt til hvert funksjonelle punkt. For eksempel
| Gruppe | Vekt |
|---|---|
| Kompleks | 5 |
| Medium | 3 |
| Enkel | 1 |
La oss ta en enkel eksempeløvelse for å bli klarere:
Ta en titt på programvarespesifikasjonen til nettstedet Guru99 Bank her, programvareingeniøren har allerede beskrevet programvaremodulene i detalj. Kan du bestemme kompleksiteten til nettstedets funksjoner ved å angi vekten for hver modul?
Mer komplisert funksjonspunkt, mer er innsatsen for å teste det. Nettstedet er delt inn i 12 funksjonspunkter , du kan bestemme kompleksiteten til hvert funksjonspunkt som følger-
| Nei. | Modulnavn | Gjeldende roller | Beskrivelse | Vekt |
|---|---|---|---|---|
| 1. | Balanseforespørsel | Manager-kunde | Kunde: En kunde kan ha flere bankkontoer. Han kan bare se saldoen på kontoene sine Manager: En manager kan se saldoen til alle kundene som kommer under hans tilsyn | 3 |
| 2. | Overføring av midler | Manager-kunde | Kunde: En kunde kan ha overføringsmidler fra sin “egen” konto til hvilken som helst destinasjonskonto. Manager: En manager kan overføre penger fra hvilken som helst kilde bankkonto til destinasjonskonto | 5 |
| 3. | Mini Statement | Manager-kunde | En Mini-uttalelse vil vise de siste 5 transaksjonene til en konto Kunde: En kunde kan bare se mini-uttalelse av sine "egne" kontoer Manager: En manager kan se mini-uttalelse for en hvilken som helst konto | 3 |
| 4. | Tilpasset uttalelse | Manager-kunde | En tilpasset uttalelse lar deg filtrere og vise transaksjoner i en konto basert på dato, transaksjonsverdi Kunde: En kunde kan se Tilpasset - kun uttalelse av sine "egne" kontoer. Manager: En leder kan se Tilpasset - uttalelse om hvilken som helst konto | 5 |
| 5. | Bytt passord | Manager-kunde | Kunde: En kunde kan bare endre passord for kontoen sin. Manager: En manager kan bare endre passord for kontoen sin. Han kan ikke endre passord til kundene sine | 1 |
| 6. | Ny kunde | sjef | Manager: En manager kan legge til en ny kunde. Manager: En manager kan redigere detaljer som adresse, e-post, telefon til en kunde. | 3 |
| 7. | Ny konto | sjef | For tiden tilbyr systemet to typer kontoer
| 5 |
| 8. | Rediger bruker | sjef | Manager: En manager kan legge til redigeringsdetaljer for en eksisterende konto | 1 |
| 9. | Slett konto | sjef | Manager: En manager kan legge til en slette en konto for en kunde. | 1 |
| 10. | Slett kunde | sjef | En kunde kan bare slettes hvis han / hun ikke har noen aktive nåværende eller lagrende kontoer Manager: En manager kan slette en kunde. | 1 |
| 11. | Innskudd | sjef | Manager: En manager kan sette inn penger på hvilken som helst konto. Vanligvis gjort når kontanter blir satt inn i en bankkontor. | 3 |
| 12. | Uttak | sjef | Manager: En manager kan ta ut penger fra hvilken som helst konto. Vanligvis gjøres når kontanter blir tatt ut i en bankkontor. | 3 |
TRINN B) Beregn varigheten for oppgaven
Etter å ha klassifisert kompleksiteten til funksjonspunktene, må du estimere varigheten for å teste dem. Varighet betyr hvor lang tid det tar å fullføre oppgaven.
- Total innsats : Innsatsen for å teste alle funksjonene på nettstedet fullstendig
- Totale funksjonspoeng : Totale moduler på nettstedet
- Estimert definert per funksjonspoeng : Gjennomsnittlig innsats for å fullføre ett funksjonspoeng. Denne verdien avhenger av produktiviteten til medlemmet som tar ansvaret for denne oppgaven.
Anta at prosjektgruppen din har estimert definert per funksjonspoeng på 5 timer / poeng . Du kan estimere den totale innsatsen for å teste alle funksjonene på nettstedet Guru99 Bank på følgende måte:
| Vekt | Antall funksjonspoeng | Total | |
|---|---|---|---|
| Kompleks | 5 | 3 | 15 |
| Medium | 3 | 5 | 15 |
| Enkel | 1 | 4 | 4 |
| Funksjon totalt poeng | 34 | ||
| Anslag definere per punkt | 5 | ||
| Total estimert innsats (arbeidstimer) | 170 | ||
Så den totale innsatsen for å fullføre oppgaven "Lag testspesifikasjonen" til Guru99 Bank er rundt 170 arbeidstimer
Når du forstår innsatsen som kreves, kan du tildele ressurser for å bestemme hvor lang tid oppgaven vil ta (varighet), og deretter kan du estimere arbeidskraft og ikke-arbeidskraftkostnader.
Ovenstående eksempel viser også viktigheten av medlemmet i teamet ditt. Hvis du har dyktige og erfarne medlemmer, kan du fullføre den tildelte oppgaven i løpet av den korte tiden, og prosjektet ditt avsluttes innen fristen eller før.
TRINN C) Beregn kostnadene for oppgavene
Dette trinnet hjelper deg med å svare på det siste spørsmålet til kunden " Hvor mye koster det?"
Anta at gjennomsnittlig er lønnen din $ 5 per time. Tiden som kreves for "Create Test Specs" -oppgaven er 170 timer. Følgelig er kostnaden for oppgaven 5 * 170 = $ 850. Nå kan du beregne budsjett for andre aktiviteter i WBS og komme frem til det samlede budsjettet for prosjektet.
Som prosjektleder må du bestemme hvordan du skal få mest mulig avkastning for selskapets investering. Jo mer nøyaktig estimatet ditt av prosjektkostnadene er, desto bedre er du i stand til å administrere prosjektets budsjett.
METODE 2) Trepunktsestimering
Tre-punktsestimering er en av teknikkene som kan brukes til å estimere en oppgave. Enkelheten i trepunktsestimasjonen gjør det til et veldig nyttig verktøy for en prosjektleder som ønsker å estimere.
I trepunktsestimering produseres tre verdier i utgangspunktet for hver oppgave basert på tidligere erfaring eller beste gjetninger som følger
Når du estimerer en oppgave, må Test Manager oppgi tre verdier, som spesifisert ovenfor. De tre verdiene som er identifisert, estimerer hva som skjer i optimal tilstand , hva som er mest sannsynlig , eller hva vi tror det ville være i verste fall .
La oss se hvordan du bruker de ovennevnte tre verdiene i følgende eksempel
Kan du estimere testinnsatsen for oppgaven “ Lag testspesifikasjonen ”? Husk at du må dekke alle modulene på Guru99 Bank-nettstedet, slik det er gjort i Function Point Method
Du kan estimere følgende
- Det beste tilfellet for å fullføre denne oppgaven er 120 arbeidstimer (rundt 15 dager). I dette tilfellet har du et talentfullt team, de kan fullføre oppgaven på den minste tiden.
- Det mest sannsynlige tilfellet for å fullføre denne oppgaven er 170 arbeidstimer (rundt 21 dager). Dette er en normal sak, du har nok ressurs og evne til å fullføre oppgaven
- Det verste tilfellet for å fullføre denne oppgaven er 200 arbeidstimer (rundt 25 dager). Du må utføre mye mer arbeid fordi teammedlemmene dine ikke er erfarne.
Nå tildeler verdien til hver parameter som nedenfor
Innsatsen for å fullføre oppgaven kan beregnes ved hjelp av den dobbelte trekantede fordelingsformelen som følger -
I formelen ovenfor er parameter E kjent som vektet gjennomsnitt. Det er estimeringen av oppgaven "Lag testspesifikasjonen".
Men sjefen din spør deg kanskje
I estimeringen ovenfor bestemmer du bare en mulig og ikke en viss verdi, vi må vite om sannsynligheten for at estimeringen er riktig. Du kan bruke den andre formelen:
I formelen ovenfor, SD betyr standardavvik, kan denne verdien gi deg informasjon om sannsynligheten for at estimeringen er riktig.
Nå kan du avslutte estimeringen for oppgaven "Lag testspesifikasjonen"
For å fullføre oppgaven "Lag testspesifikasjonen" på Guru99 Banks nettsted, trenger du 166,6 ± 13,33 Man-time (153,33 til 179,99 man-time)
Trinn 4) Valider estimeringen
Når du har opprettet et samlet estimat for alle oppgavene nevnt i WBS, må du sende det til styret , som vil gjennomgå og godkjenne det.
Styremedlemmet kan bestå av administrerende direktør, prosjektleder og andre interessenter.
Styret vil gjennomgå og diskutere estimeringsplanen din med deg. Du kan forklare dem estimeringen din logisk og rimelig, slik at de kan godkjenne estimeringsplanen din.
Testmetoder for beste praksis
Dette emnet introduserer generelle tips om hvordan du estimerer testnøyaktigheten.
- Legg til litt buffertid: Mange uforutsigbare ting kan skje med prosjektet ditt, for eksempel at et talentfullt teammedlem avslutter jobben sin plutselig, testingen tar mer tid enn beregnet å fullføre ... osv. Det er derfor du trenger å ta med noen buffer i beregningen. Å ha en buffer i estimeringen gjør det mulig å takle eventuelle forsinkelser som kan oppstå.
- Konto Ressursplanlegging i estimering: Hva bør du gjøre hvis noen medlemmer i teamet ditt tar lange permisjoner? Det kan forsinke prosjektet. Ressursplanlegging i estimering spiller en nøkkelrolle. Tilgjengeligheten av ressurser vil bidra til å sikre at estimatene er realistiske. Her må du vurdere bladene for teammedlemmet ditt, generelt lange løv.
- Bruk tidligere erfaringer som referanse: Erfaringer fra tidligere prosjekter spiller en viktig rolle mens de utarbeider tidsestimatene. Fordi noen prosjekter kan være lik, kan du bruke den tidligere estimeringen. Hvis du for eksempel bruker et prosjekt som å teste et nettsted, kan du lære av denne erfaringen, prøve å unngå alle vanskeligheter eller problemer som ble møtt i tidligere prosjekter.
- Hold deg til din estimering: Estimering er bare estimat fordi det kan gå galt . I tidlige stadier av prosjektet, bør du ofte sjekke testestimatene og foreta endringer om nødvendig. Vi skal ikke utvide estimatet etter at vi har løst det, med mindre det er store endringer i kravet, eller du må forhandle med kunden om nyestimering
Estimasjonsmal for programvare
Last ned programvaretestestimering Excel (.xlsx)
Andre teknikker
Wideband Delphi Technique, Use - Case Point Method, Prosentvis fordeling, Ad-hoc metode er andre estimeringsteknikker innen Software Engineering.
Klikk her hvis videoen ikke er tilgjengelig
Videoutskrift- La oss gjøre en øvelse -for Flight Reservation-applikasjonen forberede en arbeidsstruktureringsstruktur for
- forskjellige testoppgaver som - Sjekk påloggingsfunksjonalitet, Sjekk ny ordrefunksjonalitet, Sjekk faksfunksjonalitet og annen lignende funksjonalitet, og estimer innsatsen som kreves for å teste disse funksjonene
- For eksempel kan påloggingsfunksjonalitet testes på to timer. Lage også en liste over alle oppgavene og tilsvarende innsats. Sett opplæringen på pause, og fullfør øvelsen. Jeg håper du gjorde en utdannet gjetning av den nødvendige innsatsen
- Dette er en bottom-up-strategi for testestimering. Teknikken kalles nedenfra og opp, siden du beregner varighet, avhengighet og ressurser på grunnlag av oppgavene som er på det laveste nivået i arbeidsfordelingshierarkiet.
- I bottom-up-strategien blir ikke estimater tatt av en enkelt person, men alle interessenter, individuelle bidragsytere, eksperter og erfarne medarbeidere samlet. Ideen er å trekke på samarbeidsvisdom fra teammedlemmene for å komme til nøyaktige testestimater
- Nå siden du har betydelig erfaring med flyreservasjonssystemet. Bruk denne erfaringen til å estimere den innsatsen som kreves for full funksjonstesting av nettstedet. - http://newtours.demoaut.com/
- Dette nettstedet er funksjonelt identisk med Flight Reservation Application, bare at det er nettbasert. Sett opplæringen på pause og gjør øvelsen nå
- Jeg håper at du, basert på din erfaring, gjorde et godt estimat på innsatsen som kreves for å teste nettstedet
- Dette er Top-Down-tilnærmingen til estimering som er basert på erfaring.
- En annen teknikk er å klassifisere prosjekt basert på størrelse og kompleksitet, og deretter se hvor lang tid et prosjekt av en bestemt størrelse og kompleksitet har tatt tidligere.
- En annen tilnærming er å bestemme gjennomsnittlig innsats per testtilfelle tidligere for lignende prosjekter, og deretter bruke estimerte testtilfeller for det aktuelle prosjektet og komme til total innsats
- Mer sofistikerte estimeringsmodeller involverer komplekse matematiske modeller. I praksis bruker flertallet av prosjektene top-down-tilnærming for estimering.
- Testestimater kan påvirkes av mange faktorer som tidspress, personfaktorer, geografisk fordeling av testteamet og så videre