Transcript …… men borde vi inte också testa kraven?

…… men borde vi inte
också testa kraven?
Robert Bornelind
Presentation på SAST, 24 februari 2011
SQS Software Quality Systems Sweden AB
Innehåll
Introduktion
Kvalitet, tid och kostnad
Process
Testning av krav
Tidig design av testfall
Avslut
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 2
Introduktion
Mål
Identifiera när test av krav bör utföras i den överordnade planen
Identifiera ”bra” krav som kan användas för testning i praktiken
Utföra test av krav och använda hjälpmedel
Minska utvecklingskostnader
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 3
Introduktion
Utmaningen för alla projekt som utvecklar programvara
Hur får man bort fel som har
införts?
Hur minskar man de risker som
felen innebär för produkten?
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 4
Introduktion
Tolka krav
Krav:
1. Upphängd med flera linor
2. Kunna ta last
3. Kan röras fritt
4. Tillverkad av lövträ
5. Väderbeständig
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 5
Introduktion
Så här är problemet….
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 6
Introduktion
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 7
Introduktion
Typiskt scenario
Felen införs under krav och design faserna
Kraven godkända av verksamheten
men har inte tillräcklig med detaljer för utveckling- och
test-disciplinerna
Kraven inte godkända av utveckling- och test-disciplinerna
Projekt som är ”offshore” eller ”outsourced” förlitar sig på att
dokumentationen är tillräcklig
Fel upptäcks inte eller avlägsnas inte förrän i senare skeden
i mjukvarans utveckling:
Byggen eller Enhetstestning
System / integration / icke-funktionell / End-to-end testning
Acceptanstestning
Projekt förbrukar tid och ansträngning för att rätta till problem
Kravdokumentation och lösningsförslag genomgår sällan en
noggrann granskning
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 8
Innehåll
Introduktion
Kvalitet, tid och kostnad
Process
Testning av krav
Tidig design av testfall
Avslut
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 9
Kvalitet, tid och kostnad
Felens införande och borttagning
Source: Six Sigma Software Metrics Part 2, by David L. Hallowell
Granskning av krav och design samt kodgranskning upptäcker fel närmare där
felen infördes, vilket flyttar kurvan där felen upptäckts åt vänster där tiden för
åtgärd är kortare och kostnaden är lägre.
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 10
Kvalitet, tid och kostnad
Ökande kostnad för rättning av fel
Ökande kostnader genom programvaruutvecklingens livscykel
Källa: StickyMinds.com, Calculating the Economics of Inspections by Ed Weller
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 11
Kvalitet, tid och kostnad
Granska tidigt
Tidigt test (granskning)
Hjälper till att sänka den slutliga kostnaden för utveckling
Kraven styr hela utvecklingssekvensen
Viktigt att se till att de är
Riktiga
Kompletta
Konsekventa
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 12
Innehåll
Introduktion
Kvalitet, tid och kostnad
Process
Testning av krav
Tidig design av testfall
Avslut
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 13
Process
Hur ser krav ut?
Felrapport
En test
(automatiserad)
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 14
Process
Statisk testning
Granskningstekniker
Statisk testning
Dynamisk testning
Statisk analys
Acceptanstest
Affärskrav
Kravtestning
System
specifikation
Design
Tidig testdesign
specifikation
Kodning
Systemtest
Integrationstest
Komponenttest
Tid
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 15
Innehåll
Introduktion
Kvalitet, tid och kostnad
Process
Testning av krav
Tidig design av testfall
Avslut
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 16
Testning av krav
Men först ….. Granskningstyper
Från SSTB’s kursplan för Certifierad testare grundnivå
Informell granskning
ingen formell process
billigt sätt att uppnå en viss nytta
Genomgång
mötet leds av författaren
lärande, ge förståelse, hitta defekter
Teknisk granskning
mötet leds av moderator
diskussioner, beslutsfattande, utvärdering av alternativ, hitta defekter, lösa tekniska
problem, kontroll av överensstämmelse med specifikationer och standarder
Inspektion
mötet leds av utbildad moderator
formell process
hitta defekter
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 17
Testning av krav
Definition
Testning av krav
hitta kravrelaterade fel så tidigt som möjligt
baseras på frågor uppdelade i områden
vägleder utvärderaren att identifiera fel
frågorna besvaras med ”ja” eller ”nej”
baseras på sunt förnuft och standarder
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 18
Testning av krav
Kravspecifikationsstandard på programvara
IEEE std 830-1998
Rekommenderad praxis för kravspecifikationen på programvara
Korrekt;
Alla krav är något som programvaran ska uppfylla
Otvetydig;
Varje krav har endast en tolkning
Komplett;
Alla väsentliga krav. Alla realiserbara kategorier av indata.
Definition av alla termer och måttenheter
Överensstämmande; Inga delar av enskilda krav står i konflikt
Rankad;
Varje krav har en ”identifierare” som kan ange betydelse/prioritering
Verifierbarhet;
Varje krav är verifierbart
Modifierbar;
Strukturen på kraven är sådan att eventuella ändringar kan göras
Spårbarhet;
Ursprunget är tydligt för alla krav
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 19
Testning av krav
10 kravtester
10 kravtester från “An early start to testing: How to test requirements”*
Intyga att kravspecifikationen är en godtagbar beskrivning av systemet
Kraven testas enligt följande kriterier
Gör kraven mätbara
Sammanhang och överensstämmelse
Fullständighet
Relevans
Krav eller lösning?
Intressenters värdering
Spårbarhet
Ordning i en oordnad värld
*) by Suzanne Robertson, The Atlantic Systems Guild Ltd, London
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 20
Testning av krav
10 kravtester – Gör kraven mätbara
Krav skall ha ett kvalitativt mätetal
Lösningar som uppfyller mätetalet godkänns
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 21
Testning av krav
10 kravtester – Sammanhang och överensstämmelse
Varje krav skall tolkas på samma sätt
av varje person som läser det
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 22
Testning av krav
10 kravtester – Fullständighet
Var säker på att kravspecifikation innehåller alla krav som är kända
Medvetna krav
Problem som det nya systemet/programvaran måste lösa
Omedvetna krav
Redan lösta i det befintliga systemet/programvaran
Oanade krav
Skulle vara ett krav om vi visste att det var möjligt eller hade kommit på det
Kravtest 4
Är sammanhanget för kraven stort nog att täcka allt
som vi måste förstå?
Kravtest 5
Har vi frågat berörda parter om medvetna, omedvetna
och oanade krav?
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 23
Testning av krav
10 kravtester – Relevans
Kravinsamling
Irrelevanta krav – ett resultat av att inte förstå målet
"Bara utifall vi behöver det"-krav
Tycker att det är ett krav
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 24
Testning av krav
10 kravtester – Krav eller lösning?
Lösningsförslag förväxlas med krav
Man uppfattar inte det verkliga kravet
Den slutliga lösningen kanske inte är så bra som den borde vara
Arkitekter/designers utvärderar inte alla tänkbara sätt att uppfylla kravet
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 25
Testning av krav
10 kravtester – Intressenters värdering
Förstå värdet/nyttan som intressenterna har på varje krav
Använd den informationen för att avgöra prioriteringar
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 26
Testning av krav
10 kravtester – Spårbarhet
Kunna bevisa att systemet/programvaran uppfyller de specificerade kraven
Behovet av att identifiera varje krav och att spåra det genom utvecklingsfasen
Behov av att kartlägga de ursprungliga kraven med avseende på test
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 27
Testning av krav
10 kravtester – Ordning i en oordnad värld
Att tänka på
Beroenden mellan krav
Förstå påverkan av ett krav på andra krav
Dela upp kraven i hanterbara grupper
Interna beroenden mellan kraven i varje grupp
Beroenden mellan grupperna
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 28
Testning av krav
10 kravtester – Exempel på rapport
Område
Mätbar
Kravtest nummer
Test 1
Test 2
Test 3
Test 4
Har varje krav ett
kvalitativt mätetal
som kan användas
för att testa om
lösningen uppfyller
kravet?
Innehåller
specifikationen en
definition av varje
viktig fackterm som
används i texten?
Stämmer varje
referens till en
definierad fackterm
överens med sin
definition?
Är sammanhanget
för kraven stort nog
att täcka allt som vi
måste förstå?
Fråga/test
Krav
Krav
nr
Sammanhang och överensstämmelse
Fullständighet
Test 5
Har vi frågat
berörda parter om
medvetet,
omedvetet och
oanade krav?
Svara på alla frågorna med "j" eller "n"
1
j
j
j
n
n
2
j
j
j
j
n
3
n
j
j
n
4
n
j
j
n
n
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 29
Innehåll
Introduktion
Kvalitet, tid och kostnad
Process
Testning av krav
Tidig design av testfall
Avslut
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 30
Tidig testdesign
Koncept
Under arbetet med att analysera kraven
kommer testdesign identifiera problem (fel) i kraven
Detta beror på att testare måste
läsa och förstå kraven för att identifiera vilka tester som krävs
skapa aktiviteter för att utföra testerna
definiera de förväntade resultaten
Tidig testdesign kräver att testaren förstår syftet med kravet
hindrar dem från att bara hitta problem med stavning och format
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 31
Innehåll
Introduktion
Kvalitet, tid och kostnad
Process
Testning av krav
Tidig design av testfall
Avslut
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 32
Avslut
Definiera acceptanskriterier
Utför kravtestning
mot definierade mätbara acceptanskriterier och standarder
Definiera acceptanskriterier
innan kraven börjar formuleras
Informera kravanalytiker
så de är medvetna om den förväntade
kvalitetsbedömningen
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 33
Avslut
Definiera acceptanskriterier i workshop
Workshop med kravanalytiker
så de kan uttala sig om acceptanskriterierna
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 34
Avslut
Fördelar med acceptanskriterier
Mätbara acceptanskriterier för kraven
tydligare för kravanalytiker vad de måste producera och till vilken kvalitet
Framtagandet av kraven påskyndas
minskar mängden omarbete då kraven får en bra kvalitet från början
© SQS Software Quality Systems Sweden AB | …… men borde vi inte också testa kraven? | Februari 2011 | 35
SQS Software Quality Systems
Sweden AB
Kista Science Tower | 164 51 Kista | Sweden
Phone: +46 (0) 8 590 045 80 | Fax: +46 (0) 8 590 320 70
E-Mail: [email protected]
Internet: www.sqs-nordic.com | www.sqs-group.com
Thank you for your attention