Klicka här för att ladda ned artikeln med alla illustrationer i PDF- format.

Det går inte att testa sig till kvalitet i efterhand -- kvalitet bygger man upp genom träget arbete under hela utvecklingsarbetet. Detta innebär bland annat att det inte räcker med att konstruktionstesta enbart på systemnivå, man bör genomföra konstruktionstester även på lägre nivåer. Faktum är att man under utvecklingen av ett stort/komplext system bör göra en hel serie av konstruktionstester, fördelade på de olika nivåerna i konstruktionens struktur. För att detta skall kunna genomföras på ett bra sätt måste man i förväg lägga upp en teststrategi och sedan utgående från denna i god tid planera hela testarbetet tillsammans med övriga utvecklingsaktiviteter.

Inte allt om test
Syftet med denna artikel är huvudsakligen att uppmuntra till att testa på flera nivåer i systemarkitekturen än bara systemnivån (högsta nivån) under utvecklingen av ett system. Att testa på flera nivåer sparar tid och pengar genom att man då kan finna och avlägsna defekter så tidigt som möjligt. I artikeln identifieras och beskrivs ett antal tester som bör övervägas under utvecklingen. Vidare understryks vikten av att så tidigt som möjligt försöka överblicka och planera dessa tester. Artikeln har inte ambitionen att uttömmande beskriva ämnet test och ger sålunda inga detaljer om hur dessa tester skall förberedas, genomföras, stödjas, dokumenteras och rapporteras -- det är en annan historia.

Testa på flera nivåer
I princip kan man under utvecklingsarbetet testa på alla nivåer i systemarkitekturen men det är långtifrån alltid praktiskt att göra så. Här nedan identifierar jag sålunda tester som man under utvecklingsarbetet skulle kunna (men inte alltid måste) genomföra för ett system som är uppbyggt i tre nivåer enligt fig 1; enhetsnivå, delsystemnivå och systemnivå. I stället för enheter och delsystem används ibland andra benämningar, exempelvis block och moduler men det spelar ingen roll -- principen är densamma.

Black box test white box test
Man talar ibland om Black Box Test och White Box Test som två angreppsätt vid test. Betydelsen av dessa är (i korthet):
Black Box Test innebär test mot kravspecifikation (eller liknande dokument) varvid testföremålet ses som en "svart låda" vars innehåll är helt okänt. Vid testen iakttas endast gränssnitten in till och ut från testföremålet. Testföremålets innehåll manipuleras ej. Black Box Test används för systemtest och delsystemtest. White Box Test innebär test mot konstruktionsbeskrivning (eller liknande dokument), varvid testföremålet ses som en "genomskinlig låda" vars innehåll är känt. Vid testen iakttas såväl gränssnitten in till och ut från testföremålet som testföremålets innehåll. Testföremålets innehåll kan fritt manipuleras. White Box Test används för systemintegrationstest och delsystemintegrationstest. Vid enhetstest används både Black Box Test och White Box Test.

Acceptanstest
Acceptanstest görs på det färdiga, kompletta systemet. Acceptanstest görs normalt av systemets mottagare (beställare/kund) och det kan då diskuteras huruvida denna test skall räknas till utvecklingsaktiviteterna eller ej. Det förekommer dock att acceptanstesten görs av den organisation som gjort utvecklingen eller görs som ett samarbete mellan utvecklingsorganisationen och systemets mottagare (beställaren/kunden). Resultatet från acceptanstest utgör formellt underlag för beslut om eventuellt godkännande av mottaget system. Syftet är att verifiera att de förväntningar som beställaren/kunden (egentligen; användare) har på systemet uppfylls.

Täckningen bestäms av beställaren/kunden. För beställaren av ett system är det viktigt att noggrant definiera innehållet i acceptanstesten, eftersom godkännande vid acceptanstest ju i praktiken ofta innebär godkännande av mottagen leverans -- kanske till och med godkännande av hela produkten.

Systemtest
Systemtest utförs på det färdiga, kompletta systemet. Krav på uppfyllande av myndigheters rekommendationer, standarder, lagar och förordningar antas här ingå som en delmängd i systemkravspecifikationen; det innebär att vissa applikationsspecifika typer av tester (exempelvis EMC-verifiering, personsäkerhetstester, nättester och kliniska tester) här ses som en delmängd av systemtest. Inom vissa organisationer hanteras i stället dessa typer av tester separerade från systemtest -- det är inget problem; kalla dem vad ni vill, hantera dem hur ni vill, huvudsaken är att de också blir gjorda. Resultatet från systemtest utgör formellt underlag för beslut om eventuell frisläppning/leverans av systemet från utvecklingsorganisationen till beställare/ kund.

