men borde vi inte också testa kraven? Robert Bornelind

Transkript

1 men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST 15 års jubileum 14 oktober 2010 SQS Software Quality Systems Nordic

2 Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av krav Tidig design av testfall Avslut SQS Software Quality Systems Testa krav, 14 oktober 2010 Page 2

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 Testa krav, 14 oktober 2010 Page 3

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 Testa krav, 14 oktober 2010 Page 4

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 Testa krav, 14 oktober 2010 Page 5

6 Introduktion Så här är problemet. SQS Software Quality Systems Testa krav, 14 oktober 2010 Page 6

7 Activity 2(b): High level definition of Requirements Process SQS Software Quality Systems Testa krav, 14 oktober 2010 Page 7

8 Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av krav Tidig design av testfall Avslut SQS Software Quality Systems Testa krav, 14 oktober 2010 Page 8

9 Kvalitet, tid och kostnad Felens införande och borttagning Source: Six Sigma Software Metrics Part 2, by David L. Hallowell Granskning och testning av krav 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 Testa krav, 14 oktober 2010 Page 9

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 Testa krav, 14 oktober 2010 Page 10

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 Testa krav, 14 oktober 2010 Page 11

12 Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av krav Tidig design av testfall Avslut SQS Software Quality Systems Testa krav, 14 oktober 2010 Page 12

13 Process Hur ser krav ut? Felrapport En test (automatiserad) SQS Software Quality Systems Testa krav, 14 oktober 2010 Page 13

14 Process Statisk testning Granskningstekniker Statisk testning Dynamisk testning Statisk analys Affärskrav Acceptanstest Kravtestning System specifikation Design specifikation Systemtest Integrationstest Tidig testdesign Kodning Komponenttest Tid SQS Software Quality Systems Testa krav, 14 oktober 2010 Page 14

15 Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av krav Tidig design av testfall Avslut SQS Software Quality Systems Testa krav, 14 oktober 2010 Page 15

16 Testning av krav Definition Testning av krav hitta kravrelaterade fel så tidigt som möjligt baseras på frågor uppdelade i områden Vägledning för att identifiera fel frågorna besvaras med ja eller nej baseras på sunt förnuft och standarder SQS Software Quality Systems Testa krav, 14 oktober 2010 Page 16

17 Testning av krav Kravspecifikationsstandard på programvara IEEE std Rekommenderad praxis för kravspecifikationen på programvara Korrekt; Otvetydig; Komplett; 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 Överensstämmande; Inga delar av enskilda krav står i konflikt Rankad; Verifierbarhet; Modifierbar; Spårbarhet; 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 Testa krav, 14 oktober 2010 Page 17

18 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 Testa krav, 14 oktober 2010 Page 18

19 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 Testa krav, 14 oktober 2010 Page 19

20 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 Testa krav, 14 oktober 2010 Page 20

21 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 Testa krav, 14 oktober 2010 Page 21

22 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 Testa krav, 14 oktober 2010 Page 22

23 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 *) Frågan ändrad jämfört med original SQS Software Quality Systems Testa krav, 14 oktober 2010 Page 23

24 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 Testa krav, 14 oktober 2010 Page 24

25 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 Testa krav, 14 oktober 2010 Page 25

26 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 Testa krav, 14 oktober 2010 Page 26

27 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 Har varje krav ett kvalitativt mätetal som Innehåller specifikationen Stämmer varje referens till en Är sammanhanget för kraven stort nog att Har vi frågat berörda parter om medvetet, Fråga/test kan användas för att en definition av definierad täcka allt som vi omedvetet och oanade testa om lösningen varje viktig fackterm överens måste förstå? krav? uppfyller kravet? fackterm som används i texten? med sin definition? 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 Testa krav, 14 oktober 2010 Page 27

28 Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av krav Tidig design av testfall Avslut SQS Software Quality Systems Testa krav, 14 oktober 2010 Page 28

29 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 Testa krav, 14 oktober 2010 Page 29

30 Innehåll Introduktion Kvalitet, tid och kostnad Process Granskningstekniker Testning av krav Tidig design av testfall Avslut SQS Software Quality Systems Testa krav, 14 oktober 2010 Page 30

31 Avslut Validering av krav första steget. Definiera Acceptanskriterier Test av krav bör göras mot definierade mätbara acceptanskriterier och standarder Kriterier skall vara framtagna innan kraven börjar formuleras Kravanalytiker skall meddelas så de är medvetna om den förväntade kvalitetsbedömningen Workshop angående Acceptanskriterier En workshop kan genomföras med kravanalytiker så de kan uttala sig om acceptanskriterierna Påskynda leveransen av kravdokument En effekt av att ha mätbara acceptanskriterier för kraven är att det blir mycket tydligt för kravanalytiker vad de måste producera och till vilken kvalitet Detta bidrar till att påskynda framtagandet av kraven och minskar mängden omarbete då kraven får en bra kvalitet från början SQS Software Quality Systems Testa krav, 14 oktober 2010 Page 31

32 SQS Software Quality Systems Nordic Kista Science Tower Kista Sweden Phone: +46 (0) Fax: +46 (0) Internet: Frågor