Testestimeringsteknikker i programvaretesting
Thomas Hamilton
⚡ Smart oppsummering
Teknikker for estimering av programvaretesting anslår hvor lang tid testingen vil ta og hvor mye det vil koste. En firetrinnsprosess – bryt ned oppgaver, tildel eiere, estimer innsats og valider med interessenter – gjør vage tidslinjer om til en forsvarlig plan som ledelsen kan godkjenne.
Hva er Software Test Estimation?
Estimering av programvaretest er en ledelsesaktivitet som anslår hvor lang tid en testoppgave vil ta og hvor mye den vil koste. Å produsere et troverdig testestimat er en av de viktigste oppgavene i testledelse fordi det styrer beslutninger om tidsplan, budsjett og ressurser.
Hvorfor testestimatering er viktig
Klienter stiller alltid to spørsmål før de signerer et testoppdrag:
For små prosjekter er disse spørsmålene enkle å svare på. For et større prosjekt – for eksempel testing av Guru99 Banks nettsted – du trenger en strukturert teknikk for å forsvare svaret.
Hva skal estimeres?
- Ressurser: folk, utstyr, fasiliteter, finansiering og alt annet som kreves for å utføre arbeidet.
- Tid: den mest verdifulle ressursen i ethvert prosjekt – hver utgivelse har en tidsfrist.
- Menneskelige ferdigheter: kunnskapen og erfaringen til teamet. Sterkere testere fullfører raskere enn et mindre erfarent team.
- Kostnad: prosjektbudsjettet – hvor mye penger det tar å gjennomføre den planlagte testingen.
Hvordan estimere
Vanlige estimeringsteknikker for programvaretesting er:
- Arbeidsfordelingsstruktur (WBS).
- Trepunktsestimering.
- Bredbånd Delphi.
- Funksjonspunkt- eller testpunktanalyse.
- Brukstilfellepunktmetoden.
- Prosentfordeling.
- Ad-hoc-metode.
Firetrinnsprosessen nedenfor kombinerer flere teknikker for å komme frem til et forsvarlig estimat. Eksemplet bruker Guru99 Casestudie av banker.
Trinn 1) Del hele prosjektet inn i deloppgaver
Bruke Work Breakdown Structure teknikk for å dele et komplekst prosjekt inn i moduler, undermoduler og til slutt de minste meningsfulle oppgavene. Estimater er langt mer pålitelige på bladnivå enn mot vage overskriftsprosjekter.
Bruk teknikken for å bryte ned Guru99 Bank-prosjektet i fem mindre oppgaver:
Hver oppgave deles deretter inn i underoppgaver inntil hver linje er detaljert nok til å estimere.
| Oppgave | Deloppgave |
|---|---|
| Analyser programvarekravspesifikasjon | Undersøk kravspesifikasjonene. |
| Intervju utviklere og andre interessenter for å lære mer om nettstedet. | |
| Lag testspesifikasjonen | Design testscenarier. |
| Lag testtilfeller. | |
| Revvise og revidere testtilfeller. | |
| Utfør testsakene | Bygg testmiljøet. |
| Utfør testtilfellene. | |
| Revse resultatene av testkjøringen. | |
| Rapporter feilene | Opprett defekt rapporter. |
| Rapporter manglene. |
Trinn 2) Tildel hver oppgave til et teammedlem
Tildel hver underoppgave til den mest passende eieren.
| Oppgave | Eieren |
|---|---|
| Analyser programvarekravspesifikasjon | Alle teammedlemmer |
| Lag testspesifikasjonen | Tester / Testanalytiker |
| Bygg testmiljøet | Testadministrator |
| Utfør testsakene | Tester, testadministrator |
| Meld fra om mangler | tester |
Trinn 3) Innsatsestimering for hver oppgave
To komplementære teknikker fungerer bra på dette stadiet:
- Funksjonspunktmetoden.
- Trepunktsestimering.
Metode 1) Funksjonspunktmetode
Testlederen estimerer størrelse, varighet og kostnad for hver oppgave.
Trinn A) Estimer størrelsen på oppgaven
Ta oppgaven «Lag testspesifikasjonen». Størrelsen avhenger av den funksjonelle størrelsen på systemet som testes – jo flere funksjoner, desto mer komplekst er systemet. Funksjonspunkter klassifiseres vanligvis i tre grupper: Komplekse, Medium og Enkel.
Basert på kompleksitet tildeler testlederen en vekt til hvert funksjonspunkt:
| Gruppe | vekting |
|---|---|
| Complex | 5 |
| Medium | 3 |
| Enkelt | 1 |
Ocuco GuruNettstedet til 99 Bank er delt inn i 12 funksjonspunkter. Kompleksiteten deres er oppsummert nedenfor.
| # | Moduler | Gjeldende roller | Tekniske beskrivelser | vekting |
|---|---|---|---|---|
| 1 | Balanseforespørsel | Leder, kunde | Kunde: se kun saldoen på egne kontoer. manager: se saldoen til hver kunde under oppsyn. |
3 |
| 2 | Overføring av midler | Leder, kunde | Kunde: overføre penger fra egen konto til et hvilket som helst sted. manager: overføre midler fra hvilken som helst kilde til hvilken som helst destinasjon. |
5 |
| 3 | Mini erklæring | Leder, kunde | De siste fem transaksjonene på en konto. Kunde: se bare egne kontoer. manager: se hvilken som helst konto. |
3 |
| 4 | Tilpasset erklæring | Leder, kunde | Filtrerte transaksjoner etter dato eller verdi. Kunde: kun egne kontoer. manager: hvilken som helst konto. |
5 |
| 5 | Endre passord | Leder, kunde | Kunde: endre eget passord. manager: endre eget passord (ikke kundens). |
1 |
| 6 | Ny kunde | Leder | Legg til og rediger kundedetaljer (adresse, e-post, telefon). | 3 |
| 7 | Ny konto | Leder | Spare- og brukskontoer; en kunde kan ha flere av hver. Leder legger til nye kontoer for eksisterende kunder. | 5 |
| 8 | Rediger bruker | Leder | Rediger detaljene for en eksisterende konto. | 1 |
| 9 | Slett konto | Leder | Slett en eksisterende konto for en kunde. | 1 |
| 10 | Slett kunde | Leder | Slett en kunde bare når det ikke finnes noen aktive kontoer. | 1 |
| 11 | Innskudd | Leder | Sett inn kontanter på en hvilken som helst konto i filialen. | 3 |
| 12 | Tilbaketrekking | Leder | Ta ut kontanter fra hvilken som helst konto i filialen. | 3 |
Trinn B) Estimer varigheten for oppgaven
Når kompleksiteten er angitt, estimer varigheten som kreves for å teste hver gruppe.
- Total innsats: total innsats for å teste alle funksjonene på nettstedet.
- Totalt antall funksjonspoeng: totale moduler på nettstedet.
- Estimat per funksjonspunkt: gjennomsnittlig innsats per poeng; avhenger av teamets produktivitet.
Anta at teamets estimat per funksjonspunkt er 5 timer/poengDen totale innsatsen for GuruEksempel på 99 Bank er:
| Gruppe | vekting | Funksjonspunkter | Totalt |
|---|---|---|---|
| Complex | 5 | 3 | 15 |
| Medium | 3 | 5 | 15 |
| Enkelt | 1 | 4 | 4 |
| Funksjon Totalt antall poeng | 34 | ||
| Estimat per punkt | 5 | ||
| Total estimert innsats (persontimer) | 170 | ||
Den totale innsatsen for å fullføre «Opprett testspesifikasjonen» er rundt 170 arbeidstimerNår innsatsen er kjent, kan du tildele ressurser for å bestemme varighet og kostnad.
Trinn C) Estimer kostnaden for oppgavene
Dette trinnet svarer på det andre klientspørsmålet – «Hvor mye koster det?». Anta en gjennomsnittlig teampris på $ 5 / timeOppgaven ovenfor tar 170 timer, så kostnaden er 170 × $5 = $850Bruk den samme beregningen på tvers av alle WBS-oppgaver for å komme frem til prosjektbudsjettet.
Jo mer nøyaktig estimatet er, desto bedre kan du styre prosjektets budsjett og sikre at hver krone gir avkastning.
Metode 2) Trepunktsestimering
Trepunktsestimering er en strukturert teknikk der testlederen oppgir tre verdier per oppgave – optimistisk, mest sannsynligog pessimistisk innsats – basert på tidligere erfaring eller beste gjetninger.
For «Opprett testspesifikasjonen» kan de tre verdiene være:
- Beste tilfelle: 120 arbeidstimer (~15 dager) med et sterkt og erfarent team.
- Mest sannsynlig: 170 arbeidstimer (~21 dager) med et typisk team og ressurser.
- Verste tilfelle: 200 arbeidstimer (~25 dager) med et mindre erfarent team og ekstra omarbeid.
Beregn det vektede gjennomsnittet ved hjelp av PERT-formelen:
Verdien E er den vektlagt gjennomsnitt – overskriftsestimatet for «Lag testspesifikasjonen».
Å uttrykke tilliten rundt E, beregn standardavviket:
For det Guru99 Bankeksempel estimatet utgjør 166.6 ± 13.33 arbeidstimer — et intervall på 153.33 til 179.99 arbeidstimer.
Trinn 4) Valider estimatet
Samle alle oppgaveestimater fra WBS-en og send planen til styret (administrerende direktør, prosjektleder, viktige interessenter) for gjennomgang og godkjenning.
Gå logisk gjennom estimatet med styret, slik at de forstår forutsetningene, de valgte teknikkene og beredskapen du har bygget inn.
Beste praksis for testestimering
Legg til buffertid
Planer overlever sjelden kontakt med virkeligheten – teammedlemmer slutter, tester tar lengre tid enn forventet, avhengigheter forsvinner. Bygg en rimelig buffer i hvert estimat slik at tidsplanen absorberer mindre overraskelser.
Planlegg for ressurstilgjengelighet
Ta hensyn til planlagt permisjon, opplæring og vaktskifter. Estimater som ignorerer tilgjengelighet ser bra ut på papiret og kollapser i levering.
Bruk tidligere erfaringer som referanse
Historiske data fra lignende prosjekter er uvurderlige. Hvis du testet et sammenlignbart nettsted i fjor, lær av dets faktiske data, problemene som oppsto og bufferen som reddet dagen.
Hold deg til estimatet – men gjennomgå det på nytt
Anslagene er ikke falsketracts; de er de beste gjetningene. RevBesøk dem ved kjente milepæler og juster kun når kravene endres vesentlig eller ny informasjon endrer bildet. Forhandle om eventuelle endringer med kunden på en transparent måte.
Software Test Estimation Mal
Last ned programvaretestestimeringen i Excel (.xlsx)
Andre estimeringsteknikker
I tillegg til WBS-, funksjonspunkt- og trepunktsestimering, er flere andre teknikker mye brukt:
- Bredbånd Delphi: iterativ konsensusestimering av et ekspertpanel.
- Brukstilfellepunktmetode: henter innsats fra antallet og kompleksiteten av brukstilfeller.
- Prosentfordeling: allokerer en fast prosentandel av den totale prosjektets innsats til testing.
- Ad-hoc-metode: ekspertvurdering når historiske data mangler.
Bottom-Up vs Top-Down estimering
Et praktisk syn på estimering deler seg også opp i to komplementære strategier:
- Bottom-up-estimering: basert på oppgaver på det laveste nivået i arbeidsstokksystemet. Flere interessenter, erfarne medarbeidere og bidragsytere kombinerer tallene sine for å komme frem til en nøyaktig totalsum. Ideelt når arbeidet er godt forstått.
- Topp-og-ned-estimering: klassifiserer prosjektet etter størrelse og kompleksitet og sammenligner det med fullførte prosjekter av lignende form. Bruker også gjennomsnittlig innsats per testforsøk og skaleres etter det anslåtte antallet tilfeller. Nyttig tidlig i et prosjekt når detaljer er knappe.
De fleste team blander de to – ovenfra-og-ned for overskriftstallene, nedenfra-og-opp for trygghet – og legger resultatet over med sofistikerte modeller når budsjettene rettferdiggjør innsatsen.
