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.
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
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.
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.
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 Kommentarer 001 Är alla valsituationer entydigt och tydligt beskrivna? 002 Utförs alltid rätt alternativ i en valsituation? 003 osv 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 Feltyp 1 pkt 7 Mångtydigt. 001 2 A C
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 Feltyp 1 pkt 7 Mångtydigt (markering 1) 001 2 2 pkt 7 Vad ska skrivas på lappen? 001 2 002 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 Feltyp 1 pkt 7 Mångtydigt (markering 1) 001 2 2 pkt 7 Vad ska skrivas på lappen? 001 2 002 3 pkt 7 Ospecificerat om mackor saknas, varianter 001 2 på detta. Ingen fortsättning. 002 A C 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).
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.
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.