Testestimeringsteknikker i softwaretestning
Thomas Hamilton
⚡ Smart opsummering
Teknikker til estimering af softwaretest anslår, hvor lang tid testningen vil tage, og hvor meget det vil koste. En proces i fire trin – opdeling af opgaver, tildeling af ejere, estimering af indsats og validering med interessenter – forvandler vage tidslinjer til en forsvarlig plan, som ledelsen kan godkende.
Hvad er Software Test Estimation?
Softwaretestestimering er en ledelsesaktivitet, der tilnærmelsesvis beregner, hvor lang tid en testopgave vil tage, og hvor meget den vil koste. At producere et troværdigt testestimat er et af de vigtigste ansvarsområder i testadministration fordi det er drivkraften bag beslutninger om tidsplan, budget og ressourcer.
Hvorfor testedstimering er vigtig
Klienter stiller altid to spørgsmål, før de underskriver et testopdrag:
For små projekter er disse spørgsmål lette at besvare. For et større projekt – f.eks. at teste Guru99 Banks hjemmeside — du har brug for en struktureret teknik til at forsvare svaret.
Hvad skal estimeres?
- Ressourcer: mennesker, udstyr, faciliteter, finansiering og alt andet, der kræves for at udføre arbejdet.
- Tid: den mest værdifulde ressource i ethvert projekt — hver udgivelse har en deadline.
- Menneskelige færdigheder: teamets viden og erfaring. Stærkere testere bliver hurtigere færdige end et mindre erfarent team.
- Omkostninger: projektbudgettet — hvor mange penge det kræver at udføre den planlagte testning.
Sådan estimerer du
De almindelige teknikker til estimering af softwaretest er:
- Arbejdsfordelingsstruktur (WBS).
- Trepunktsestimering.
- Bredbånds Delphi.
- Funktionspunkts- eller testpunktsanalyse.
- Use-Case Point-metoden.
- Procentfordeling.
- Ad-hoc-metode.
Firetrinsprocessen nedenfor kombinerer adskillige teknikker for at nå frem til et forsvarligt estimat. Eksemplet bruger Guru99 Bankcasestudie.
Trin 1) Opdel hele projektet i underopgaver
Brug Work Breakdown Structure teknik til at opdele et komplekst projekt i moduler, undermoduler og i sidste ende de mindste meningsfulde opgaver. Estimater er langt mere pålidelige på bladniveau end i forhold til vage overskriftsprojekter.
Anvend teknikken til at bryde Guru99 Bankprojekt i fem mindre opgaver:
Hver opgave opdeles derefter i underopgaver, indtil hver linje er detaljeret nok til at kunne estimeres.
| Opgaver | Delopgave |
|---|---|
| Analyser softwarekravspecifikation | Undersøg kravspecifikationerne. |
| Interview udviklere og andre interessenter for at lære mere om hjemmesiden. | |
| Opret testspecifikationen | Design testscenarier. |
| Opret testcases. | |
| Revse og revidere testcases. | |
| Udfør testsagerne | Byg testmiljøet. |
| Udfør testcasesene. | |
| RevSe resultaterne af testudførelsen. | |
| Rapportér manglerne | Opret defekt rapporter. |
| Rapportér manglerne. |
Trin 2) Tildel hver opgave til et teammedlem
Tildel hver underopgave til den mest passende ejer.
| Opgaver | Ejer |
|---|---|
| Analyser softwarekravspecifikation | Alle teammedlemmer |
| Opret testspecifikationen | Tester / Testanalytiker |
| Byg testmiljøet | Test administrator |
| Udfør testsagerne | Tester, testadministrator |
| Rapporter mangler | tester |
Trin 3) Indsatsestimering for hver opgave
To komplementære teknikker fungerer godt på dette stadie:
- Funktionspunktmetoden.
- Trepunktsestimering.
Metode 1) Funktionspunktsmetode
Testmanageren estimerer størrelse, varighed og omkostninger for hver opgave.
Trin A) Estimer opgavens størrelse
Tag opgaven "Opret testspecifikationen". Dens størrelse afhænger af den funktionelle størrelse af det system, der testes - jo flere funktioner, desto mere komplekst er systemet. Funktionspunkter klassificeres typisk i tre grupper: Komplekse, Mellemstore og Simple.
Baseret på kompleksitet tildeler testmanageren en vægt til hvert funktionspunkt:
| gruppe | Vægtning |
|---|---|
| Complex | 5 |
| Medium | 3 |
| Simpelt | 1 |
Guru99 Banks hjemmeside er opdelt i 12 funktionspunkter. Deres kompleksitet er opsummeret nedenfor.
| # | Moduler | Gældende roller | Beskrivelse | Vægtning |
|---|---|---|---|---|
| 1 | Balanceundersøgelse | Leder, Kunde | Kunde: kun se saldo på egne konti. Manager: se saldoen for hver kunde under opsyn. |
3 |
| 2 | Pengeoverførsel | Leder, Kunde | Kunde: overføre penge fra egen konto til en hvilken som helst destination. Manager: overføre penge fra enhver kilde til enhver destination. |
5 |
| 3 | Mini erklæring | Leder, Kunde | De sidste fem transaktioner på en konto. Kunde: kun se egne konti. Manager: se enhver konto. |
3 |
| 4 | Tilpasset erklæring | Leder, Kunde | Filtrerede transaktioner efter dato eller værdi. Kunde: kun egne konti. Manager: enhver konto. |
5 |
| 5 | Skift adgangskode | Leder, Kunde | Kunde: ændre egen adgangskode. Manager: ændre egen adgangskode (ikke kundens). |
1 |
| 6 | Ny kunde | Manager | Tilføj og rediger kundeoplysninger (adresse, e-mail, telefon). | 3 |
| 7 | Ny konto | Manager | Opsparings- og løbende konti; en kunde kan have flere af hver. Leder tilføjer nye konti for eksisterende kunder. | 5 |
| 8 | Rediger konto | Manager | Rediger oplysninger om en eksisterende konto. | 1 |
| 9 | Slet konto | Manager | Slet en eksisterende konto for en kunde. | 1 |
| 10 | Slet kunde | Manager | Slet kun en kunde, når der ikke er nogen aktive konti. | 1 |
| 11 | Depositum | Manager | Indsæt kontanter på en hvilken som helst konto i filialen. | 3 |
| 12 | Tilbagetrækning | Manager | Hæv kontanter fra enhver konto i filialen. | 3 |
Trin B) Estimer varigheden af opgaven
Når kompleksiteten er angivet, skal du estimere den varighed, der kræves for at teste hver gruppe.
- Samlet indsats: en total indsats for at teste alle funktioner på webstedet.
- Samlede funktionspoint: hjemmesidens samlede moduler.
- Estimat pr. funktionspunkt: gennemsnitlig indsats pr. point; afhænger af holdets produktivitet.
Antag at holdets estimat pr. funktionspunkt er 5 timer/pointDen samlede indsats for Guru99 Bank eksempel er:
| gruppe | Vægtning | Funktionspunkter | Samlet beløb |
|---|---|---|---|
| Complex | 5 | 3 | 15 |
| Medium | 3 | 5 | 15 |
| Simpelt | 1 | 4 | 4 |
| Funktion Totalpoint | 34 | ||
| Estimat pr. point | 5 | ||
| Samlet anslået indsats (persontimer) | 170 | ||
Den samlede indsats for at færdiggøre "Opret testspecifikationen" er ca. 170 arbejdstimerNår indsatsen er kendt, kan du tildele ressourcer for at bestemme varighed og omkostninger.
Trin C) Estimer omkostningerne for opgaverne
Dette trin besvarer klientens andet spørgsmål — "Hvad koster det?". Antag en gennemsnitlig teampris på $ 5 / timenOvenstående opgave tager 170 timer, så omkostningerne er 170 × $5 = $850Anvend den samme beregning på tværs af alle WBS-opgaver for at nå frem til projektbudgettet.
Jo mere præcist estimatet er, desto bedre kan du styre projektets budget og sikre, at hver en krone giver et afkast.
Metode 2) Trepunktsestimering
Trepunktsestimering er en struktureret teknik, hvor testmanageren angiver tre værdier pr. opgave - optimistisk, højst sandsynligog pessimistisk indsats — baseret på tidligere erfaring eller bedste gæt.
For "Opret testspecifikationen" kan de tre værdier være:
- Bedste tilfælde: 120 arbejdstimer (~15 dage) med et stærkt og erfarent team.
- Mest sandsynligt: 170 arbejdstimer (~21 dage) med et typisk team og ressourcer.
- Værste tilfælde: 200 arbejdstimer (~25 dage) med et mindre erfarent team og ekstra omarbejde.
Beregn det vægtede gennemsnit ved hjælp af PERT-formlen:
Værdien E er vægtet gennemsnit — overskriftsestimatet for "Opret testspecifikationen".
At udtrykke tilliden omkring E, beregn standardafvigelsen:
For Guru99 Bankeksempel estimatet udregnes til 166.6 ± 13.33 arbejdstimer — et interval på 153.33 til 179.99 persontimer.
Trin 4) Valider estimatet
Saml alle opgaveestimater fra WBS'en, og indsend planen til bestyrelsen (administrerende direktør, projektleder, nøgleinteressenter) til gennemgang og godkendelse.
Gennemgå estimatet logisk med bestyrelsen, så de forstår antagelserne, de valgte teknikker og den beredskabsplan, du har indbygget.
Test Estimation Bedste Practices
Tilføj buffertid
Planer overlever sjældent kontakt med virkeligheden – teammedlemmer forlader teamet, test tager længere tid end forventet, afhængigheder glider ud. Byg en rimelig buffer i hvert estimat, så tidsplanen absorberer mindre overraskelser.
Planlæg for ressourcetilgængelighed
Tag højde for planlagt orlov, træning og vagtskifter. Estimater, der ignorerer tilgængelighed, ser godt ud på papiret og leverer ikke altid som forventet.
Brug tidligere erfaringer som reference
Historiske data fra lignende projekter er uvurderlige. Hvis du testede et sammenligneligt websted sidste år, så lær af dets faktiske data, de opståede problemer og den buffer, der reddede dagen.
Hold dig til estimatet – men gennemgå det igen
Skøn er ikke falsketracts; de er de bedste gæt. RevBesøg dem ved kendte milepæle, og juster dem kun, når kravene ændrer sig væsentligt, eller nye oplysninger ændrer billedet. Forhandl enhver ændring med kunden på en transparent måde.
Software Test Estimation skabelon
Download softwaretestestimeringen i Excel (.xlsx)
Andre estimeringsteknikker
Ud over WBS-, funktionspunkts- og trepunktsestimering anvendes adskillige andre teknikker i vid udstrækning:
- Bredbånds Delphi: iterativ konsensusestimering foretaget af et ekspertpanel.
- Use-Case Point-metode: henter indsats fra antallet og kompleksiteten af use cases.
- Procentfordeling: allokerer en fast procentdel af den samlede projektindsats til testning.
- Ad-hoc-metode: ekspertvurdering, når historiske data mangler.
Bottom-Up vs. Top-Down estimering
Et praktisk perspektiv på estimering kan også opdeles i to komplementære strategier:
- Bottom-up-estimering: baseret på opgaver på det laveste niveau i arbejdsmarkedsstrukturen. Flere interessenter, erfarne medarbejdere og bidragydere kombinerer deres tal for at nå frem til en præcis total. Ideelt, når arbejdet er godt forstået.
- Top-down estimering: Klassificerer projektet efter størrelse og kompleksitet og sammenligner det med gennemførte projekter af lignende form. Bruger også gennemsnitlig indsats pr. test sag og skaleres efter det forventede antal sager. Nyttig tidligt i et projekt, når detaljerne er knappe.
De fleste teams blander de to – top-down for overskriftstallet, bottom-up for tillid – og lægger resultatet oven på sofistikerede modeller, når budgetterne retfærdiggør indsatsen.
