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 Affärskrav Acceptanstest Kravtestning System specifikation Systemtest Tidig testdesign Design specifikation Integrationstest Kodning 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; Otvetydig; Komplett; Överensstämmande; Rankad; Verifierbarhet; Modifierbar; Spårbarhet; Alla krav är något som programvaran ska uppfylla Varje krav har endast en tolkning Alla väsentliga krav. Alla realiserbara kategorier av indata. Definition av alla termer och måttenheter Inga delar av enskilda krav står i konflikt Varje krav har en identifierare som kan ange betydelse/prioritering Varje krav är verifierbart Strukturen på kraven är sådan att eventuella ändringar kan göras 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 Sammanhang och överensstämmelse Fullständighet Kravtest nummer Test 1 Test 2 Test 3 Test 4 Test 5 Fråga/test 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å? Har vi frågat berörda parter om medvetet, omedvetet och oanade krav? Krav Krav nr 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 n j 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: info@sqs-nordic.com Internet: www.sqs-nordic.com www.sqs-group.com Thank you for your attention