Teknikker for beregning av programvaretest
Thomas Hamilton
Hva er Software Test Estimation?
Testvurdering er en ledelsesaktivitet som tilnærmer hvor lenge en oppgave ville ta å fullføre. Anslå innsats for testen er en av de større og viktig oppgaver i Test Management.
Hvorfor testestimering?
To spørsmål du kan forvente fra kundene dine når du diskuterer potensielle testengasjementer
For små prosjekter er disse spørsmålene relativt enkle å svare på. Men for det store prosjektet som Testing Guru99 Banks nettsted, må du tenke hardt for å svare på disse spørsmålene.
Hva skal estimeres?
- Ressurser: Det kreves ressurser for å bære ut eventuelle prosjektoppgaver. De kan være personer, utstyr, fasiliteter, finansiering eller noe annet som kan defineres som kreves for å fullføre en prosjektaktivitet.
- Tider: Tid er den mest verdifulle ressursen i et prosjekt. Hvert prosjekt har en leveringsfrist.
- Menneskelige ferdigheter: Menneskelige ferdigheter betyr kunnskap og erfaring av teammedlemmene. De påvirker etter din vurdering. For eksempel vil et team, hvis medlemmer har lave testferdigheter, bruke mer tid på å fullføre prosjektet enn det som har høye testferdigheter.
- Kostnad: Kostnad er prosjektet budsjett. Generelt sett betyr det hvor mye penger det tar å fullføre prosjektet.
Hvordan estimere?
Liste over estimeringsteknikker for programvaretest
- Work Breakdown Structure
- 3-punkts programvaretestingsestimeringsteknikk
- Bredbånd Delphi-teknikk
- Funksjonspunkt/testpunktanalyse
- Bruk – Case Point Method
- Prosentvis fordeling
- Ad hoc metode
Følgende er 4-trinns prosessen for å komme frem til et estimat
Du vil lære hvordan du kombinerer disse teknikkene for å finne estimatet for Guru99 Bank case-studie.
Trinn 1) Del opp hele prosjektoppgaven i deloppgaver
Oppgave er et stykke arbeid som er gitt til noen. For å gjøre dette kan du bruke Work Breakdown Structure teknikk.
I denne teknikken er et komplekst prosjekt delt inn i moduler. Modulene er delt inn i undermoduler. Hver undermodul er videre delt inn i funksjonalitet. Det betyr å dele opp hele prosjektoppgaven i minste oppgaver.
Bruk Work Break Down-strukturen for å dele opp Guru99 Bank-prosjektet i 5 mindre oppgaver-
Etter det kan du bryte ut hver oppgave til deloppgave. Formålet med denne aktiviteten er å lage oppgave som detaljert as mulig.
| Oppgave | Underoppgave |
|---|---|
| Analyser programvarekravspesifikasjonen | Undersøk de myke kravspesifikasjonene |
| Intervju med utvikleren og andre interessenter for å vite mer om nettstedet | |
| Lag testspesifikasjonen | Design testscenarier |
| Lag testcases | |
| Revse og revidere testsaker | |
| Utfør testsakene | Bygg opp testmiljøet |
| Utfør testsakene | |
| Revse resultater av testutførelse | |
| Rapporter feilene | |
| Opprett Defekt rapporter | |
| Rapporter feilene |
Trinn 2) Tildel hver oppgave til et teammedlem
I dette trinnet tildeles hver oppgave til hensiktsmessig medlem i prosjektgruppen. Du kan tildele oppgaven som følger
| Oppgave | medlemmer |
|---|---|
| Analyser programvarekravspesifikasjonen | Alle medlemmene |
| Lag testspesifikasjonen | Tester/testanalytiker |
| Bygg opp testmiljøet | Test administrator |
| Utfør testsakene | Tester, testadministrator |
| Meld fra om mangler | tester |
Trinn 3) Beregning av innsats for oppgaver
Det er 2 teknikker du kan bruke for å beregne innsatsen for oppgaver
- Funksjonell punktmetode
- Trepunkts estimering
Metode 1) Funksjonspunktmetode
I denne metoden estimerer testlederen størrelse, varighet og kostnad for oppgavene
Trinn A) Estimer størrelsen på oppgaven
In Trinn 1, har du allerede delt opp hele prosjektoppgaven i små oppgaver ved å bruke WBS-metoden. Nå anslår du størrelsen på disse oppgavene. La oss øve 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 beløp funksjonalitet som er relevant for brukeren. Jo flere Antall av funksjonalitet, jo mer komplekse systemet er.
Før du starter faktiske estimere oppgaver innsats, funksjonelle poeng er delt inn i tre grupper som Complex, Middels Enkel som følger:
Basert på komplekset av programvarefunksjoner, må testlederen gi nok vekt til hvert funksjonspunkt. For eksempel
| Gruppe | Vekt |
|---|---|
| Complex | 5 |
| Medium | 3 |
| Enkelt | 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 kompleksitet av nettstedets funksjoner ved å angi vekten for hver modul?
Mer kompleks funksjonspunktet, mer er innsatsen for å teste det. Nettsiden er delt inn i 12-funksjon poeng, kan du bestemme kompleksitet av hver funksjon punkter som følger-
| Nei. | Modulnavn | Gjeldende roller | Tekniske beskrivelser | Vekt |
|---|---|---|---|---|
| 1. | Balanseforespørsel | Leder
Kunde- |
Kunde: En kunde kan ha flere bankkontoer. Han kan kun se saldoen på kontoene sine
manager: En leder kan se balansen til alle kundene som er under hans tilsyn |
3 |
| 2. | Overføring av midler | Leder
Kunde- |
Kunde: En kunde kan overføre penger fra sin "egen" konto til en hvilken som helst destinasjonskonto.
manager: En leder kan overføre midler fra en hvilken som helst kildebankkonto til destinasjonskonto |
5 |
| 3. | Mini erklæring | Leder
Kunde- |
En miniutskrift vil vise de siste 5 transaksjonene på en konto
Kunde: En kunde kan se mini-uttalelse av kun sine "egne" kontoer manager: En administrator kan se miniuttalelse for enhver konto |
3 |
| 4. | Tilpasset erklæring | Leder
Kunde- |
En tilpasset erklæring lar deg filtrere og vise transaksjoner på en konto basert på dato, transaksjonsverdi
Kunde: En kunde kan kun se tilpasset kontoutskrift for sine "egne" kontoer manager: En leder kan se tilpasset -uttalelse for enhver konto |
5 |
| 5. | Endre passord | Leder
Kunde- |
Kunde: En kunde kan endre passord for kun kontoen sin.
manager: En leder kan endre passordet for kun kontoen sin. Han kan ikke endre passord til kundene sine |
1 |
| 6. | Ny kunde | Leder | manager: En leder kan legge til en ny kunde.
manager: En leder kan redigere detaljer som adresse, e-post, telefon til en kunde. |
3 |
| 7. | Ny konto | Leder | Systemet tilbyr for øyeblikket 2 typer kontoer
En kunde kan ha flere sparekontoer (en i hans navn, en annen i et felles navn osv.). Han kan ha flere brukskontoer for forskjellige selskaper han eier. Eller han kan ha flere bruks- og sparekontoer. manager: En administrator kan legge til en ny konto for en eksisterende kunde. |
5 |
| 8. | Rediger bruker | Leder | manager: En administrator kan legge til en redigeringskontodetaljer for en eksisterende konto | 1 |
| 9. | Slett konto | Leder | manager: En leder kan legge til en slette en konto for en kunde. | 1 |
| 10. | Slett kunde | Leder | En kunde kan bare slettes hvis han/hun ikke har noen aktive kontoer eller sparekontoer
manager: En leder kan slette en kunde. |
1 |
| 11. | Innskudd | Leder | manager: En leder kan sette inn penger på hvilken som helst konto. Gjøres vanligvis når kontanter settes inn i en bankfilial. | 3 |
| 12. | Tilbaketrekking | Leder | manager: En leder kan ta ut penger fra hvilken som helst konto. Gjøres vanligvis når kontanter tas ut i en bankfilial. | 3 |
TRINN B) Estimer varighet for oppgaven
Etter å ha klassifisert kompleksitet av funksjonspoengene må du estimere varighet å teste dem. Varighet betyr hvor mye tid trenger for å fullføre oppgaven.
- Total innsats: Innsatsen for å teste alle funksjonene til nettstedet fullstendig
- Totalt funksjonspoeng: Totalt antall moduler på nettstedet
- Estimat definert per funksjonspunkt: Gjennomsnittlig innsats for å fullføre ett funksjonspoeng. Denne verdien avhenger av produktivitet av medlemmet som skal påta seg denne oppgaven.
Anta at prosjektteamet ditt har estimert definerte funksjonspunkter på 5 timer/poeng. Du kan anslå den totale innsatsen for å teste alle funksjonene til nettstedet Guru99 Bank som følger:
| Vekt | Antall funksjonspunkter | Totalt | |
|---|---|---|---|
| Complex | 5 | 3 | 15 |
| Medium | 3 | 5 | 15 |
| Enkelt | 1 | 4 | 4 |
| Funksjon Totalt antall poeng | 34 | ||
| Estimat definerer per punkt | 5 | ||
| Total estimert innsats (person Hours) | 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 arbeids- og ikke-arbeidskostnader.
Eksempelet ovenfor viser også viktigheten av medlemmet i teamet ditt. Hvis du har talentfull og erfaren medlemmer, kan du fullføre den tildelte oppgaven i liten tid, og prosjektet vil fullføres ved fristen eller tidligere.
TRINN C) Estimer kostnadene for oppgavene
Dette trinnet hjelper deg med å svare på det siste spørsmålet til kunden "Hvor mye koster det?"
Anta at teamlønnen din i gjennomsnitt er $5 per time. Tiden som kreves for oppgaven "Opprett testspesifikasjoner" 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 et samlet budsjett for prosjektet.
Som prosjektleder må du bestemme hvordan du skal få de fleste kommer tilbake for din bedrifts investering. Jo flere nøyaktig ditt estimat av prosjektkostnaden er bedre kan du administrere prosjektets budsjett.
Metode 2) Trepunktsvurdering
Tre-punkts estimering er en av teknikkene som kan brukes til å estimere en oppgave. Enkelheten til trepunktsestimatet gjør det til et veldig nyttig verktøy for en prosjektleder som ønsker å estimere.
I trepunkts estimering, tre verdier produseres i utgangspunktet for hver oppgave basert på tidligere erfaring or beste gjetninger som følger
Når man estimerer en oppgave, må testlederen oppgi tre verdier, som spesifisert ovenfor. De tre verdiene som er identifisert, anslår hva som skjer i en optimal tilstand, hva er mest sannsynlig, eller hva vi tror det ville være i verste fall scenario.
La oss se hvordan du bruker de tre verdiene ovenfor i følgende eksempel
For oppgaven "Lag testspesifikasjonen”, kan du anslå testinnsatsen? Husk at du må dekke alt modulene til Guru99 Bank-nettstedet som gjort i Funksjonspunktmetode
Du kan anslå som følgende
- Ocuco Beste tilfelle å fullføre denne oppgaven er 120 arbeidstimer (rundt 15 dager). I dette tilfellet har du et dyktig team, de kan fullføre oppgaven på kortest mulig tid.
- Ocuco mest sannsynlig sak for å fullføre denne oppgaven er 170 arbeidstimer (rundt 21 dager). Dette er et normalt tilfelle, du har nok ressurser og evne til å fullføre oppgaven
- Ocuco i verste fall å fullføre denne oppgaven er 200 arbeidstimer (rundt 25 dager). Du må utføre mye mer arbeid fordi teammedlemmene dine ikke er erfarne.
Tilordne nå verdien til hver parameter som nedenfor
Innsatsen for å fullføre oppgaven kan beregnes ved hjelp av dobbelt-trekant fordeling formel som følger-
I formelen ovenfor er parameter E kjent som Vektet gjennomsnitt. Det er estimeringen av oppgaven "Opprett testspesifikasjonen".
Men sjefen din kan spørre deg
I estimatet ovenfor bestemmer du bare en mulig og ikke en viss verdi, må vi vite om sannsynlighet at anslaget er riktig. Du kan bruke den andre formelen:
I formelen ovenfor, SD-gjennomsnittet standardavvik, kan denne verdien gi deg informasjon om sannsynlighet at anslaget er riktig.
Nå kan du konkludere estimatet for oppgaven "Opprett testspesifikasjonen"
For å fullføre oppgaven "Opprett testspesifikasjonen" til Guru99 Bank-nettstedet, trenger du 166.6 ± 13.33 Arbeidstimer (153.33 til 179.99 arbeidstimer)
Trinn 4) Valider estimatet
Når du har opprettet et samlet estimat for alle oppgavene nevnt i WBS, må du videresende det til ledelsen, hvem vil anmeldelse 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 din vurdering logisk og rimelig slik at de kan godkjenne estimeringsplanen din.
Beste praksis for testberegning
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 slutter i jobben plutselig, testingen tar mer tid enn beregnet å fullføre... osv. Derfor må du inkludere en viss buffer i estimeringen din. Å ha en buffer i estimeringen gjør det mulig å takle eventuelle forsinkelser som kan oppstå.
Kontoressursplanlegging 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 til teammedlemmet ditt, vanligvis lange blader.
Bruk tidligere erfaring som referanse
Erfaringer fra tidligere prosjekter spiller en viktig rolle under utarbeidelsen av tidsestimatene. Fordi noen prosjekter kan ha en viss likhet, kan du gjenbruke tidligere estimat. For eksempel, hvis du bruker å gjøre et prosjekt som å teste et nettsted, kan du lære av den erfaringen, prøve å unngå alle vanskelighetene eller problemene som ble møtt i tidligere prosjekter.
Hold deg til din vurdering
Estimat er bare estimat fordi det kan gå Feil.I tidlige stadier av prosjektet bør du ofte sjekk testberegningene på nytt og foreta endringer om nødvendig. Vi bør ikke utvide estimeringen etter at vi har fikset den, med mindre det er store endringer i kravet, eller du må forhandle med kunden om revurderingen
Software Test Estimation Mal
Last ned Software Test Estimation Excel(.xlsx)
Andre teknikker
Wideband Delphi Technique, Use – Case Point Method, Prosentfordeling, Ad-hoc-metoden er andre estimeringsteknikker innen programvareteknikk.
Software Test Estimation Techniques Video
Klikk her. hvis videoen ikke er tilgjengelig
Videoutskrift
- La oss gjøre en øvelse -for Søknad om flyreservasjon utarbeide en arbeidssammenbruddsstruktur 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 innloggingsfunksjonalitet testes på 2 timer. Lag 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 om innsatsen som kreves
- Dette er Bottom-Up-strategi for testestimering. Teknikken kalles nedenfra og opp siden du estimerer varigheten, avhengighetene og ressursene basert på oppgavene som er på det laveste nivået i arbeidsnedbrytningshierarkiet.
- I bottom-up-strategien er estimater ikke tatt av en enkelt person, men alle interessenter, individuelle bidragsytere, eksperter og erfarne medarbeidere samlet. Ideen er å trekke på samarbeidsvisdommen til teammedlemmene for å komme frem til nøyaktige testestimater
- Nå siden du har betydelig erfaring med flyreservasjonssystemet. Bruk denne erfaringen til å anslå innsatsen som kreves for full Funksjonell testing av nettstedet. – http://newtours.demoaut.com/
- Denne sidens funksjon er identisk med Flight Reservation Application , bare at den er nettbasert. Sett veiledningen på pause og gjør øvelsen nå
- Jeg håper basert på din erfaring at du 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å deres 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 å fastsette Gjennomsnittlig innsats pr Testsak tidligere for lignende prosjekter og deretter bruke estimerte testtilfeller av det nåværende prosjektet og komme frem til total innsats
- Mer sofistikerte estimeringsmodeller involverer komplekse matematiske modeller. I praksis bruker flertallet av prosjektene ovenfra-ned-tilnærming for estimering.
- Testestimater kan påvirkes av mange faktorer som tidspress, personfaktorer, geografisk fordeling av testteamet og så videre
