voor het succes van een project, test schatting en een goede uitvoering is net zo belangrijk als de ontwikkelingscyclus. Vasthouden aan de schatting is erg belangrijk om een goede reputatie op te bouwen met de klant.
ervaring speelt een belangrijke rol bij het schatten van de “Software Test inspanningen”. Werken aan uiteenlopende projecten helpt ons om een nauwkeurige schatting van de testcyclus voor te bereiden.
het is duidelijk dat men niet zomaar een aantal dagen voor een testtaak kan zetten. De schatting van de Test moet realistisch en nauwkeurig zijn.
deze tutorial bevat enkele belangrijke aanwijzingen die zeer nuttig zullen zijn om een nauwkeurige schatting van de test op een zeer eenvoudige manier voor te bereiden.
Test Schattingsproces
” schatting is het proces van het vinden van een schatting, of benadering, die een waarde is die bruikbaar is voor enig doel, zelfs als de inputgegevens onvolledig, onzeker of instabiel kunnen zijn.”
we hebben allemaal te maken met verschillende taken, plichten en deadlines gedurende ons leven als professionals, nu zijn er twee benaderingen om de oplossing voor een probleem te vinden.
de eerste benadering is een reactieve benadering waarbij we proberen een oplossing voor het probleem te vinden pas nadat het is aangekomen.
in de tweede benadering, die een proactieve benadering kan worden genoemd, bereiden we ons eerst goed voor voordat het probleem met onze ervaringen uit het verleden aankomt en vervolgens proberen we met onze ervaringen uit het verleden een oplossing te vinden voor de uitdaging wanneer het aankomt.
schatting kan dus worden beschouwd als een techniek die wordt toegepast wanneer we een proactieve benadering van het probleem nemen.
Zo kan een schatting worden gebruikt om te voorspellen hoeveel inspanning met betrekking tot tijd en kosten nodig zou zijn om een bepaalde taak te voltooien. Zodra het testteam in staat is om een schatting te maken van het probleem bij de hand, dan is het gemakkelijker voor hen om met een oplossing te komen die optimaal zou zijn voor het probleem bij de hand.
de praktijk van schatting kan dan formeler worden gedefinieerd als een benaderende berekening van de waarschijnlijke kosten van een werkstuk.
ook, lees = > 7 factoren die van invloed zijn op de schatting van de test van Selenium Automation Project
basisvereisten
hieronder zijn de basisvereisten voor de schatting van de Test.
#1) inzichten verkregen uit het werken met ervaring uit het verleden: het is altijd een goede praktijk om wat tijd door te brengen, herinnerend aan projecten uit het verleden die uitdagingen vormden die vergelijkbaar zijn met de huidige inspanning.
# 2) de beschikbare documenten of artefacten: De test management repository tools van pas komen in dit soort scenario ‘ s als ze de eisen en verduidelijking documenten op te slaan. Deze documenten kunnen door het testteam worden doorverwezen om de reikwijdte van het project duidelijk te definiëren.
#3) aannames over het soort werk: vroegere werkervaring helpt bij het maken van aannames over het project. Dit is waar het inhuren van ervaren professionals het belangrijkst is. Testmanagers kunnen de hersenen van deze mensen kiezen om de gewenste resultaten te leveren.
# 4) Berekening van potentiële risico ‘ s en bedreigingen: Het testteam moet ook de potentiële risico ‘ s en bedreigingen en valkuilen visualiseren die in de toekomst voor het team kunnen liggen.
# 5) bepalen of de documenten zijn gebaseerd: het testteam moet ook bepalen of de vereisten al dan niet zijn gebaseerd. Als de documenten niet zijn gebaseerd dan is het belangrijk om de frequentie van de veranderingen te bepalen.
# 6) alle verantwoordelijkheden en afhankelijkheden moeten duidelijk zijn: de organisatie moet duidelijk de rollen en verantwoordelijkheden definiëren voor iedereen die het schattingsproces zou uitvoeren.
#7) documentatie en tracking van de ramingsrecords: alle relevante informatie voor het ramingsproces moet worden gedocumenteerd.
# 8) tijdens het schattingsproces van de test uit te voeren activiteiten:
- organiseer een team dat schattingen zal uitvoeren.
- het project opsplitsen in projectfasen en daaropvolgende samenstellende activiteiten.
- Bereken de schatting op basis van eerdere projecten en beroepservaring.
- mogelijke bedreigingen prioriteren en benaderingen bedenken om deze risico ‘ s te beperken.
- de relevante onderdelen van de werkzaamheden te evalueren en te documenteren.
- de werkzaamheden voorleggen aan de relevante belanghebbenden.
meest prominente technieken voor Testschatting
enkele van de belangrijkste technieken voor testschatting zijn::
- schatting van het testpunt
- schatting op basis van de werkfase
- schatting van het casuspunt
hoe en waar gebruiken we deze technieken:
#1) Test Point estimation is een eenvoudige en gemakkelijk te begrijpen schatting techniek die op grote schaal wordt gebruikt in de software testen spectrum. Iteratieve fasen en eenvoud zijn de belangrijkste kenmerken van deze specifieke techniek.
#2) schatting op basis van de werkfase is de schattingstechniek die wordt gebruikt waarbij een schatting wordt gemaakt voor een bepaalde fase (normaal gesproken de kortste en eenvoudigste van de fasen) en vervolgens het testteam geleidelijk aan andere fasen toevoegt aan de initiële schatting en uiteindelijk met een passende schatting komt.
# 3) Use-Case Point estimation technique is de schatting van de use cases waarbij de niet-aangepaste actorgewichten en niet-aangepaste use case-gewichten worden gebruikt om de schatting van de software testing te bepalen.
Details van de Testpuntschattingstechniek
de testpuntschattingstechniek wordt uitgevoerd door de onderstaande stappen te volgen:
(de volgende gewichten, die kunnen variëren van project tot project, kunnen worden overwogen onder dit paradigma – sommige van deze gewichten zijn de gewichten voor de programmeertaal op basis van de complexiteit van de code, toepassing gewicht op basis van het type toepassing en test gewichten die worden toegekend op basis van de verschillende fasen van software testen.)
onverwerkte testpunten worden vermenigvuldigd met CWF om de testgrootte te verkrijgen in de grootte van het testpunt.
de Productiviteitsfactor geeft aan hoeveel tijd een Testingenieur nodig heeft om de test van één testpunt te voltooien.
de Testinspanning in Persoonsuren wordt berekend door de grootte van het testpunt te vermenigvuldigen met de Productiviteitsfactor.
voor de berekening van de testpuntschattingstechniek houden we rekening met de volgende variabelen.
- Test eis complexiteit
- Interface met andere vereisten
- Totaal aantal controle punten
- Baseline test gegevens
vervolgens hebben We nodig om te overwegen gewicht vectoren voor elk van de variabelen en ze organiseren op de volgende wijze.
Adjustment factor = Gemiddelde van (product van de complexiteit van het gewicht en de factor gewicht) / 30
Aanpassing van de Test-Point voor Test-case design = Totaal testpunt X (1 + aanpassingsfactor voor Test-Case design)
Aangepast testpunt voor de Test execution = Totaal testpunt X (1 + aanpassingsfactor voor Test Case uitvoering)
Totale Test Punt (genormaliseerde) X (1 + aanpassingsfactor voor Test Case ontwerp/uitvoering) = Aangepaste Test-Point voor Test Case ontwerp/uitvoering
de Totale inspanning in Persoonsuren ( PH) = Aantal genormaliseerde testpunten / productiviteit (in genormaliseerde testpunten per Persoonsuren)
voorbeelden van Testschattingen
laten we proberen de bovenstaande formulering toe te passen op een ander praktisch gebruik.
stel dat we eindigen met een testvereiste waarbij we 5 testscenario ‘ s hebben om te testen.
laten we zeggen dat testscenario 1 5 verwachte testresultaten heeft, testscenario 2 6 verwachte testresultaten, testscenario 3 slechts 2 verwachte testresultaten, testscenario 4 9 verwachte testresultaten, testscenario 5 Ook 9 verwachte testresultaten.
we classificeren de testscenario ‘ s in drie klassen, d.w.z. complex, eenvoudig en matig op basis van het totale aantal verwachte resultaten in deze drie klassen.
complexe klassen zullen meer dan 7 verwachte resultaten hebben, terwijl de eenvoudige uit minder dan 5 verwachte resultaten zullen bestaan en de gematigde scenario ‘ s uit 4 tot 7 verwachte resultaten zullen bestaan.
we classificeren testscenario 1 en testscenario 2 als gematigde scenario ‘s, scenario 5 en scenario 6 als complexe scenario’ s en testscenario 3 als eenvoudig.
we zullen nu testpunten toepassen op al deze scenario ‘ s. We hebben 5 testpunten toegepast voor complexe klassen, 3 voor gematigde en 2 voor de eenvoudige scenario ‘ s.
we vermenigvuldigen de veronderstelde testpunten met het totale aantal verwachte resultaten in al deze testscenario ‘ s. Dus we eindigen met de volgende benaderingen:
Scenario 1: 3 testpunten * 5 verwachte resultaten van de test = aangepaste testpunten = 25
Scenario 2: 3 testpunten * 6 verwachte resultaten van de test = aangepaste testpunten = 30
Scenario 3: 2 testpunten * 2 verwachte resultaten van de test = aangepaste testpunten = 4
Scenario 4: 5 testpunten * 9 verwachte resultaten van de test = aangepaste testpunten = 45
Scenario 5: 5 testpunten * 9 verwachte resultaten van de test = aangepaste testpunten = 45
aangezien we voor elk aangepast testpunt bijvoorbeeld 5 uur per persoon moeten aanvragen, krijgen we bij benadering het volgende resultaat.
testscenario 1: 25 aangepaste testpunten * 5 Persoonsuren = 125 Persoonsuren
testscenario 2: 30 aangepaste testpunten * 5 Persoonsuren = 150 Persoonsuren
testscenario 3: 4 aangepaste testpunten * 5 Persoonsuren = 20 Persoonsuren
testscenario 4: 45 aangepaste testpunten * 5 Persoonsuren = 225 Persoonsuren
testscenario 5: 45 aangepaste testpunten * 5 Persoonsuren = 225 Persoonsuren
dus de totale geschatte persoonsuren is: 745 Persoonsuren
Use Case Point schattingsmethode
Use Case Point methode is gebaseerd op de use cases waarbij we de totale test schattingsinspanning berekenen op basis van de use cases of de vereisten.
Hieronder is een gedetailleerd proces van de Use case point schattingsmethode:
een voorbeeld van hetzelfde is dat we in een bepaalde eis 5 use cases, use case 1, use case 2,…, use case 5 hebben. Laten we nu overwegen dat use case 1 bestaat uit 6 acteurs, use case 2 bestaat uit 15 acteurs, use cases 3, 4 en 5, 3, 4 en 5 acteurs respectievelijk.
we beschouwen elke use case waarbij het totale aantal actoren minder dan 5 is als negatief, elke use case waarbij het totale aantal actoren gelijk is aan of meer is dan 5 en minder dan of gelijk is aan 10 als positief en elke use case met meer dan 10 actoren als uitzonderlijk.
we hebben besloten om 2 punten toe te wijzen voor de uitzonderlijke use cases, 1 voor de positieve en -1 voor de negatieve.
aldus categoriseren we de use cases 1 en 5 als positief, use case 2 als uitzonderlijk en use case 3, 4 als negatief, respectievelijk op basis van onze hierboven genoemde aannames.
dus de onverwerkte actor gewichten = Use case 1 =(totaal aantal acteurs) 5 * 1 (het toegewezen punt) = 5. Evenzo
Use case 2 = 15 * 2 = 30 .
het proces herhalen voor de rest van de use cases ontvangen we de onverwerkte actor gewichten = 33
onverwerkt use case gewicht = totaal no. van use cases = 5
niet-verwerkt use case point = niet-aangepast actorgewichten + niet-aangepast use case weight = 33 + 5 = 38
verwerkt use case point = 38 * = 26.7 of 28 Persoonsuren ongeveer
Werkfaseafbraaktechniek
de werkfaseafbraaktechniek kan in de volgende stappen worden beschreven.
- de totale werkzaamheden in fasen verdelen.
- begin met de eenvoudigste fase en wijs er een geschatte schattingswaarde aan toe.
- ga dan verder met het identificeren van de volgende mogelijke fase die kan worden begonnen zodra deze fase is voltooid.
- leid een mogelijke reeks van benaderingswaarden af die op deze fase kunnen worden toegepast en kies de maximale waarde uit alle afgeleide benaderingswaarden.
- som de geschatte schattingswaarde op door de huidige schattingswaarde voor de fase toe te voegen aan de reeds bestaande waarde.
- Ga door met de stappen 3 tot en met 5 totdat alle fasen die in de eerste stap zijn geïdentificeerd, zijn uitgeput.
- accepteer de definitieve geschatte schattingswaarde als de uiteindelijke waarde.
stel dat er in een eis 5 vereiste fasen zijn. In de eerste fase 1 gaan we ervan uit dat de totale inspanning 35 persoonsuren bedraagt en dan beginnen we met de volgende fase 2 waarvoor we 4 vergelijkende veronderstellingen hebben van respectievelijk 35, 45, 55 en 65.
we beschouwen de 65 persoonsuren die hier de maximale waarde is. In Fase 3, 4, 5 komen we met schattingen (12 , 33, 43 , 54) , (15 , 10 , 7 , 8) en (2, 16, 5, 13) respectievelijk. Door het toepassen van het genoemde principe komen we uit op respectievelijk 185 Persoonsuren.
Ik geef informatie over-hoe testinspanningen te schatten voor elke testtaak, die ik uit mijn ervaring heb geleerd.
9 algemene Tips om de testtijd nauwkeurig te schatten
factoren die de schatting van de Softwaretest beïnvloeden, en algemene Tips om nauwkeurig te schatten:
#1) Denk aan een buffertijd: de schatting moet een buffer bevatten. Maar voeg geen buffer toe, wat niet realistisch is. Het hebben van een buffer in de schatting stelt ons in staat om te gaan met eventuele vertragingen die kunnen optreden. Het hebben van een buffer helpt ook om maximale testdekking te garanderen.
# 2) overweeg de Bug cyclus: de test schatting omvat ook de bug cyclus. De werkelijke testcyclus kan meer dagen duren dan geraamd.
om dit te voorkomen, moeten we rekening houden met het feit dat de testcyclus afhankelijk is van de stabiliteit van de build. Als de build niet stabiel is, kunnen ontwikkelaars meer tijd nodig hebben om het op te lossen en uiteraard wordt de testcyclus automatisch verlengd.
# 3) beschikbaarheid van alle middelen voor de geraamde periode: Bij de schatting van de test moet rekening worden gehouden met alle door de teamleden geplande bladeren (meestal lange bladeren) in de komende weken of maanden. Dit zal ervoor zorgen dat de schattingen realistisch zijn.
bij de schatting moet rekening worden gehouden met een vast aantal middelen voor een testcyclus. Als het aantal bronnen afneemt, moet de schatting opnieuw worden bezocht en dienovereenkomstig worden bijgewerkt.
# 4) Kunnen We Parallel Testen? Heeft u eerdere versies van hetzelfde product, zodat u de uitvoer kunt vergelijken? Zo ja, dan kan dit uw testtaak een beetje gemakkelijker maken. Je moet nadenken over de schatting op basis van uw product versie.
# 5) schattingen kunnen fout gaan – dus bezoek de schattingen regelmatig in de beginfasen voordat je ze commit: In de beginfasen moeten we de testschattingen regelmatig opnieuw bezoeken en indien nodig wijzigingen aanbrengen. We moeten de schatting niet verlengen zodra we ze bevriezen, tenzij er grote veranderingen in de vereisten zijn.
# 6) denk aan je ervaring uit het verleden om oordelen te maken! Ervaringen uit eerdere projecten spelen een cruciale rol bij het opstellen van tijdschattingen. We kunnen proberen alle moeilijkheden of problemen te vermijden die in eerdere projecten werden ondervonden. We kunnen analyseren hoe de vorige schattingen waren en hoeveel ze hielpen om het product op tijd te leveren.
# 7) overweeg de reikwijdte van het Project: weet wat het einddoel van het project is en lijst van alle eindresultaten. De factoren waarmee rekening moet worden gehouden voor kleine en grote projecten verschillen sterk. Grote projecten omvatten meestal het opzetten van een testbed, het genereren van testgegevens, test scripts, enz.
daarom moeten de schattingen op al deze factoren worden gebaseerd. Terwijl voor kleine projecten, typisch de testcyclus omvat testcase schrijven, uitvoering en regressie.
# 8)gaat u Load Testing uitvoeren? Als je nodig hebt om aanzienlijke tijd te zetten in het testen van de prestaties dan schatting dienovereenkomstig. Schattingen voor projecten waarbij belasting wordt getest, moeten anders worden bekeken.
# 9) Kent U Uw Team? Als u de sterke en zwakke punten kent van personen die in uw team werken, kunt u de testtaken nauwkeuriger inschatten. Bij het schatten moet men rekening houden met het feit dat niet alle middelen hetzelfde productiviteitsniveau kunnen opleveren.
sommige mensen kunnen sneller uitvoeren in vergelijking met anderen. Hoewel dit geen belangrijke factor is, komt het neer op de totale vertraging in deliverables.
conclusie
schatting van de Softwaretest is een praktijk die de betrokkenheid van ervaren professionals vereist, evenals de invoering van industriebrede beste praktijken zoals test case point-en use case point-methoden.
het is ook belangrijk om open te staan voor het aanpassen van de vereiste processen. De succesvolle implementatie van deze processen leidt tot een algehele verbetering van het testproces.
dit is een gastartikel van auteur “N. Sandhya Rani”.
Laatst Bijgewerkt: 29 November 2021