Syfte:
• Verifiera att systemet uppfyller samtliga testbara krav i systemkravspecifikationen.
• Verifiera att systemets användardokumentation är korrekt i sig samt att systemets beteende överensstämmer med vad som beskrivs i användardokumentationen.
Täckning åtminstone:
• Alla funktioner/användningsfall som statuerats i systemkravspecifikationen skall exerceras uttömmande för systemet.
• Alla egenskaper som statuerats i systemkravspecifikationen (prestanda, robusthet, säkerhet) skall bekräftas för systemet.
• Varje signifikant utmärkande drag (ankomstfrekvenser, format, värden och beroenden) hos indata till systemet skall testas åtminstone en gång.
• Varje moment eller förfaringssätt beskrivet i systemets användardokumentation skall exerceras uttömmande.

Systemintegrationstest
Blanda inte ihop installation med integration. Installationen av systemet i samband med systemtesten skall verifiera att systemet verkligen går att installera (av beställaren/kundens användare eller leverantörens installatörer). Detta bör dock verkligen inte vara första gången som delsystemen samkörs, då riskerar systemtesten att "torpederas" av integrationsproblem. Avsätt i stället tid och resurser för att göra en separat systemintegrationstest och ta hand om eventuella integrationsproblem där innan systemtesten påbörjas! Till skillnad från systemtest kan systemintegrationstest vara mindre formell och tillåta mera interaktiv felsökning/ rättning. Integration brukar ofta innebära att oväntade problem "dyker upp", så avsätt ordentligt med tid för integrationsarbete redan från början. Syfte:
• Verifiera att systemet fungerar i enighet med vad som beskrivits i systemkonstruktionsbeskrivningen eller motsvarande dokument.
• Verifiera att systemet fungerar tillräckligt bra för att det skall vara meningsfullt att gå vidare till systemtesten.
Täckning åtminstone:
• Varje tillstånd och tillståndsövergång hos systemet (om sådana finnes men inte har statuerats i systemkravspecifikationen) skall testas åtminstone en gång så långt detta är praktiskt.
• Alla gränssnitt mellan delsystem skall exerceras.
• Varje tillstånd och tillståndsövergångar hos kommunikationsprotokoll (om sådana finnes) i gränssnitten mellan delsystem skall testas åtminstone en gång så långt detta är praktiskt.
• Varje signifikant utmärkande drag (ankomstfrekvenser, format, värden och beroenden) hos data utväxlat mellan delsystem skall testas åtminstone en gång.
Delsystemtester
Delsystemtest utförs för vart och ett av delsystemen innan dessa integreras till det kompletta systemet. Resultatet från delsystemtest utgör formellt underlag för beslut om eventuell frisläppning av delsystemet för användning inom den egna utvecklingsorganisationen (samma delsystem används ju ibland i flera olika system/produkter). Syfte:
• Verifiera att varje delsystem uppfyller samtliga testbara krav i respektive delsystemkravspecifikation eller motsvarande dokument (om sådant dokument finnes -- det bör finnas ett sådant dokument i de fall då delsystemet skall kunna frisläppas separat).
Täckning åtminstone:
• Alla funktioner som statuerats i delsystemkravspecifikationen eller beskrivits i motsvarande dokument (om sådant dokument finnes) skall exerceras uttömmande för delsystemet.
• Alla egenskaper (prestanda, robusthet, säkerhet) som statuerats i delsystemkravspecifikationen eller motsvarande dokument (om sådant dokument finnes) skall bekräftas för delsystemet.
• Varje signifikant utmärkande drag (ankomstfrekvenser, format, värden och beroenden) hos indata till delsystemet skall testas åtminstone en gång.
Delsystemintegrationstester
På samma sätt som att installationen av systemet inför systemtesten inte bör vara första gången som delsystemen samkörs, så bör inte delsystemtesterna vara första gången som enheterna samkörs. Då riskerar även delsystemtesterna att torpederas av integrationsproblem. Avsätt därför tid och resurser för att göra en separat delsystemintegrationstest för varje delsystem! Till skillnad från delsystemtest så kan delsystemintegrationstest tillåtas vara mindre formell och tillåta mera interaktiv felsökning/rättning. Återigen -- integration brukar ofta innebära att oväntade problem dyker upp, så avsätt ordentligt med tid för integrationsarbete redan från början. Syfte:
• För varje delsystem verifiera att delsystemet i fråga fungerar i enighet med vad som beskrivits i delsystemkonstruktionsbeskrivningen eller motsvarande dokument.
•För varje delsystem verifiera att delsystemet i fråga fungerar tillräckligt bra för att det skall vara meningsfullt att gå vidare till delsystemtesterna.
Täckning åtminstone:
• För varje delsystem skall varje tillstånd och tillståndsövergång (om sådana finnes men inte har statuerats i delsystemkravspecifikationen) testas åtminstone en gång så långt detta är praktiskt.
•För varje delsystem skall alla interna gränssnitt (inuti det aktuella delsystemet) exerceras.
• För varje delsystem skall varje tillstånd och tillståndsövergång hos kommunikationsprotokoll (om sådana finnes) i de interna gränssnitten (inuti det aktuella delsystemet) testas åtminstone en gång så långt detta är praktiskt.
• För varje delsystem skall varje signifikant utmärkande drag (ankomstfrekvenser, format, värden och beroenden) hos data utväxlat internt inom det aktuella delsystemet testas åtminstone en gång.

