Den här artiklen skrev jag 2005 när jag var Testledare på Trygg-Hansa Företagsmarknad.
En ordentlig krav- och dokumentationsgranskning bör göras.
Brister i detta kan leda till mycket stora konsekvenser.
Fel som inte upptäcks i tid riskerar att byggas in i systemet och ju senare
felen hittas desto dyrare blir det att åtgärda dem.
Granskningar gör att vi sparar pengar och leder ofta till att vi kan spendera mindre
tid och pengar på test.
Vad är dokumentgranskning?
- Syftet är att testa dokument för att hitta fel och förbättra kvalitén.
- Ett bra sätt att hitta fel tidigt i projekt.
- Granskning kan tillämpas både på dokumentation och på programkod (kodgranskning = ej kompilerad ännu).
Fördelar med granskning
- Liten investering, stora möjligheter till vinst.
- Granskningar har visat sig vara minst lika effektiva som själva testarbetet.
- Förbättrar lagarbetet.
- Effektivt sätt att sprida kunskaper.
- Snabbare introduktion av nyanställda.
Roller vid granskning av kravspecifikation
- Kravställare.
- Utvecklare.
- Projektledare.
- Testare.
- Testledare.
Förberedelser
- Utse deltagare
– Lagom storlek på gruppen (max 6-8 st.).
– Personerna ska beröras av dokumentet.
– Tillräckligt med tid (sänds ca 2 v innan mötet för påläsning).
- Grundläggande koll av dokumentet
– Dokumentmall.
– Teckensnitt och stavning.
– Uppdaterad innehållsförteckning och sidhänvisningar.
– Röd tråd.
– Nivå och målgrupp.
Kallelse till granskning
- I god tid före granskningsmötet
– Minst 2 veckor före mötet. - Förklara syftet med mötet.
- Beskrivning av arbetet före, under och efter
– Omfattning.
– Krav på förberedelser.
Granskningsmöte
- Genomgång av dokument
– Börja med övergripande struktur.
– Fortsätt avsnitt för avsnitt. - Deltagare ger synpunkter
– Konstruktiv kritik.
– Undvik långa diskussioner. - En person antecknar beslutade ändringar.
- Vid behov av ytterligare utveckling, antecknas detta.
Uppföljning
- Sammanställning av ändringsförslag.
- Uppdatering av dokument.
- Distribution av dokument.
- Ev. ett nytt granskningsmöte.
Framgångsfaktorer
- Rätt information till rätt deltagare inför mötet.
- Undvik långa diskussioner.
- Håll tiderna, både start- och sluttid.
- Genomför grundläggande koll av dokument innan det skickas för granskning.
Sammanfattning
- Granskningar av dokument är en teknik som gör att man hittar fel tidigt.
- Det är ett bra sätt att skapa insyn i projektet.
- Granskning av krav och specifikationer förbättrar testarnas kunskap om systemet.
Checklista för krav
- Beskriver kravet design eller ger förslag till lösningar?
- Beskriver flera krav samma eller liknande behov?
- Kan några krav grupperas ihop?
- Kan något krav delas upp i flera krav?
- Är det möjligt att uppfylla kravet med tillgänglig teknik?
- Är kravet unikt identifierat?
- Är kravet testbart?
- Är termer och begrepp definierade?
- Är kravet självständigt eller måste du/vi undersöka andra krav för att förstå det?
- Går det att tolka kravet på olika sätt?
- Finns redundant (överflödig) information?
- Saknas information?
Checklista för språk
- Alltid, alla, varje, ingen, aldrig
– Tänk på testfall som motsäger kravet. - Definitivt, därför, uppenbarligen, således
– Försöker övertyga om att något är givet. - Några, ibland, ofta, vanligen, många, de flesta
– För vaga krav. Man kan inte testa något som är ”ibland”. - Bra, snabb, lagom, billig, liten, stabil, effektiv
– Går inte att mäta, är inte testbara. - Hanteras, processas
– Risk att stora mängder funktionalitet döljs. - Har alla ord samma betydelse för utvecklare och användare?
– Samtidigt, minst, normalt, i genomsnitt, ofta. - Finns det ofullständiga uppräkningar?
– Osv., etc., t.ex.
7 synder vid specificering av krav
- Brus
– Nya termer och begrepp för redan specificerade krav eller annan information. - Tystnad
– Utelämnar information om krav. - Överspecificering
– Beskrivning av lösning i stället för önskad egenskap. - Motsägelse
– Inkonsekvent eller motsägelsefull beskrivning. - Tvetydighet
– Lämnar möjlighet att tolka kravet på olika sätt. - Framåtreferens
– Användning av begrepp som inte definierats tidigare. - Önsketänkande
– Beskrivning av egenskaper som inte är möjliga att genomföra.
Sammanfattning
- Kraven är den enskilt största felkällan.
- Kravhanteringsprocessen behöver innehålla:
1. Stöd för insamling.
2. Strukturering.
3. Prioritering.
4. Dokumentation.
5. Förvaltning.
6. Test.
Man kan även dela ut läsinstruktioner för ökad bredd: tänk att du är administratör för slutanvändarna, tänk prestanda/säkerhet, jämför med övrig arkitektur, titta på konkurrenter o.s.v.
Ett annat knep från Internet är att någon granskar dokumentet bakifrån.
Jag måste dock starkt opponera mot det kategoriska “Går inte att mäta, är inte testbara”. Vaga (eller subjektiva) krav är måhända svåra att verifiera på ett mätbart sätt, men självklart kan man testa och ta fram relevant information!
Syftet med krav och programvaruutveckling är inte att det ska vara lätt för testare att sätta Pass eller Fail.
En sån tumregel riskerar att det blir som det blivit på många ställen; saker som är viktiga står inte med i kraven, för de gick inte att uttrycka på ett objektivt sätt. Typexemplet är väl att testare inte tänker på eller rapporterar användbarhetsproblem, vilket jag tror är viktigt i alla system som används av människor.
Allt som är mätbart är inte viktigt, allt som är viktigt är inte mätbart, lär Einstein ha sagt.