Först av allt bör vi veta vad baslinje är innan vi förstår vad baslinjetestning är.

Tekniskt sett –

En baslinje är ett formellt dokument som fungerar som ett grunddokument för framtida arbete. På lekmannaspråk kan man säga att man behöver en bas för att bygga en byggnad. Samma sak gäller för test. Vi måste skapa en baslinje, från vilken vidare testning sker. Först och främst är det mycket viktigt att veta att det rör sig om icke-funktionell testning, vilket innebär att den inte har något att göra med testning av en applikations funktionalitet. Snarare testar man dokumentet som lägger en solid grund för det arbete som ska göras i framtiden. Man kan alltså säga att det fungerar som en bas för framtida utveckling, oavsett vad det är. Det kan vara prestanda, utveckling av testfall.

Talking In Terms Of Performance Testing –

Om man ser att prestandan hos applikationen på en viss server med en belastning på 100 användare, om den fungerar bra på servern med en belastning på 100 utan några avbrott eller långsamhet eller nedbrytning och efter att serverns prestanda minskar drastiskt efter att en belastning på mer än 100 användare appliceras på den server som innehåller applikationen. Då kan vi säga att standarden för denna server är 100 användare. Nu kan denna standard jämföras med standardservern och den framtida omfattningen av prestandatester kan definieras.

Låt oss förstå detta med ett annat exempel, anta att version 1 har en svarstid på 2 sekunder och att version 2 har en svarstid på 3 sekunder. När det gäller version 3 fungerar svarstiden på 2 sekunder för version 2 som grund eller baslinje för prestanda för version 3. Vi kan alltså dra slutsatsen att Baseline är ett dokument som används som en bas för jämförelse eller referens för framtida arbete. Det måste finnas något dokument som kan refereras till som ett stabilt slutligt dokument för framtida arbete.

Talking In Terms Of Software Development –

Om vi talar i termer av mjukvaruutveckling finns det ett dokument som kallas Design Document. Det kan vara ett dokument på låg nivå eller ett dokument på hög nivå utifrån vilket utvecklingsarbetena påbörjas. Om vi talar i testtermen, ett dokument som utarbetas av affärsanalytiker som är i kontakt med kunden och ansvarar för att hämta kraven från kunden fungerar som en referenspunkt för kontakt för testarna för att starta utvecklings- och testprocessen. Affärsanalytikern åker till kunden efter att ha tagit ett möte och tar med sig kravet och fyller i det i en särskild mall. Nu diskuterar han kravet med Engagement Manager eller Project Management Manager för att testa kravet och kontrollera dess genomförbarhet. Om de inte är klara över kraven ber de utvecklaren att skapa en prototyp och om de är nöjda överlämnar de kravdokumentet till projektledaren som utarbetar en kravspecifikation för programvara. Ett dokument som utarbetas av en affärsanalytiker kallas Business Requirement Document eller Functional Requirement Specification eller User Requirement Specification eller Business Design Document eller Business Document beroende på vilken terminologi som används i organisationen. Här ser vi alltså att kravtestning görs för att färdigställa kravdokumentet, som fungerar som en grund för utformningsdokument, projektplan och testplan och som utgör grunden för programvaruutveckling och testning. Denna typ av testning kallas baslinjetestning. I denna typ av testning kontrollerar vi om det förberedda dokumentet håller måttet och uppfyller förväntningarna ordentligt eller med andra ord, vi validerar dokumentet och färdigställer det.

När baslinjetestning är utförd och dokumentet för specifikation av programvarans krav är färdigställt, är vi redo att gå vidare och påbörja utvecklings- och testprocessen. För testning kan vi börja förbereda testfall baserat på kravdokumenten. Den största fördelen med Baseline Testing är att vi kan ta bort fel i kraven i det tidiga skedet av Software Development Life Cycle och ta bort så många problem och ansträngningar i ett senare skede och hjälpa oss att leverera projektet med minimalt omarbete och mindre ansträngning.

Talking In Terms Of Software Development Life Cycle Phase –

Som vi vet så minskar mer arbete i den tidiga fasen av Software Development Life Cycle för mycket ansträngning i ett senare skede. För att förstå hur viktigt det är med baslinjetestning måste vi ha en liten förståelse för programvaruutvecklingslivscykeln. Den första fasen är en kravfas där affärsanalytiker samlar in information från kunden och förbereder kravdokument som kallas Business Requirement Document eller Functional Requirement Specification eller User Requirement Specification eller Business Design Document eller Business Document beroende på organisationens använda terminologi. Utifrån kravdokumentet görs en testning av kravdokumentet, som kallas baslinjetestning, och kravet färdigställs, eller vi kan säga att kravet är fryst. När det väl är i nivå med kraven kan man förbereda en specifikation av programvarukraven i analysfasen. I detta dokument förbereder projektledaren, den tekniska chefen eller systemanalytikern en projektplan för hur projektet ska utvecklas. På grundval av SRS-dokumentet utarbetas ett konstruktionsdokument, t.ex. ett högnivåkonstruktionsdokument och ett lågnivåkonstruktionsdokument, som ligger till grund för en annan fas i programvaruutvecklingslivscykeln, t.ex. kodning, testning och leverans.

Antag att baslinjetestningen inte är korrekt utförd och att Business Requirement Document inte är korrekt färdigställt, då kommer SRS som utarbetats baserat på Business Requirement Document inte att vara korrekt och designdokumentet kommer inte heller att vara korrekt, och därför kommer alla utvecklings- och testverksamheter inte att vara enligt kundens förväntningar, eftersom det kan finnas ett litet misstag när man tar fram kravet eller kravet inte var baslinjestyrt på ett korrekt sätt. Från detta kan vi förstå hur viktigt det är med baslinjetestning.

En viktig sak är att det finns en term Baseline som används inom konfigurationshantering, även om innebörden är mer eller mindre densamma där också. Det är relaterat till versionering av dokument där basversionen av dokumentet är färdigställd och den nya versionen av dokumentet släpps per programvaruversion. Men det finns ett litet begrepp om baslinjetestning i konfigurationshantering, eftersom basversionen av alla dokument, oavsett om det är relaterat till utveckling, testning, webbdesign eller något annat dokument som utarbetas i samband med programvaruutveckling, måste granskas ordentligt när det gäller format och innehåll, så att nästa version av dokumentet utarbetas med mindre ansträngning i ett redan korrekt formaterat dokument.

Slutsats:

Därmed ser vi att baslinjetestning är av hur stor betydelse som helst och om och tills kravdokumentet inte valideras ordentligt eller med andra ord, om baslinjetestning inte görs, kommer det att finnas många problem i ett senare skede och ansträngningsutnyttjandet kommer att vara mycket större för att lösa problemen, vilket bara kommer att vara slöseri med ansträngning och tid, och nya krav kommer att tas och måste gå igenom alla faser av programvaruutvecklingens livscykel, för att lösa problemet helt. Så vi kan säga att Baseline Testing löser många problem i ett tidigare skede, minskar kostnader, ansträngning och tid för organisationen i det senare skedet av Software Development Life Cycle.

⇓ Prenumerera på oss ⇓

Om du inte är en regelbunden läsare av den här webbplatsen rekommenderar vi starkt att du registrerar dig för vårt gratis nyhetsbrev!!! Registrera dig genom att ange din e-postadress nedan:

Happy Testing!!!