Voreerst moeten we weten dat wat is Baseline alvorens te begrijpen wat Baseline testing is.

Technisch gesproken –

Een baseline is een formeel document dat fungeert als een basis document voor toekomstige werkzaamheden. In lekentaal gesproken, voor het maken van een gebouw heb je een basis nodig. Hetzelfde geldt voor testen. We moeten een baseline maken, van waaruit verder getest wordt. Allereerst is het heel belangrijk om te weten dat dit niet-functioneel testen is, wat betekent dat het niets te maken heeft met het testen van de functionaliteit van een applicatie. Er wordt veeleer een document getest dat een solide basis legt voor het werk dat in de toekomst moet worden gedaan. Er kan dus worden gezegd dat het als basis dient voor toekomstige ontwikkeling, wat die ook moge zijn. Het kan de prestaties, test case development.

Talking In Terms Of Performance Testing –

Als wordt gezien dat de prestaties van de toepassing van een bepaalde server met een belasting van 100 gebruikers, als het prima werkt op de server met een belasting van 100 zonder enige onderbreking of traagheid of storingen en daarna server prestaties drastisch afneemt na een belasting van meer dan 100 gebruikers wordt toegepast op de server met de toepassing. Dan kunnen we zeggen dat de norm voor deze server 100 gebruikers is. Nu kan deze norm worden vergeleken met de standaardserver en kan de toekomstige omvang van prestatietests worden bepaald.

Laten we dit met een ander voorbeeld begrijpen, stel dat release 1 een responstijd van 2 seconden heeft, en release 2 een responstijd van 3 seconden. Voor release 3 fungeert de responstijd van 2 seconden van release 2 als basis of basislijn voor de prestaties van release 3. Hieruit kunnen we dus afleiden dat de basislijn een document is waarnaar wordt verwezen als basis voor vergelijking of referentie voor toekomstig werk. Er moet een document zijn waarnaar kan worden verwezen als een stabiel afgerond document voor toekomstig werk.

Praten in termen van software-ontwikkeling –

Als we praten in termen van software-ontwikkeling, is er een document dat Design Document wordt genoemd. Het kan een Low-Level Document of High-Level Document zijn op basis waarvan de ontwikkeling begint. Als we praten in de testen term, een document opgesteld door Business Analyst die in contact met de klant en is verantwoordelijk voor het ophalen van de eisen van de klant fungeert als een referentiepunt voor contact voor de testers om de ontwikkeling en het testen proces te starten. De Business Analyst gaat naar de klant na het maken van de afspraak en neemt de vereisten op en vult die in een specifieke template in. Nu bespreekt hij het vereiste met de Engagement Manager of Project Management Manager om het vereiste te testen en de haalbaarheid ervan te controleren. Als de eisen niet duidelijk zijn, vragen ze de ontwikkelaar om een prototype te maken en als hij tevreden is, overhandigt hij het document met eisen aan de projectmanager die de Software Requirement Specification opstelt. Een document dat is opgesteld door de Business Analyst wordt Business Requirement Document of Functional Requirement Specification of User Requirement Specification of Business Design Document of Business Document genoemd, afhankelijk van de gebruikte terminologie in de organisatie. Hier zien we dus dat requirement testing wordt gedaan om het Requirement Document af te ronden, dat als basis dient voor het Design Document of Project Plan en Test Plan, en de basis vormt voor Software ontwikkeling en testen. Dit type van testen wordt Baseline testen genoemd. In dit type van testen controleren we of het opgestelde document voldoet aan de verwachtingen of in andere woorden, we valideren het document en finaliseren het.

Nadat de Baseline Testing is gedaan en het Software Requirement Specification document is afgerond, zijn we klaar om verder te gaan en te beginnen met het ontwikkelings- en testproces. Voor het testen, kunnen we beginnen met het voorbereiden van testgevallen gebaseerd op de requirement documenten. Het belangrijkste voordeel van Baseline Testing is dat we fouten kunnen verwijderen in de eisen in de vroege fase van de Software Development Life Cycle en zo veel problemen en inspanning in een later stadium te verwijderen en ons te helpen het project op te leveren met een minimum aan rework en minder inspanning.

Talking In Terms Of Software Development Life Cycle Phase –

Zoals we weten dat meer werk in de vroege fase van de Software Development Life Cycle vermindert te veel inspanning in een later stadium. Om te begrijpen hoe belangrijk Baseline testing is, moeten we een beetje inzicht hebben in de Software Development Life Cycle. De eerste fase is een requirement fase waar de Business Analist informatie verzamelt van de klant en vereistedocumenten opstelt die Business Requirement Document of Functional Requirement Specification of User Requirement Specification of Business Design Document of Business Document worden genoemd, afhankelijk van de gebruikte terminologie in de organisatie. Vanuit het requirement document, wordt het testen van het requirement document gedaan, wat Baseline testing wordt genoemd en de requirement wordt afgerond of we kunnen zeggen dat de requirement wordt bevroren. Zodra het is tot de mark en tot worden beschouwd voor te bereiden Software Requirement Specification in de Analyse fase. In dit document, bereidt de Project Manager of Technisch Manager of Systeemanalist een Project Plan voor over hoe het project zal worden ontwikkeld. Op basis van het SRS document, Design Document zoals High-Level Design Document en Low-Level Design Document wordt voorbereid op basis waarvan een andere fase van de Software Development Life Cycle, zoals Codering, Testen, en Levering wordt uitgevoerd wordt uitgevoerd.

Suppose Baseline Testing is niet goed gedaan en Business Requirement Document is niet goed afgerond, dan SRS voorbereid op basis van Business Requirement Document zal niet goed zijn en Design Document zal ook niet correct zijn en dus alle activiteiten van de ontwikkeling en het testen zal niet volgens de verwachtingen van de klant als er een kleine fout kan zijn bij het nemen van de eis of de eis was niet goed baseline. Hieruit kunnen we begrijpen hoe belangrijk Baseline testing is.

Een belangrijk ding is dat er een term Baseline is die wordt gebruikt in configuration management, hoewel de betekenis daar ook min of meer hetzelfde is. Het is gerelateerd aan versiebeheer van documenten, waarbij de basisversie van het document wordt voltooid en de nieuwe versie van het document wordt vrijgegeven per software release. Maar er is weinig concept van Baseline Testing in Configuration Management, ook omdat Base Version van alle documenten of het nu gaat om Ontwikkeling, Testen, Web ontwerpen of enig ander document opgesteld in relatie tot Software Ontwikkeling, moet goed worden beoordeeld in termen van formaten en inhoud, zodat de volgende versie van het document is voorbereid met minder inspanning in reeds goed geformatteerde document.

Conclusie:

Dus zien we dat Baseline testen is van hoeveel belang en tenzij en totdat de eis Document is niet goed gevalideerd of met andere woorden, als Baseline testen is niet gedaan, zal er veel problemen in latere fase en inspanning gebruik zal veel meer in het oplossen van de problemen die zal gewoon verspilling van moeite en tijd en nieuwe eis zal worden genomen en moet gaan door alle fasen van Software Development Life Cycle, om het probleem op te lossen volledig. Dus, we kunnen zeggen dat Baseline Testing lost veel problemen in een eerder stadium, vermindert de kosten, moeite en tijd voor de organisatie in de latere fase van de Software Development Life Cycle.

⇓ Abonneer ons ⇓

Als u niet regelmatig lezer van deze website dan sterk beveelt u aan om u in te schrijven voor onze gratis e-mail nieuwsbrief! Meld u aan door hieronder uw emailadres in te vullen:

Happy Testing!!!