Enhetstester
Enhetstest utförs för varje i delsystemen ingående enhet innan dessa integreras till respektive delsystem. Enhetstest kan sägas bestå av både en formell och en mindre formell del. Resultatet från den formella delen av en enhetstest utgör underlag för beslut om eventuell frisläppning av enheten för användning inom den egna utvecklingsorganisationen (samma enhet används ju ibland i flera olika system/produkter). Den mindre formella delen som tillåter mera interaktiv felsökning/rättning skall vara avklarad innan den formella delen genomförs. Syfte:
• För varje enhet verifiera att enheten i fråga uppfyller samtliga testbara krav i motsvarande enhetskravspecifikation eller motsvarande dokument (ifall något sådant dokument existerar, vilket faktiskt är ganska ovanligt -- det bör dock finnas ett sådant dokument i de fall då enheten skall kunna frisläppas separat).
• För varje enhet verifiera att enheten i fråga fungerar i enighet med vad som beskrivits i enhetskonstruktionsbeskrivningen -- eller motsvarande dokument; exempelvis för programvara redovisas ibland motsvarande information istället i form av kommentarfält i källkoden.
Täckning åtminstone:
• För varje enhet skall alla funktioner exerceras uttömmande.
• För varje enhet skall varje signifikant utmärkande drag (ankomstfrekvenser, format, värden och beroenden) hos indata till enheten testas åtminstone en gång.
• För varje enhet skall varje intern funktionsmekanism testas åtminstone en gång.
För rena programvaruenheter innebär detta att enhetstesten för var och en av dessa skall konstrueras så att:
• Varje instruktion i programvarans kod skall exekveras åtminstone en gång
• Varje villkorlig instruktion i programvarans kod skall exekveras åtminstone en gång i varje möjlig riktning
• Varje tillåtet tillstånd och tillståndsövergång skall testas åtminstone en gång så långt detta är praktiskt.
För rena maskinvaruenheter innebär detta att enhetstesten för var och en av dessa skall konstrueras så att:
• Varje observerbar dynamisk nod inuti enheten skall byta signalnivå åtminstone en gång.
• Varje observerbar statisk nod inuti enheten observeras med avseende på korrekt signalnivå åtminstone en gång.
• Varje tillåtet tillstånd och tillståndsövergång bör testas åtminstone en gång -- så långt detta är praktiskt, om det ens är möjligt.

Lägg upp en teststrategi
Det kan sålunda bli ganska många tester för ett stort/komplext system. Skall organisationen klara detta måste testarbetet planeras väl. Försök att så tidigt som möjligt överblicka den tänkbara omfattningen av alla testaktiviteter. För att kunna göra det måste man först identifiera alla enskilda delresultat och/eller leverabler som kan testas separat.

Utgående från den preliminära systemstrukturen så kan man börja skissa på en preliminär integrationsstrategi (hur enheter integreras till delsystem och hur dessa delsystem sedan integreras till komplett system) på vilken sedan en preliminär teststrategi (vilka typer av tester som kan göras på varje enskilt delresultat och/eller leverabel) baseras.

Integration kan här betyda exempelvis programvara som integreras med annan programvara, maskinvara som integreras med annan maskinvara, programvara som integreras med maskinvara eller inbyggt system som integreras med annat inbyggt system.

Prioritera
Nu när den tänkbara omfattningen av testarbetet börjar inses måste man fråga sig ärligt; hur mycket av detta klarar vi av? Vad är realistiskt? Utifrån svaret på dessa frågor prioriteras viktiga tester upp och eventuella överflödiga tester prioriteras bort. Det är viktigt att man analyserar och försöker förebygga de risker som eventuella bortprioriteringar kan medföra. Tänk på att tid och kostnader som sparas genom sänkt ambitionsnivå för test på lägre nivåer kan "dyka upp" senare igen som otrevliga överraskningar, exempelvis genom att integration och/ eller tester på högre nivåer inte går att genomföra därför att vissa enheter fungerar alltför dåligt.

