ivan.nilsson@liu.se
Version 2015-04-07
Lektion – inspektioner som testredskap
-----------------------------------------------------------------------------------1. Introduktion.
Inspektioner och kodtestning är två av de aktiviteter, som ingår i arbetet med kvalitetssäkring
(quality assurance) av ett program eller system. Artefakten som ska granskas och vad som är målet
med granskningen påverkar hur granskningen bäst genomförs och dokumenteras. Det innebär, att
varje granskningstillfälle är en ny, unik situation. Därför görs en anpassning av ett standardförfarande
till det aktuella granskningstillfället. Det är en av anledningarna till att du kommer att upptäcka, att det
är svårt att hitta en mall, som är färdig att användas och kan användas i nästan alla situationer. Den
tillgängliga litteraturen beskriver riktlinjer och tumregler baserade på best practices (en situation liknande den när det gäller metodlitteratur för systemutveckling). De handlar mest om vad som ska
granskas och olika infallsvinklar på det.
Lektionen ägnas åt att utföra två inspektioner av typen Fagan Inspection. Det är en av de mer kända
metoderna för att granska artefakter, t.ex. kravspecifikationer och programkod (skrivbordstestning).
2. Bakgrundsmaterial, teori.
Du behöver ha skaffat dig en viss bakgrundsinformation för att förstå vad det är som görs under ett inspektionsmöte (lektionstillället och senare under laborationen).
2.1 Inspektion enligt Fagan.
Läs gärna länkarna i den ordning som de presenteras.

Kompakt om Fagan Inspection: http://en.wikipedia.org/wiki/Fagan_inspection och därför en bra
och snabb start.
Observera de två dokumenten som är skrivna av Fagan själv (bland länkarna nederst på webbsidan - PDF-filer). Det är två tidiga artiklar om inspektioner.

Från IEEE en artikel om viktiga milstolpar i disciplinen Software Engineering, varav en är inspektioner: http://www.stevemcconnell.com/ieeesoftware/eic09.htm.
Samtliga milstolpar är viktiga att känna till för en systemutvecklare. Artikeln sätter Faganinspektionerna i ett större sammanhang.

En av flera utvärderingar av Faganinspektioner
https://www.ida.liu.se/~TDDC90/labs/lab-papers/doolan91.pdf
En lättläst artikel i vetenskaplig stil. På ett universitet är det viktigt att skaffa sig vana av att läsa
och utvärdera denna typ av artiklar. Det är också viktigt att utveckla ett sunt kritiskt tänkande, vilket här handlar om att ta reda på vilka som är de praktiska resultaten av att använda denna inspektionsmetod.
Denna artikel kan tyckas vara ensidigt positiv. Sådant ska man vara försiktig med, eftersom jämförelse med andra metoder saknas. Det finns fler varav vissa tyder på att det finns problem förknippade med att använda denna metod, men även konkurrerande metoder har sina problem. Kontentan av dem är, att olika metoder passar för olika situationer. Leta gärna upp en eller ett par artiklar
som jämför denna metod med en eller flera andra metoder (finns gott om dem på Internet). En viktig lärdom av den här typen av artiklar är att du ser vad som anses vara viktigt att utvärdera.
ivan.nilsson@liu.se

