software test estimation techniques
Voor het succes van elk project is het inschatten en de juiste uitvoering van een project net zo belangrijk als de ontwikkelingscyclus. Vasthouden aan de inschatting is erg belangrijk om een goede reputatie bij de klant op te bouwen.
Ervaring speelt een grote rol bij het schatten van 'Software Testing Efforts'. Werken aan gevarieerde projecten helpt om een nauwkeurige inschatting van de testcyclus te maken. Het is duidelijk dat je niet zomaar een aantal dagen blindelings kunt besteden aan een testtaak. De testschatting moet realistisch en nauwkeurig zijn.
In dit artikel probeer ik een aantal punten op een zeer eenvoudige manier vast te leggen, die nuttig zijn om een nauwkeurige testschatting voor te bereiden.
Wat je leert:
- Korte beschrijving van het testschattingsproces
- Voorbeelden van testschattingen
- 9 Algemene tips voor het nauwkeurig inschatten van de testtijd
- Gevolgtrekking
- Aanbevolen literatuur
Korte beschrijving van het testschattingsproces
'Schatting is het proces waarbij een schatting of benadering wordt gevonden, een waarde die voor een bepaald doel kan worden gebruikt, zelfs als de invoergegevens onvolledig, onzeker of onstabiel zijn.' [Referentie: Wikipedia
We komen allemaal verschillende taken en plichten en deadlines tegen tijdens ons leven als professionals, nu zijn er twee benaderingen om een oplossing voor een probleem te vinden.
Een eerste benadering is een reactieve benadering, waarbij we proberen een oplossing voor het probleem te vinden, pas nadat het is gearriveerd.
In de tweede benadering die een Proactieve Aanpak genoemd kan worden, waarbij we ons eerst voorbereiden ruim voordat het probleem zich aandient met onze ervaringen uit het verleden en vervolgens met onze ervaringen uit het verleden, proberen we een oplossing te vinden voor de uitdaging wanneer deze zich aandient.
Schatten kan dus worden beschouwd als een techniek die wordt toegepast wanneer we het probleem proactief benaderen.
Zo kan een schatting worden gebruikt om te voorspellen hoeveel tijd en kosten er nodig zijn om een bepaalde taak te voltooien.
Als het testteam eenmaal in staat is om een inschatting te maken van het probleem, is het gemakkelijker voor hen om een oplossing te bedenken die optimaal is voor het betreffende probleem.
De praktijk van het schatten kan dan formeler worden gedefinieerd als een benadering bij benadering van de waarschijnlijke kosten van een werkstuk.
Lees ook 7 factoren die de testschatting van het seleniumautomatiseringsproject beïnvloeden
De basisvereisten van het testschattingsproces
# 1) Inzichten die zijn verzameld door te werken met ervaringen uit het verleden : Het is altijd een goede gewoonte om wat tijd te besteden aan projecten uit het verleden die dezelfde uitdagingen opleverden als het huidige streven.
# 2) De beschikbare documenten of artefacten: De test management repository tools komen binnen handig in dit soort scenario's omdat ze de vereiste- en verduidelijkingsdocumenten opslaan. Deze documenten kunnen door het testteam worden doorverwezen om de reikwijdte van het project duidelijk te omschrijven.
# 3) Veronderstellingen over het soort werk: Werkervaring uit het verleden helpt bij het maken van aannames over het project. Dit is waar het inhuren van ervaren professionals het belangrijkst is.
De testmanagers kunnen de hersenen van deze mensen oppikken 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 baseline: Het testteam moet ook bepalen of de vereisten al dan niet baseline zijn. Als de documenten niet baseline zijn, is het belangrijk om de frequentie van de wijzigingen te bepalen.
# 6) Alle verantwoordelijkheden en afhankelijkheden moeten duidelijk zijn: De organisatie dient duidelijk de rollen en verantwoordelijkheden te omschrijven van alle personen die het schattingsproces zouden uitvoeren.
# 7) Documentatie en tracering van de schattingsrecords: Alle relevante informatie voor het schattingsproces moet worden gedocumenteerd.
# 8) Activiteiten die moeten worden uitgevoerd tijdens het testschattingsproces
- Organiseer het team dat schattingen zou uitvoeren
- Deel het project op in projectfasen en daaropvolgende samenstellende activiteiten
- Bereken de schatting op basis van eerdere projecten en professionele ervaring
- Geef prioriteit aan de mogelijke bedreigingen en bedenk de benaderingen om die risico's te beperken
- Bekijk en documenteer het relevante deel van het werk
- Leg het werk voor aan de relevante belanghebbenden
Meest prominente testschattingstechnieken
Enkele van de belangrijkste technieken voor testschatting zijn:
- Testpunt schatting
- Op werkfase gebaseerde schatting
- Gebruik casuspuntschatting
Hoe en waar we deze technieken gebruiken:
# 1) Schatting van testpunten is een eenvoudige en gemakkelijk te begrijpen schattingstechniek die algemeen wordt gebruikt in het hele spectrum van softwaretests. Iteratieve fasen en eenvoud zijn de belangrijkste kenmerken van deze specifieke techniek.
beste stuurprogrammasoftware voor Windows 10
# 2) Op werkfase gebaseerde schatting 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 voegt het testteam geleidelijk andere fasen toe aan de initiële schatting en komt uiteindelijk met een geschikte schatting.
# 3) Use-Case Puntschattingstechniek 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 softwaretest te bepalen.
Details van de testpuntschattingstechniek
De techniek voor het schatten van testpunten wordt gedaan door de vermelde stappen te volgen:
(De volgende gewichten, die van project tot project kunnen verschillen, kunnen onder dit paradigma worden overwogen - Sommige van deze gewichten zijn het gewicht voor de programmeertaal op basis van de complexiteit van de code, het toepassingsgewicht op basis van het type toepassing en testgewichten die toegewezen op basis van de verschillende fasen van softwaretests.)
Onverwerkte testpunten worden vermenigvuldigd met CWF om de testgrootte in de grootte van het testpunt te verkrijgen.
De productiviteitsfactor geeft de hoeveelheid tijd aan die een testingenieur nodig heeft om het testen van één testpunt te voltooien
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.
- Complexiteit van testvereisten
- Interface met andere vereisten
- Totaal aantal verificatiepunten
- Basislijntestgegevens
We moeten dan gewichtsvectoren overwegen voor elk van de gegevensvariabelen en ze op de volgende manier ordenen.
Correctiefactor = gemiddelde van (product van complexiteitsgewicht en factorgewicht) / 30
Aanpassing testpunt voor testcaseontwerp = totaal testpunt X (1 + correctiefactor voor testcaseontwerp)
beste schoonmaaksoftware voor Windows 7
Aangepast testpunt voor uitvoering testcase = totaal testpunt X (1 + aanpassingsfactor voor uitvoering testcase)
Totaal testpunt (genormaliseerd) X (1 + aanpassingsfactor voor ontwerp / uitvoering testcase) = aangepast testpunt voor ontwerp / uitvoering testcase
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.
Zeg nu Testscenario 1 heeft 5 verwachte testresultaten, testscenario 2 6 verwachte testresultaten, testscenario 3 alleen 2 verwachte testresultaten, testscenario 4 9 verwachte testresultaten, testscenario 5 en 9 verwachte testresultaten, respectievelijk.
Daarom classificeren we de testscenario's in drie klassen, d.w.z. complex, eenvoudig en gematigd op basis van het totale aantal verwachte resultaten dat aanwezig is 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 zouden bestaan uit 4 tot 7 verwachte resultaten.
We classificeren dus testscenario 1 en testscenario 2 als gematigde scenario's, scenario 5 en scenario 6 als complexe en testscenario 3 als eenvoudig.
Op al deze scenario's gaan we nu testpunten toepassen. We passen 5 testpunten toe voor complexe klassen, 3 voor gematigde klassen en 2 voor de eenvoudige scenario's.
We vermenigvuldigen de veronderstelde testpunten met het totale aantal verwachte resultaten in al deze testscenario's. We eindigen dus met de volgende benaderingen.
Scenario 1: 3 testpunten * 5 verwachte testresultaten = Aangepaste testpunten = 25
Scenario 2: 3 testpunten * 6 verwachte testresultaten = Aangepaste testpunten = 30
Scenario 3: 2 testpunten * 2 verwachte testresultaten = Aangepaste testpunten = 4
Scenario 4: 5 testpunten * 9 verwachte testresultaten = Aangepaste testpunten = 45
Scenario 5: 5 testpunten * 9 verwachte testresultaten = Aangepaste testpunten = 45
Gezien het feit dat we 5 persoonsuren moeten aanvragen voor elk aangepast testpunt, krijgen we het volgende geschatte 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
Het totale geschatte persoonsuren is dus: 745 persoonsuren
Gebruik casuspuntschattingsmethode
Use-Case Point-methode is gebaseerd op de use-cases waarbij we de algehele testschattingsinspanning berekenen op basis van de use-cases of de vereisten.
Hier is het gedetailleerde proces van de Use Case-puntschattingsmethode:
Een voorbeeld hiervan is dat we zeggen dat we in een bepaalde vereiste respectievelijk 5 use-cases, use-case 1, use-case 2,…, use-case 5 hebben. Laten we nu eens kijken dat use case 1 uit 6 actoren bestaat, use case 2 uit 15 actoren, use cases 3, 4 en 5, 3, 4 en 5 actoren.
We beschouwen elke use-case waarbij het totale aantal actoren minder dan 5 is als negatief, elke use-case met het totale aantal actoren is gelijk aan of groter dan 5 en minder dan of gelijk aan 10 als positief en elke use-case met meer dan 10 acteurs als uitzonderlijk.
We besluiten om 2 punten toe te kennen aan de uitzonderlijke use cases, 1 aan de positieve en -1 aan de negatieve.
Daarom categoriseren we de use cases 1 en 5 als positief, use case 2 als exceptioneel en use case 3, 4 als negatief op basis van onze bovengenoemde aannames.
Dus de onverwerkte actorgewichten = use case 1 = (totaal aantal actoren) 5 * 1 (het toegewezen punt) = 5. Evenzo
Gebruik geval 2 = 15 * 2 = 30.
Als we het proces herhalen voor de rest van de use-cases, ontvangen we de onbewerkte actorgewichten = 33
Gewicht onbewerkte use case = totaal aantal. van use cases = 5
Onverwerkt use-case-punt = niet-aangepaste actorgewichten + niet-aangepaste use-case-gewicht = 33 + 5 = 38
Verwerkt use case-punt = 38 * [0,65+ (0,01 * 50] = ongeveer 26,7 of 28 persoonsuren
Work-Phase Breakdown Techniek
De techniek voor het afbreken van de werkfase kan in de volgende stappen worden beschreven.
- Verdeel het algehele werk in fasen.
- Begin met de eenvoudigste fase en wijs er een geschatte schattingswaarde aan toe.
- Ga vervolgens verder met het identificeren van de volgende mogelijke fase die kan worden gestart zodra deze fase is voltooid.
- Leid een mogelijke set benaderingswaarden af die op deze fase kunnen worden toegepast en kies de maximale waarde uit alle afgeleide benaderingswaarden.
- Tel de geschatte schattingswaarde op door de waarde van de huidige fase-inspanning op te tellen bij de reeds bestaande waarde.
- Ga door met stap 3 t / m 5 totdat alle fasen die in de eerste stap zijn geïdentificeerd, zijn uitgeput.
- Accepteer de uiteindelijke geschatte waarde als de ultieme waarde.
Stel dat er in een vereiste 5 vereiste fasen zijn. Dus in de beginfase 1 gaan we ervan uit dat de totale benodigde inspanning 35 mensuren is en dan beginnen we aan de volgende fase 2 waarvoor we 4 vergelijkende aannames hebben van respectievelijk 35, 45, 55 en 65.
We kijken dus naar de 65 persoonsuur 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 Person Hours.
Ik geef informatie over - Hoe de testinspanningen voor elke testtaak te schatten, wat ik heb geleerd van mijn ervaring.
hoe json-bestand te openen in windows
9 Algemene tips voor het nauwkeurig inschatten van de testtijd
Factoren die de schatting van softwaretests beïnvloeden en algemene tips om nauwkeurig te schatten:
# 1) Denk aan wat buffertijd
De schatting moet een buffer bevatten. Maar voeg geen buffer toe, dat is niet realistisch. Met een buffer in de schatting kunnen eventuele vertragingen worden opgevangen. Het hebben van een buffer helpt ook om een maximale testdekking te garanderen.
# 2) Overweeg de bugcyclus
De testschatting omvat ook de bugcyclus. De daadwerkelijke testcyclus kan meer dagen duren dan geschat. Om dit te voorkomen, moeten we er rekening mee houden dat de testcyclus afhankelijk is van de stabiliteit van de build. Als de build niet stabiel is, hebben ontwikkelaars mogelijk meer tijd nodig om te repareren en wordt de testcyclus uiteraard automatisch verlengd.
# 3) Beschikbaarheid van alle bronnen voor een geschatte periode
De testschatting moet rekening houden met alle door de teamleden geplande verlof (meestal lange bladeren) in de komende weken of de komende maanden. Dit zorgt ervoor dat de schattingen realistisch zijn.
Bij de schatting moet rekening worden gehouden met een vast aantal bronnen 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 enkele eerdere versies van hetzelfde product zodat u de output kunt vergelijken? Zo ja, dan kan dit uw testtaak een beetje gemakkelijker maken. U moet nadenken over de schatting op basis van uw productversie.
# 5) Schattingen kunnen fout gaan - Bezoek de schattingen dus regelmatig in de beginfase voordat u ze vastlegt.
In de vroege stadia moeten we de testschattingen regelmatig opnieuw bekijken en indien nodig een wijziging aanbrengen. We moeten de schatting niet verlengen als we deze eenmaal hebben bevroren, tenzij er grote veranderingen in de vereisten zijn.
# 6) Denk aan je ervaringen uit het verleden om een oordeel te vellen!
Ervaringen uit eerdere projecten spelen een cruciale rol bij het opstellen van tijdschattingen. We kunnen proberen alle moeilijkheden of problemen te vermijden waarmee we in eerdere projecten werden geconfronteerd. We kunnen analyseren hoe de vorige schattingen waren en hoeveel ze hebben geholpen om het product op tijd te leveren.
# 7) Overweeg de reikwijdte van het project
Weet wat het einddoel van het project is en maak een lijst van alle eindproducten. Factoren waarmee rekening moet worden gehouden bij kleine en grote projecten verschillen sterk.
Het grote project omvat typisch het opzetten van een testbed, het genereren van testdata, testscripts, enz. Daarom moeten de schattingen gebaseerd zijn op al deze factoren. Terwijl in kleine projecten de testcyclus typisch het schrijven, uitvoeren en regresseren van testcases omvat.
# 8) Gaat u belastingtests uitvoeren?
Als u veel tijd moet besteden aan prestatietests, maak dan een schatting. Schattingen voor projecten waarbij belastingtests zijn betrokken, 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 testtaken nauwkeuriger inschatten. Bij het schatten moet men rekening houden met het feit dat niet alle middelen mogelijk hetzelfde productiviteitsniveau opleveren. Sommige mensen kunnen sneller presteren in vergelijking met anderen. Hoewel dit geen belangrijke factor is, draagt het bij aan de totale vertraging in de te leveren producten.
Gevolgtrekking
Softwaretestschatting is de praktijk die de betrokkenheid van ervaren professionals vereist, evenals de introductie van branchebrede best practices zoals testcase-punt en het gebruik van case-point-methoden.
Het is ook belangrijk om een open geest te hebben 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 ”.
Aanbevolen literatuur
- Beste QA-softwaretestservices van SoftwareTestingHelp
- QA Outsourcing Guide: Software Testing Outsourcing Companies
- Alfatesten en bètatesten (een complete gids)
- Perfect Software Testing CV-gids (met Software Tester CV-voorbeeld)
- Software Testing Jobs: een complete gids voor QA-testopdrachten
- Agile schattingstechnieken: een echte schatting in een agile project
- 68 essentiële bronnen om een succesvolle tester te zijn (Mis het niet!)
- Soorten softwaretests: verschillende testtypen met details