for succes for ethvert projekt er testestimering og korrekt udførelse lige så vigtig som udviklingscyklussen. At holde sig til estimeringen er meget vigtigt for at opbygge et godt omdømme hos kunden.
erfaring spiller en vigtig rolle i estimeringen af “Programmeltestningsindsatsen”. Arbejdet med forskellige projekter hjælper os med at udarbejde en nøjagtig vurdering af testcyklussen.
det er klart, at man ikke bare blindt kan sætte et antal dage til nogen testopgave. Testvurderingen skal være realistisk og nøjagtig.
denne tutorial vil indeholde nogle vigtige pointers, der vil være meget nyttige til at forberede nøjagtig testestimering på en meget enkel måde.
test Estimeringsproces
“estimering er processen med at finde et estimat eller tilnærmelse, som er en værdi, der kan bruges til et eller andet formål, selvom inputdata kan være ufuldstændige, usikre eller ustabile.”
vi støder alle på forskellige opgaver, pligter og deadlines gennem vores liv som fagfolk, nu er der to tilgange til at finde løsningen på et problem.
den første tilgang er en reaktiv tilgang, hvor vi først forsøger at finde en løsning på det aktuelle problem, når det ankommer.
i den anden tilgang, der kan kaldes en proaktiv tilgang, forbereder vi os først godt, før problemet kommer med vores tidligere erfaringer, og derefter med vores tidligere erfaringer forsøger vi at finde en løsning på udfordringen, når den ankommer.
estimering kan således betragtes som en teknik, der anvendes, når vi tager en proaktiv tilgang til problemet.
estimering kan således bruges til at forudsige, hvor meget indsats med hensyn til tid og omkostninger der kræves for at udføre en defineret opgave. Når testteamet er i stand til at foretage et skøn over det aktuelle problem, er det lettere for dem at komme med en løsning, der ville være optimal for det aktuelle problem.
praksis med estimering kan derefter defineres mere formelt som en omtrentlig beregning af de sandsynlige omkostninger ved et stykke arbejde.
Læs også => 7 faktorer, der påvirker Testestimering af Selenautomatiseringsprojekt
grundlæggende forudsætninger
nedenfor er de grundlæggende forudsætninger for Testestimeringsprocessen.
#1) indsigt indsamlet fra at arbejde med tidligere erfaringer: det er altid en god praksis at bruge lidt tid på at huske tidligere projekter, der udgjorde udfordringer svarende til den nuværende indsats ved hånden.
#2) de tilgængelige dokumenter eller artefakter: Test management repository-værktøjerne er nyttige i disse typer scenarier, da de gemmer kravene og afklaringsdokumenterne. Disse dokumenter kan henvises af testteamet for klart at definere projektets omfang.
#3) antagelser om typen af arbejde: tidligere arbejdserfaring hjælper med at tage antagelser om projektet. Det er her ansættelse af erfarne fagfolk betyder mest. Testledere kan vælge hjernen hos disse mennesker for at levere de ønskede resultater.
#4) Beregning af potentielle risici og trusler: Testteamet skal også visualisere de potentielle risici og trusler og faldgruber, som løgnen kan ligge for holdet i fremtiden.
#5) bestemmelse af, om dokumenterne er baselined: testteamet skal også afgøre, om kravene er baselined eller ej. Hvis dokumenterne ikke er baseret, er det vigtigt at bestemme hyppigheden af ændringerne.
#6) Alle ansvarsområder og afhængigheder skal være klare: organisationen skal klart definere roller og ansvar for alle dem, der ville udføre estimeringsprocessen.
#7) dokumentation og sporing af estimeringsposterne: alle relevante oplysninger til estimeringsprocessen skal dokumenteres.
#8) aktiviteter, der skal udføres under testestimeringsprocessen:
- organiser et hold, der udfører skøn.
- dekomponere projektet i projektfaser og efterfølgende konstituerende aktiviteter.
- Beregn estimeringen baseret på tidligere projekter og erhvervserfaring.
- Prioriter mulige trusler og kom med tilgange til at afbøde disse risici.
- gennemgå og dokumentere de relevante dele af arbejdet.
- Indsend arbejdet til de relevante interessenter.
mest fremtrædende Testestimeringsteknikker
nogle af de vigtigste teknikker til testestimering er:
- testpunktsestimering
- Arbejdsfasebaseret estimering
- brug case point estimation
hvordan og hvor bruger vi disse teknikker:
#1) Testpunktsestimering er en enkel og let forståelig estimeringsteknik, der bruges i vid udstrækning på tværs af testspektret. Iterative faser og enkelhed er de vigtigste træk ved denne særlige teknik.
#2) Arbejdsfasebaseret estimering er den estimeringsteknik, der anvendes, hvorved der foretages et gættestimat på en bestemt fase (normalt den korteste og enkleste af faserne), og derefter tilføjer testteamet gradvist andre faser i den indledende estimering og kommer til sidst med en passende estimering.
#3) Brug-Case point estimation teknik er estimeringen af use cases, hvor de ujusterede aktørvægte og ujusterede use case-vægte bruges til at bestemme estimeringen af programmelprøvning.
detaljer om Testpunktsestimeringsteknik
testpunktsestimeringsteknikken udføres ved at følge nedenstående trin:
(følgende vægte, som kan variere fra projekt til projekt, kunne overvejes under dette paradigme – nogle af disse vægte er vægten for programmeringssproget baseret på kodens kompleksitet, applikationsvægt baseret på applikationstypen og testvægte, der tildeles baseret på de forskellige faser af programtestning.)
uforarbejdede testpunkter ganges med CVF for at opnå teststørrelsen i Testpunktets størrelse.
Produktivitetsfaktor angiver, hvor lang tid en testingeniør skal gennemføre testen af et testpunkt.
Testindsats i persontimer beregnes ved at multiplicere Testpunktstørrelsen med Produktivitetsfaktoren.
til beregning af testpunktsestimeringsteknikken overvejer vi følgende variabler.
- prøvningskravets kompleksitet
- grænseflade med andre krav
- samlet antal kontrolpunkter
- Baseline testdata
vi skal derefter overveje vægtvektorer for hver af datavariablerne og organisere dem på følgende måde.
justeringsfaktor = gennemsnit af (produkt af kompleksitetsvægt og faktorvægt) / 30
Justeringspunkt for prøvesagsdesign = samlet prøvningspunkt * (1 + justeringsfaktor for Prøvesagsdesign)
justeret prøvningspunkt for prøvesagsudførelse = samlet prøvningspunkt * (1 + justeringsfaktor for prøvesagsudførelse)
samlet prøvningspunkt (normaliseret) * (1 + justeringsfaktor for prøvningssagsdesign/udførelse) = justeret prøvningspunkt for prøvesagsdesign/udførelse
samlet indsats i Persontimer (PH) = Antal normaliserede testpunkter / produktivitet (i normaliserede testpunkter pr.persontimer)
Test Estimeringseksempler
lad os prøve at anvende ovenstående formulering til en anden praktisk anvendelse.
Antag, at vi ender med et testkrav, hvor vi har 5 testscenarier at teste.
lad os nu sige, at Testscenarie 1 har 5 test forventede resultater, testscenarie 2 har 6 test forventede resultater, testscenarie 3 kun 2 test forventede resultater, testscenarie 4 9 test forventede resultater, testscenarie 5 også 9 test forventede resultater, henholdsvis.
vi klassificerer testscenarierne i tre klasser, dvs.komplekse, enkle og moderate baseret på det samlede antal forventede resultater, der er til stede i disse tre klasser.
komplekse klasser vil have mere end 7 forventede resultater, mens de enkle vil bestå af mindre end 5 forventede resultater, og de moderate scenarier vil bestå af mellem 4 og 7 forventede resultater.
vi klassificerer således testscenarie 1 og testscenarie 2 som moderate scenarier, scenario 5 og scenario 6 som komplekse og testscenarie 3 som enkle.
vi vil nu anvende testpunkter på alle disse scenarier. Vi anvendte 5 testpunkter for komplekse klasser, 3 for moderate og 2 for de enkle scenarier.
vi multiplicerer de antagne testpunkter med det samlede antal forventede resultater i alle disse testscenarier. Så vi ender med følgende tilnærmelser:
Scenario 1: 3 testpunkter * 5 test forventede resultater = justerede testpunkter = 25
Scenario 2: 3 testpunkter * 6 test forventede resultater = justerede testpunkter = 30
Scenario 3: 2 testpunkter * 2 test forventede resultater = justerede testpunkter = 4
Scenario 4: 5 testpunkter * 9 test forventede resultater = justerede testpunkter = 45
Scenario 5: 5 testpunkter * 9 test forventede resultater = justerede testpunkter = 45
så i betragtning af at vi skal ansøge om 5 Person timer for hvert justeret testpunkt, ender vi med at få følgende omtrentlige resultat.
Testscenarie 1: 25 justerede testpunkter * 5 persontimer = 125 persontimer
Testscenarie 2: 30 justerede testpunkter * 5 persontimer = 150 persontimer
Testscenarie 3: 4 justerede testpunkter * 5 persontimer= 20 persontimer
Testscenarie 4: 45 justerede testpunkter * 5 persontimer = 225 persontimer
Testscenarie 5: 45 justerede testpunkter * 5 persontimer = 225 persontimer
så de samlede omtrentlige persontimer er: 745 persontimer
Use Case Point Estimation Method
Use-Case Point Method er baseret på use cases, hvor vi beregner den samlede Testestimeringsindsats baseret på Use Cases eller kravene.
nedenfor er en detaljeret proces af use case point estimation method:
et eksempel på det samme er, at vi i et bestemt krav har 5 use cases, use case 1, use case 2,…, use case 5 henholdsvis. Lad os nu overveje, at use case 1 består af 6 skuespillere, use case 2 består af 15 skuespillere, use cases henholdsvis 3, 4 og 5, 3, 4 og 5 skuespillere.
vi betragter enhver brugssag, der involverer det samlede antal aktører som mindre end 5 som negativ, enhver brugssag med det samlede antal aktører er lig med eller mere end 5 og mindre end eller lig med 10 som positiv og enhver brugssag med mere end 10 aktører som usædvanlig.
vi besluttede at tildele 2 point for de ekstraordinære brugssager, 1 for de positive og -1 for de negative.
således kategoriserer vi use cases 1 og 5 som positive, use case 2 som ekstraordinære og use case 3, 4 som negative henholdsvis baseret på vores ovenfor anførte antagelser.
så de uforarbejdede skuespillervægte = Use case 1 = (Samlet antal aktører) 5 * 1(det tildelte punkt) = 5. Tilsvarende
brug sag 2 = 15 * 2 = 30 .
gentagelse af processen for resten af brugssagerne modtager vi de uforarbejdede skuespillervægte = 33
uforarbejdet brugssag vægt = total nr. af use cases = 5
uforarbejdet use case point = ujusterede aktørvægte + ujusteret use case vægt = 33 + 5 = 38
behandlet brugssag punkt = 38 * = 26.7 eller 28 Person timer ca.
Arbejdsfaseopdelingsteknik
arbejdsfaseopdelingsteknikken kan beskrives i de følgende trin.
- opdel det samlede arbejde i faser.
- Start med den enkleste fase og tildel en omtrentlig estimeringsværdi til den.
- fortsæt derefter med at identificere den næste mulige fase, som kan påbegyndes, når denne fase er afsluttet.
- afled et muligt sæt tilnærmelsesværdier, der kunne anvendes på denne fase, og vælg den maksimale værdi blandt alle de afledte tilnærmelsesværdier.
- opsummerer den tilnærmede estimeringsværdi ved at tilføje den aktuelle faseindsatsestimeringsværdi til den allerede eksisterende værdi.
- fortsæt med trin 3 til 5, indtil alle de faser, der er identificeret i det første trin, er opbrugt.
- Accepter den endelige omtrentlige estimatværdi som den ultimative.
Antag i et krav, at der er 5 krævede faser. I den indledende fase 1 antager vi, at den samlede nødvendige indsats er 35 persontimer, og derefter begynder vi den næste fase 2, som vi har 4 sammenlignende antagelser om henholdsvis 35, 45, 55 og 65.
vi betragter de 65 persontimer, som er den maksimale værdi her. I fase 3 , 4 ,5 kommer vi op med skøn (12 , 33, 43 , 54) , (15 , 10 , 7 , 8) og (henholdsvis 2, 16, 5, 13). Ved at anvende det nævnte princip ender vi med henholdsvis 185 persontimer.
jeg lægger information om – hvordan man estimerer testindsatsen for enhver testopgave, som jeg lærte af min erfaring.
9 Generelle tip til, hvordan man estimerer testtiden nøjagtigt
faktorer, der påvirker estimering af Programmeltest, og generelle tip til estimering nøjagtigt:
#1) Tænk på noget buffertid: estimeringen skal indeholde en vis buffer. Men tilføj ikke en buffer, hvilket ikke er realistisk. At have en buffer i estimeringen gør det muligt for os at klare eventuelle forsinkelser, der måtte opstå. At have en buffer hjælper også med at sikre maksimal testdækning.
#2) Overvej Bugcyklussen: testestimeringen inkluderer også bugcyklussen. Den faktiske testcyklus kan tage flere dage end estimeret.
for at undgå dette bør vi overveje, at testcyklussen afhænger af bygningens stabilitet. Hvis bygningen ikke er stabil, kan udviklere muligvis have brug for mere tid til at ordne det, og selvfølgelig forlænges testcyklussen automatisk.
#3) tilgængelighed af alle ressourcer til estimeret periode: Testestimeringen skal overveje alle de blade, der er planlagt af teammedlemmerne (typisk lange blade) i de næste par uger eller næste par måneder. Dette vil sikre, at estimaterne er realistiske.
estimeringen bør overveje et bestemt antal ressourcer til en testcyklus. Hvis antallet af ressourcer reduceres, skal estimeringen genbesøges og opdateres i overensstemmelse hermed.
#4) Kan Vi Lave Parallel Test? Har du nogen tidligere versioner af det samme produkt, så du kan sammenligne output? Hvis ja, så kan dette gøre din testopgave lidt lettere. Du bør tænke på estimeringen baseret på din produktversion.
#5) estimater kan gå galt – så besøg estimaterne ofte i indledende faser, før du begår det: i de tidlige stadier bør vi ofte besøge test estimaterne og foretage ændringer, hvis det er nødvendigt. Vi bør ikke udvide estimeringen, når vi fryser den, medmindre der er store ændringer i kravene.
#6) tænk på din tidligere erfaring til at gøre domme! Erfaringer fra tidligere projekter spiller en afgørende rolle, mens man forbereder tidsestimater. Vi kan forsøge at undgå alle de vanskeligheder eller problemer, der blev konfronteret med tidligere projekter. Vi kan analysere, hvordan de tidligere estimater var, og hvor meget de hjalp med at levere produktet til tiden.
#7) overvej projektets omfang: ved, hvad der er projektets slutmål og liste over alle de endelige leverancer. Faktorer, der skal overvejes for små og store projekter, adskiller sig meget. Store projekter inkluderer typisk opsætning af en testbed, generering af testdata, testskripter osv.
derfor bør estimaterne baseres på alle disse faktorer. Mens der for små projekter typisk inkluderer testcyklussen skrivning, udførelse og regression.
#8) skal du udføre belastningstest? Hvis du har brug for at lægge betydelig tid i ydelsestest, skal du estimere i overensstemmelse hermed. Estimater for projekter, der involverer belastningstest, bør overvejes forskelligt.
#9) Kender Du Dit Team? Hvis du kender styrker og svagheder hos personer, der arbejder i dit team, kan du estimere testopgaver mere præcist. Mens man estimerer, bør man overveje det faktum, at ikke alle ressourcer kan give det samme produktivitetsniveau.
nogle mennesker kan udføre hurtigere sammenlignet med andre. Selvom dette ikke er en vigtig faktor, tilføjer det den samlede forsinkelse i leverancer.
konklusion
estimering af Programmeltest er en praksis, der kræver involvering af erfarne fagfolk samt introduktion af branchens bedste praksis som test case point og use case point metoder.
det er også vigtigt at vedtage et åbent sind til tilpasning af de krævede processer. Den vellykkede implementering af disse processer fører til en samlet forbedring af testprocessen.
dette er en gæsteartikel af forfatteren “N. Sandhya Rani”.
Sidst Opdateret: 29. November 2021