Version 2015-04-07
Ett kapitel ur en handbok framställd av teknologstudenterna på IDA från tidigt 1990-tal till 2007 i
kursen PUMPRO (gruppstorleken var åtminstone sju personer):
http://www.ida.liu.se/~TDDC02/RUT/aktuella-pdf/10.2-Reviews_According_to_Fagan-v5.0-en.pdf
(handboken kallas RUT, se under Extra material nedan
Detta kapitel är vår gemensamma bas för lektionsövningen och laborationen. Tänk på att det ingår i en tjock handbok, som är skriven av studenter för efterföljande års studenter och att innehållet är baserat på flera års litteratursökningar och egna erfarenheter i detta omfattande programmeringsprojekt. (I detta dokument används benämningen RUT-Fagan för att hänvisa till detta kapitel.)
Om det är något i detta kapitel som nu är nyfiken på eller vill ha en annan förklaring på, sök gärna
upp alternativ på Internet eller i böcker på biblioteket. Det finns mycket skrivet om detta.
Extra material för dig som är allmänt nyfiken:
 Fagans företag: http://www.mfagan.com/ (på länken Courses finns några intressanta dokument).
 En historisk översikt om Faganinspektioner: http://mfagan.com/pdfs/software_pioneers.pdf.
 Handboken RUT ingick i denna teknologkurs på IDA: http://www.ida.liu.se/~TDDC02/.
Den utgörs av flera dokument med föreskrifter, råd och mallar för olika moment i ett programutvecklingsprojekt.
En lista med alla dokumenten i RUT: http://www.ida.liu.se/~TDDC02/RUT/aktuella-pdf/.
 NASA är en av de organisationer, som har använt sig av Faganinspektioner. Detta är en detaljerad specifikation på hur den skulle utföras hos dem: http://www.cs.nott.ac.uk/~cah/G53QAT/fi.pdf.
 Stockholms stad:
http://www.stockholm.se/PageFiles/527497/St%c3%b6djande%20dokument/Testhandboken.doc
ivan.nilsson@liu.se
Version 2015-04-07
2.2 Olika infallsvinklar på testning av programkod.
Det finns flera infallsvinklar, när det gäller testning av programkod. De är ofta giltiga samtidigt. Beroende på det förhandenvarande programmet kan olika av dem behöva utföras.

Sammanfattande beskrivning av olika aspketer och metoder, när det gäller kvalitetssäkring av
mjukvara: http://en.wikipedia.org/wiki/Software_testing.
Avsnittet med rubriken Testing methods är intressant för lektionen och laborationen. Studera dess
innehåll. Det ska praktiseras i som en övning under lektionen och som examinationsmoment i
form av laborationen.

En begränsad del från ovanstående på temat Code coverage sammanfattas här med ett litet exempel: http://en.wikipedia.org/wiki/Code_coverage (rubriken Parameter Value Coverage ovan för
bilden med programkoden borde vara något i stil med Example on the coverage criteras).
Studera det. Laborationen går ut på att göra det.
Av länkarna under See also är den till Regression Testing (regressionstestning) den viktigaste för
oss. Det är viktigt att konstruera tester som kan återvändas och dessutom utgörs av exekverbar
kod. Att testa efter att en ändring har gjort, går då snabbt.
Försäkra dig om att du förstår vad som menas med de åtta punkterna under Basic coverage
criteria. Det är synvinklar utifrån vilka testare behöver göra sin granskning och testning.
En webbsida i stil med någon av de två ovanstående är utmärkt som startpunkt för eget utforskande.
Här finns det centrala begreppen samlade. Om du vill veta mer om någon av dem, går det att följa en
länk eller söka efter det på Internet.
Om du vill hitta böcker som skriver om programtestning brukar de flesta som behandla Software Engineering ha någotkapitel om det. Det finns flera sådana böcker hos bibliotektet i B-huset.
1. Använd gärna http://www.ida.liu.se/~TDDC02/RUT/aktuella-pdf/. Kapitel 11 – 14 handlar om olika
faser i utvecklingsprojektets testningsprocess.
Kapitel 11 modultest har underkapitel 11.1 Testprocedur v4.1 en figur som sammanfatar det hela
väl: Figure 1 Testing models.
Lägg märke till frånvaron av praktiska exempel överallt i litteraturen. Det som finns handlar om vad
samt riktlinjer och tumregler.
ivan.nilsson@liu.se
Version 2015-04-07
3. Genomförande av lektionen
Lektionen går ut på att genomföra två Faganinspektioner: den ena på en algoritm och den andra på
programkoden som implementerar denna algoritm.
Vi utgår från tillvägagångssättet i RUT-Fagan.
3.1 Anpassningar av metoden till lektionsformatet.
2. 4.3 Inspection team (RUT-Fagan).
De fyra rollerna finns inte hos oss. Under lektionen utses en person till att vara moderator. De förberedelselser som moderatorn ska göra innan inspektionsmötet görs av lektionsledaren. Författandet av detta dokument är en sådan aktivitet.
Läs på om moderatorns uppgift. Det kan bli du som tilldelas rollen.
De tre övriga rollerna finns inte hos oss. De slås samman till rollen inspektör.
3. 4.4 Time table.
Table 1 är svår att förstå. Avses t.ex. 500 timmar?
Inför laborationen kan ni behöva finna något som bättre hjälper er att i förväg bedöma tidsåtgången.
4. 4.5 Efficient inspections.
Frågorna 1 och 2 är viktiga. De styr var inspektionsmötet har sitt fokus och kan bidra till att tiden
används på bästa sätt (utgå från att det alltid råder tidsbrist och kundkontrakt med deadlines och
utlovade produktegenskaper).
Sista stycket om checklistor är värt att ta till sig. (Förresten, när skapade du en checklista senast?
Hur stor nyttoeffekt gav den?)
5. 5 Realization.
Punkterna 1 och 2 görs av lektionsledaren i form av material som du hämtar inför lektionen och
laborationen. Innan mötet har inspektionsdeltagarna fått artefakterna, som ska inspekteras.
Punkt 3: Den viktigaste av alla. Den som inte har gjort en granskning av artefakten innan inspektionsmötet, har inget att bidra med.
Punkt 4: Det är inte nödvändigt med en separat sekreterare. Fagan anser, att det hör till moderatorns uppgift att göra dessa noteringar. Den positiva effekten av detta kan bli, att inspektionen går
framåt i ett tempo som inte är snabbt, men inte för långsamt heller. Ni gör här på det vis som ni
finner lämpligast. Prova gärna båda.
Observera den rekommenderade åtgärden, när någon i gruppen inte har förberett sig. Det är meningslöst att genomföra en inspektion med deltagare som inte har gjort de förberedelser, som ska
ha utförts. I vårt fall kan vi inte skjuta upp lektionen.
Punkt 5 och 6: Hör till laborationen. (Borde nog logiskt sett ha kommit efter punkt 7.)
Notera iakttagelsen i det andra stycket i underkapitel 5.6.
Punkt 7: Vi slopar gruppens interna diskussion på lektionen. Vi gör i stället så att alla presenterar
sina viktigaste resultat.
6. 7 Classification of defects.
Vi använder deras definitioner och numrering av defekterna: 1 minor, 2 major, 3 super-major.
ivan.nilsson@liu.se
Version 2015-04-07
7. 10.2 Solutions to common problems.
Punkt 6 om antal deltagare förklarar varför ni ska vara 4 – 5 personer i grupperna (förutom att
Fagan skriver att det är fyra).
8. 12 Internal documents.
Utvalda kommentarer från grupper i PUMPRO. Där finns något att tänka på. Varför upprepa misstag, som nämns här?
Notera påpekandena om varför det är viktigt att göra peer reviews, innan den formella inspektionen. Notera också hur ofta det framförs, att checklistor är till god hjälp.
9. 14 Examples…
o Inspections records (sid 22). Användbart som försättsblad till inspektionsprotokoll och annat
material från inspektionsmötet. (Laborationen.)
o Error statistics?
o General checklist (sid 26) och efterföljande checklistor.
Här finns ett rikligt urval av saker som kan kontrolleras under en inspektion. Kom ihåg, att en
checklista ska innehålla sådant som är relevant för syftet med inspektionen. Allts, först svarar
man på frågan ”vad är vi ute efter med denna inspektion” och sedan skrivs kriterier i checklistan (maximalt 20 – 25 stycken).
Exempel
Syftet är att ”vi vill avgöra om algoritmen ger rätt resultat och rätt beteende i alla möjliga situationer, som kan uppstå”. Den uppmärksamme läsaren noterar, att detta liknar det om Code coverage - kanske kan principerna för den typen av testning användas även i detta fall.
Kriterier till checklistan:
ID
Fråga / kriterium
001
Är alla valsituationer entydigt och tydligt beskrivna?
002
Utförs alltid rätt alternativ i en valsituation?
003
… osv …
Kommentarer
Algoritmen kanske ser ut så här:
6. …
7. Gå till kylskåpet och tag din lunchbox, om den finns där, annars tag mackor och en frukt.
Och skriv en lapp på kylskåpsdörren.
8. …
Detta är inte entydigt för alla, även om texten i sig har tydligt innehåll. Ska personen alltid
skriva lappen på dörren eller är det bara om det inte fanns någon lunchbox och han/hon
tog mackorna och frukten? Ska man tolka det som att lappen bara ska skrivas, om personen tog lunchboxen?
Under inspektionsmöten görs en notering om detta med kommentaren ”mångtydigt” eller
något i den stilen. Oklar vilka alterniven och dithörande handlingar är (ID 002 i checklistan). Eftersom detta kan ha avgörande betydelse på beteendet som helhet, klassas det
som en defekt av typ 2. Moderatorn noterar i inspektionsprotokollet:
Nr
Steg
Felbeskrivning
ID
1
pkt 7
Mångtydigt.
001
Feltyp
2
A
C
ivan.nilsson@liu.se
Version 2015-04-07
Skriva en lapp, står det. Är det något speciellt som måste skrivas på den eller går bra att
skriva ”God morgon sömntutor”? Detta är en kombination av otydlighet och ofullständighet. Typ 2 igen!
Nr
Steg
Felbeskrivning
ID
1
2
pkt 7
pkt 7
Mångtydigt (markering 1)
Vad ska skrivas på lappen?
001
001
002
Feltyp
2
2
A
C
Men vad ska personen göra, om det inte finns någon lunch och inte heller någon macka,
men det finns frukter? Det finns luckor i algoritmen pga att den inte täcker alla situationer
som kan uppstå. Typ2! Eller har vi vår första typ 3? Utförandet av handlingssekvensen
stoppar här, eftersom det inte har angivits vad som ska göras i denna situation, vilket är
allvarligt - ”Äsch, programmet hängde sig igen”, ”CTD ”, ”Åh nej, blå skärmen igen”.
Nr
Steg
Felbeskrivning
ID
1
2
pkt 7
pkt 7
Mångtydigt (markering 1)
Vad ska skrivas på lappen?
3
pkt 7
Ospecificerat om mackor saknas, varianter
på detta. Ingen fortsättning.
001
001
002
001
002
Feltyp
2
2
A
C
2
Den här sortens samband, beroenden och logik rörande val och handlingssekvenser kallar jag för handlingslogik.
o
Inspection reporting form (sid 32; vi kallar det för inspektionsprotokoll).
Vi har denna som utgångspunkt för inspektionsprotokollet. Originalet är gjort i Framemaker version 6 (http://www.ida.liu.se/~TDDC02/RUT/aktuella/ dokument 10.2). Det har konverterats till Word och förenklats för att göra det lättare för dig att modifiera det efter egna
behov (filnamn: inspection_reporting_form.doc).
ivan.nilsson@liu.se
Version 2015-04-07
3.2 Förberedelser.
Den som tänker delta i lektionen ska ha gjort förberedelserna enligt de fyra nedanstående punkterna
(för att upprepa, deltagande är föga meningsfullt annars). Se det som att detta är ett av många inspektionsmöten på ett utvecklingsföretag. Den som är professionell i sin yrkesutövning har alltid gjort
förberedelsearbetet. Tänk på dig själv i en ledande roll: Vad är du intresserad av att få från dina medarbetare och underlydande?
1. Studerat material i kapitel 2 ovan.
2. Förstå vad som ska utföras av de två rollerna moderator och inspektör under en Faganinspektion.
Inspektionsförfarandet föreskriver att en inspektion ska genomföras snabbt och utan diskussioner under ledning av en moderator. Då måste alla ha gjort en egen granskning i förväg, annars fungerar inte
denna process. Därefter diskuterar inspektionsgruppen det som har framkommit, och beslut fattas om
vilka åtgärder som ska vidtas. Därför ska följande två punkter ha genomförts innan lektionstillfället:
3. Lektionsdeltagaren har gjort en egen genomgång av dokumentet rummen_design.doc med checklistan rummen_design_checklista.doc.
Det ska finnas en separat lista med handskrivna anmärkningar, alternativt direkt i dokumentet.
4. Lektionsdeltagaren har gjort en egen genomgång av programkoden i rummen_java.zip med
checklistan rummen_java_checklista.doc.
Filerna kan läsas in i en ordbehandlare och skrivas ut, om du tänker göra en skrivbordstest. Om
du vill provköra också, vilket rekommenderas, importera programfilerna i Netbeans.
Att exekvera programkoden och studera vad som händer, kan ge en bättre förståelse av vad som
händer.
Det ska finnas en separat lista med handskrivna anmärkningar i de utskrivna programfilerna, alternativt tydligt urskiljbara direkt i kodfilerna.
Programkoden finns samlad i filen rummen_JAVA.doc.
Listorna med anmärkningar ska uppvisas vid lektionens början, vilket är ett krav för att få delta i lektionen.
3.3 Lektionspasset
På var och en av de två lektionstimmar görs en inspektion.
 Timme1. Ett dokument som i princip är en beskrivning av en algoritm.
Filnamn: rummen_design.doc (finns som pdf också).
Timme 2: Programkoden för algoritmen från timme 1.
Filnamn: java_rummen.zip (använd Import i Netbeans) eller utskriftsversionen rummen_JAVA.doc.
Avsikten är, är att inspektionen ska börja senast tre minuter efter lektionsstart. Se till att vara inläst på
förfaringssättet.
Kom ihåg: Avsikten är att hitta fel och problem – inte att lösa dem.

Deltagarna delas in i grupper om fyra eller fem personer.
ivan.nilsson@liu.se
Version 2015-04-07

I varje grupp utses en moderator. Om gruppen inte kan bestämma sig snabbt, fattas beslutet av
lektionsledaren.
Den som varit moderator under Timme 1. Under Timme 2 ska det vara andra moderatorer än under Timme 1. Cirka 40 – 50% av deltagarna får alltså prova på rollen av moderator.

Gruppen genomför inspektionen på 25 minuter. Moderatorn går igenom artefakten som ska inspekteras steg för steg. För varje steg talar inspektörerna om de fel eller problem, som de upptäckte under sin individuella granskning av artefakten.

De fem viktigaste punkterna i inspektionsprotokollet skrivs på overhead-plast (plast och pennor
tillhandahålls av lektionsledaren).
Något att fundera på: Hur gör ni för att 4 -5 personer på ett par minuter ska komma fram till detta?

Alla grupperna presenterar och kommenterar overhead-bilden.
Något att fundera på: Vad är väsentligt att kommunicera på denna korta tid?

I mån av tid: Kort gemensam diskussion.
Det är i sin ordning, om lektionsdeltagarna innan lektionstillfället har gjort denna gruppindelning.
Det är i sin ordning, om lektionsdeltagarna efter lektionen delar med sig av sina fullständiga inspektionsprotokoll till varandra. ”Hur mycket såg de andra som vi missade?”
Tumregler hämtade från litteratur om testning och inspektioner:
 Det finns alltid ett fel till, men någon annan än du upptäcker det
 Det kan finnas ett fel som du är ensam om att ha upptäckt.
3.4 Efter lektionspasset.
Laborationen ansluter direkt till underlagen till lektionen. I korthet: Konstruera testfall och med exekvering av koden bevisa att det finns fel, korrigera felet, konstruera testfall och med exekvering av koden
bevisa att den nu fungerar korrekt. Det behövs inspektionsförfarande här också – ett enkelt och bra
redskap för att styra sitt eget arbete.
En detaljerad beskrivning finns i anvisningarna för laborationen.
Att konstruera bra testfall, är en svår konst. Det är vanligt, att litteraturen framhåller att en testkonstruktör behöver mer erfarenhet och större skicklighet än den som har producerat programkoden. Sådant tas upp på laborationen. Arbetet med checklistorna och sättet att tänka, som övades under lektionspasset, är en start för det tänkande som behövs för att skapa programkodstester.