men borde vi inte också testa kraven?

Transkript

1 men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST, 24 februari 2011 SQS Software Quality Systems Sweden AB

2 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

3 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

4 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

5 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

6 Introduktion Så här är problemet. SQS Software Quality Systems Sweden AB men borde vi inte också testa kraven? Februari

7 Introduktion SQS Software Quality Systems Sweden AB men borde vi inte också testa kraven? Februari

8 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

9 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

10 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

11 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

12 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

13 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

14 Process Hur ser krav ut? Felrapport En test (automatiserad) SQS Software Quality Systems Sweden AB men borde vi inte också testa kraven? Februari

15 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

16 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

17 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

18 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

19 Testning av krav Kravspecifikationsstandard på programvara IEEE std 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

20 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

21 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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 SQS Software Quality Systems Sweden AB Kista Science Tower Kista Sweden Phone: +46 (0) Fax: +46 (0) info@sqs-nordic.com Internet: Thank you for your attention