verschillende soorten Schattingstechnieken bij het testen van Software
schatting van softwaretests is een essentiële beheersoperatie die wordt gebruikt om een benaderend tijdsbestek te bepalen dat nodig is om een proces in een gecontroleerde omgeving te starten en af te ronden.
het is cruciaal voor een projectplanning om niet voorbij de tijdslimieten, vastgestelde budgetten en beschikbare middelen te gaan. Een van de meest nuttige taken hier is, het controleren van de middelen in het licht van een inspanning te besteden aan de test.
ingenieurs bij UTOR maken vaak gebruik van verschillende soorten schattingstechnieken tijdens het testen van software. Deze methoden zijn bevestigd als effectief door onze klanten. Daarom zullen we gaan over hen, en onthullen hun specifieke voors en tegens, zodat u op de hoogte bent van hoe ze het beste te implementeren.
Wat is schatting van softwaretests?
schatting van de Softwaretest is een proces om de duur en acties te meten en te beheren die nodig zijn om een volledige test op de software uit te voeren.
tijd en moeite zijn aanzienlijk eenvoudig te berekenen voor kleinschalige opdrachten. Maar voor grotere projecten. er moeten efficiënte strategieën komen, zodat er geen fouten worden gemaakt. Als de middelen voor het testen van dergelijke projecten worden onderschat of overschat, worden ze ontoereikend of worden ze volledig misbruikt.
Hoe Schatten Teams De Middelen Voor Het Testen Van Software?
voordat de test begint, zijn er twee zeer cruciale onzekerheden waarvan alles afhankelijk is en moet worden opgelost tussen de tester en de client. Deze omvatten;
- Wat is de totale Geschatte duur van de volledige procedure?
- wat zijn de totale geraamde kosten van de procedure, uitgedrukt in geld en middelen?
wat wordt geschat?
tijd, middelen, kosten en menselijke vaardigheden worden doorgaans bepaald tijdens de schatting van de tests.
tijd
de effectiviteit van een team wordt gewoonlijk beoordeeld aan de hand van het vermogen om binnen een bepaald tijdsbestek, op of vóór de deadline, te leveren.
na controle van de vereiste standaardduur voor elk deel van het project in kwestie, ontwikkelen de projectmanagers een middel om elk project te plannen.
hij zorgt ervoor dat alles op tijd wordt geleverd. Om deze reden, tijd schatting is een van de essentiële factoren bij het opbouwen van een goede reputatie onder klanten en het hebben van een groot aantal trouwe klanten.
middelen
voordat een project kan worden opgestart, is het verplicht om de beschikbare middelen te controleren, de middelen die moeten worden opgenomen, en aanbevolen vervangingsmiddelen indien sommige niet direct beschikbaar zijn. Zonder dit te controleren, is het zeer waarschijnlijk dat projecten niet zullen worden voltooid voor de deadline.
kosten
bij de voorbereiding van een testproces moet op alle fronten (zowel financieel als niet-financieel) ten volle rekening worden gehouden met het geraamde budget.
de totale kosten moeten in aanmerking worden genomen om rekening te houden met mogelijke uitgaven en ervoor te zorgen dat het project binnen het vastgestelde budget van de klant blijft, en eraan te werken als het niet aan kan.
de genoemde velden zijn allemaal met elkaar verbonden en onderling afhankelijk van elkaar. De duur ervan hangt ook af van de beschikbare instrumenten en het gegeven budget.
in de loop van de tijd werd de procedure voor het schatten van softwaretests uitgevoerd met verschillende processen, waarbij verschillende methoden en instrumenten werden gebruikt die met de tijd zijn vooruitgegaan om dezelfde reden.
de integratie en werking van deze technieken hebben de middelingsprocedure ook een stuk eenvoudiger gemaakt.
soorten Software Testing Schattingstechnieken
er zijn veel schattingen en middelingstechnieken in het algemeen, maar we zullen slechts kijken naar een paar populaire uit de lot van dit artikel.
programme evaluation and review technique (PERT)
in deze techniek worden de taken opgesplitst in 3 subcategorieën om beter na te gaan welke tijd voor de voltooiing moet worden genomen, namelijk;
het optimistische Scenario – O; in dit geval worden de kosten voor de duur, het geld en de middelen voor het project geacht op het hoogste optimale niveau te liggen. Dit betekent dat individuele leden van het QA-Team gezamenlijk op hun best aan het werk gaan, bij de tijd blijven, zonder druk, onvoorspelbare wending van gebeurtenissen of de noodzaak om het werk opnieuw te bekijken en nog steeds geweldig werk te leveren.
het meest waarschijnlijke Scenario-M; hier worden alle dingen in beschouwing genomen; rekening houdend met het vertrouwde werkscenario en rekening houdend met negatieve en positieve mogelijkheden, worden items geschat hoe dit het meest waarschijnlijk zal gebeuren.
het pessimistische Scenario-P; Dit is het meest negatieve scenario dat zou kunnen zijn. Het gemiddelde zal worden bepaald op basis van de veronderstelling dat er ongetwijfeld een negatief resultaat zal worden behandeld in elke fase van de hele test.
Pros van PERT
- het gebruik van deze techniek betekent dat het team werkt met een schatting die alle mogelijke sterfgevallen en beloningen op alle fronten controleert.
- Teams kunnen met een evaluatie komen die vrij dicht bij de werkelijkheid ligt.
- het bereidt de organisaties voor op elk mogelijk resultaat van de build-test wanneer zij elk denkbaar scenario berekenen en zich adequaat voorbereiden om het indien nodig te beteugelen.
Cons of PERT
- wanneer men geconfronteerd wordt met een groter aantal testprojecten, zal het gebruik van deze vorm van raming veel meer tijd vergen om te ondergaan.
- er is een grote kans op onnauwkeurige berekeningen.
- de hier gebruikte waarden zijn nooit constant en kunnen met veel fouten worden voldaan omdat het toch maar een schatting is.
user Case Point (UCP)
wanneer iemand of iets de toepassing in kwestie gebruikt en communiceert, wordt de entiteit als actor geïdentificeerd. De genoemde entiteit is voornamelijk gedocumenteerd in de niet-aanpasbare Use-Case gewichten, die de capaciteit van het proces beïnvloeden.Elke communicatie tussendoor zal de betrokkenheid van iedereen, van aandeelhouders tot individuen in het QA-team, waarborgen door middel van de verschillende sequenties en vastgestelde doelen.
meer dan tien verschillende factoren beïnvloeden hoe ingewikkeld de technische aard van een project is, en ongeveer acht leggen een complexe tol op het milieu. Dit is in overeenstemming met de bevindingen van Gustav Karner.
deze schattingsmethode is gebaseerd op het berekenen van meerdere varianten op basis van de zogenaamde actoren, gewichten van gebruikersgevallen en punten die van invloed zijn op het proces, de techniek en andere factoren.
Ten eerste moeten zij, om dit proces te starten, hun respectieve ingewikkeldheden controleren en het proces beïnvloeden. Vervolgens wordt verdere middeling gedaan door hun formules voor berekening toe te passen.
na controle van de omvang van het project bepalen de betrokkenen de tijd die nodig is voor de volledige voltooiing van het proces. Twee belangrijke manieren om dit te voorkomen zijn:;
volgens de methode van Karner en waarbij elk testgeval wordt beschouwd als een werkweek van 20 uur.
gebruikmakend van de bedrijfsrecordtijd voor de voltooiing van het project, in ieder geval, om statistische gemiddelden te berekenen en de duur van het lopende project te raden.
UCP = niet-Aanpasbare UCP x technische Complexiteitsfactor x milieueffectfactor.
Pros van UCP
- indien u van tevoren moet werken en ruim van tevoren moet plannen, dan is deze schattingsmethode waarschijnlijk beter af omdat het in de beginfase gebeurt en helpt bij het snoeien en goedkeuren van budgetgroottes.
- met behulp van enkele speciale beheersinstrumenten is automatische berekening van schattingen mogelijk, waardoor het beoordelingsteam veel tijd bespaart en het werk vergemakkelijkt.
nadelen van UCP:
- als de projectvereisten niet worden gegeven in user Case points, maakt dat het onmogelijk om deze techniek te gebruiken, en het QA Team zal moeten source voor een andere methode.
- wanneer de UCP ‘ s worden gegeven, en ze zijn niet nauwkeurig of expliciet genoeg, is het zeer waarschijnlijk negatief te eindigen met schattingen verre van reëel omdat deze methode afhangt van niet alleen het geven van case points, maar het geven van duidelijke case points.
Work Breakdown Structure (WBS)
hier wordt de techniek van het schatten van waarden uitgevoerd door het primaire proces in verschillende subcategorieën te verdelen. Een voorspellende berekening van de gemiddelde duur op elke fase begint geleidelijk met een ruw werk aan de eenvoudigere van de partij, dan afstuderen in zowel moeilijkheidsgraad en niveau van correctheid.
na het eerste proces selecteert u de hoogst mogelijke waarde die u bereikt hebt en telt u deze op en krijgt u de uiteindelijke waarde, waarbij u de inspanning en de tijd die nodig is voor elke taak schat.
Pros van WBS
- een voor de hand liggend voordeel van deze methode is dat het gemakkelijker is om elke minuut en noodzakelijke details te herkennen terwijl de arbeid in kleinere bits wordt verdeeld. Dit betekent dat het werk wordt gedaan
- het is altijd grondig en transparant, omdat de conclusies worden getabelleerd voor hetzelfde doel en gemakkelijker tracking.
nadelen van WBS:
- deze aard vereist meestal het wrijven van geesten en teamleden en stakeholders om gebruik te maken van hun externe ervaring.
- veranderingen in specificaties en behoeften van de klant kunnen leiden tot veroudering en het is nodig dat het team dit onderzoekt en volledig evalueert.
Delphi-methode
de Delphi-methode is vrij populair onder testteams wereldwijd. Gegevens van vrijwillige deelnemers worden verzameld en nauwkeurig onderzocht en komen, in geen bepaalde volgorde, tot een overeengekomen conclusie.
elke fase van het onderzoek leidt tot nieuwe of verbeterde gegevensfeedback, die alleen maar bijdraagt aan de verfijning van de definitieve bevindingen met veel verdiend vertrouwen.
gewoonlijk bestaat een team uit niet meer dan tien personen die bijeenkomen om de kritieke kenmerken van het project te bespreken en hun mening te geven over de mogelijke duur van het project.
vervolgens komt het team opnieuw bijeen en deze keer worden de meningen van de eerste datum gedeeld. Dit geeft de leden een andere invalshoek op het project. De standpunten zijn echter niet gelabeld met hun suggesties.
wanneer de teamleden door deze fase heen zijn, zullen zij opnieuw unaniem van gedachten wisselen, en door het verzamelen van meningen wordt rekening gehouden met de nieuwe invalshoek.
dit zal doorgaan totdat iedereen het eens is over dezelfde pagina. Hoewel de gebruikelijke manier van het doen van de Delphi methode, kan deze vorm worden aangepast aan de behoeften en mogelijkheden.
voors van DELPHI
- omdat hier geen unieke formules of apparatuur nodig zijn, is het voor elk team het makkelijkst om te ondergaan, alles wat nodig is is de klantspecificaties en klaar om te gaan.
- de schatting past vrij dicht bij de nauwkeurigheid, aangezien veel professionele standpunten in het proces van vergadering en het delen van ideeën worden overwogen.
nadelen van DELPHI
- hoe gemakkelijk het ook is om te ondergaan, het kan veel productieve tijd in beslag nemen omdat het vaker wel dan niet.
- het is een uitdaging om na de eerste partij vergaderingen met één uitgebreide schatting te komen en meningen te delen, dus het duurt meestal een paar.
- zelfs na zoveel tijd, kunnen de resultaten niet worden gerecycled. Dus voor elk project dat wordt uitgevoerd, wordt het proces opnieuw gestart met de nieuwe vereisten.
samenvattend
in deze blogpost werden vier soorten schattingstechnieken bij het testen van software beoordeeld en werd nagegaan hoe belangrijk deze zijn bij het plannen van een redelijk testbudget.
kunt u na een succesvolle schatting met zekerheid zeggen wat de juiste aanpak is voor het uitbesteden van uw projecten aan bedrijven voor kwaliteitsborging?
hier is een artikel over hoe de beste aanpak te kiezen voor QA outsourcing.
vertel ons welke van deze Testing schatting tactieken u zou implementeren, en wat was uw inzicht?