Prioritera aldrig bort systemtest; utöka/förstärk istället systemtesten ifall många andra bortprioriteringar av tester gjorts. Men tro inte därför att systemtest kan ersätta andra tester! Vissa typer av defekter är mycket svåra att upptäcka vid en systemtest eftersom det kan krävas komplicerade procedurer (om det ens är möjligt) för att i en systemtest täcka och isolera funktioner som ligger "djupt inbäddade" i ett delsystem eller en enhet; sådana funktioner täcks enklare vid test på lägre nivå. I sådana fall kan det paradoxalt nog vara tidsbesparande att genomföra kompletterande tester på lägre nivå.

Delegera
När man så beslutat vilka tester som skall genomföras så delegeras förberedelser för och genomförandet av dessa tester till lämpliga personer. Se i detta sammanhang inte "testfolket" som något slags B-lag (dom som "blivit över" får sköta testerna); låt i stället gärna dom mest kreativa medarbetarna deltaga åtminstone i testförberedelserna. En mycket viktig regel i detta sammanhang är dock att ingen skall testa sitt eget arbete eftersom vi människor har en tendens att vara "blinda för våra egna fel"!

Det är viktigt att klart och tydligt statuera vem/vilka som ansvarar för respektive test och att följa upp framstegen regelbundet. Informera därför fortlöpande alla medarbetare om vad som gäller; vad skall göras, när skall det göras, vem skall göra det och hur långt har vi kommit hittills.

Avsätt resurser tidigt
Test tar tid och kostar pengar. Avsätt därför resurser för test samtidigt som resurser för övriga utvecklingsarbetet bokas och försvara dem sedan kompromisslöst. När det längre fram under utvecklingsarbetet blir ont om tid (det blir det oftast förr eller senare) brukar testaktiviteterna vara bland de första som prioriteras ner/bort; till exempel genom att bara få den tid som till äventyrs "blir över" efter att konstruktörerna gjort sitt. I ett tidspressat läge är det lättare att få behålla redan beviljade resurser än att införskaffa nya icke förutsedda. Av detta inser man att testaktiviteterna måste planeras samtidigt med utvecklingsarbetet i övrigt (och definitivt inte först när utvecklingen redan börjar bli klar).

Förbered tidigt
Ju tidigare under utvecklingsarbetet en defekt i konstruktionen upptäcks desto mindre kostar det att upptäcka defekten och desto mindre indirekta kostnader (problem) hinner defekten orsaka. Många konstruktionsdefekter brukar upptäckas redan under testförberedelserna så ju tidigare testförberedelserna startar desto tidigare börjar upptäckandet av defekter.

En förutsättning för bra testförberedelser är att de dokument som man skall testa mot finns framtagna. För Black Box Test är det kravspecifikation man testar mot och för White Box Test är det konstruktionsbeskrivning man testar mot. Alltså måste dessa dokument framställas så snart som möjligt (och definitivt inte "i efterskott", framåt slutet av utvecklingsarbetet) för att skapa förutsättningar för bra testförberedelser. Att vid testförberedelserna tvingas hålla ständiga "korsförhör" med konstruktörerna på grund av att dokumenten man skall testa mot inte finns framtagna resulterar lätt i att testerna blir dåliga och försenade!

Speciellt viktigt är det att tidigt börja förbereda sådana tester som skall upprepas många gånger (typ; regressionstester) och därför skall automatiseras. Detta eftersom automatiseringen i sig oftast kräver extra resurser (ett eller flera testsystem kanske måste utvecklas/byggas parallellt med systemutvecklingen) vilka dock tjänas in flerfaldigt när testerna sedan genomförs många gånger. Bevaka helst testfolkets intressen redan vid uppställningen av systemkraven (Är kraven testbara? Behövs krav på "extra" funktionalitet för att underlätta/möjliggöra test?).

Producera också
Denna artikel behandlar enbart de tester som genomförs under utvecklingen av ett system i syfte att avlägsna eventuella defekter som under utvecklingsarbetet "råkat" införas i systemet. Oftast så skall systemet sedan också (re)produceras på ett eller annat sätt och eftersom även produktionsarbetet kan "råka" införa defekter i systemet så behöver man genomföra tester även under produktionsarbetet. Produktionstester behöver ofta automatiseras vilket innebär att man, om inte utrustning för detta kan köpas färdig, måste utveckla teststationer till produktionslinorna.

Ibland kan kanske produktionsavdelningen "ärva" hela eller delar av vissa konstruktionstester men ofta handlar det om att skapa helt nya tester -- eftersom produktstrukturen inte nödvändigtvis är densamma som systemstrukturen så blir integrationsstrategin (och därmed teststrategin) ofta annorlunda än under utvecklingsarbetet. Men det är en annan historia.