Det viste sig, at workshoppen faktisk var modul 5 (Risk Management) af IIST's certificering for Test Managers (CTM - Certified Test Manager). En lidt interessant og anderledes model - at en konference faktisk indeholder undervisningsmoduler fra et kursus.
Workshoppen dækkede følgende seks områder - defineret i CTM BOK (Certified Test Manager - Book of Knowledge):
- Risk Management & Testing
- Risk Testing Process: Identification
- Risk Testing Process: Analysis
- Risk Testing Process: Response Planning
- Risk Testing Process: Test Strategy Documentation
- Risk Testing Process: Risk Based Reporting
Indledningsvis blev der gjort meget ud af, at få risici opdelt i tre kategorier: Process Risks, Project Risks og Product Risks. De to første risikokategorier håndteres i testplanlægningen, mens Product Risks håndteres i forbindelse med design og afvikling af testen. En fornuftig opdeling, som giver god mening.
Der blev gennemgået en række metoder og teknikker til identification af produktrisici, herunder involvering af interessenterne. Metoderne var bl.a. tjeklister (en med udgangspunkt i de forskellige kvalitetskarakteristika og en med udgangspunkt i nogle generiske produktrisici, som var opsamlet retrospektivt), product assessment med at stille en række spørgsmål til produktet - både ved nyudvikling og forvaltning. Brugen af interessenternes 'benefit' ved produktet blev også inddraget i vurderingen - spændende betragtning. Formuleringen af produktrisici blev også diskuteret, og der blev der taget udgangspunkt i et IF-statement: IF.....det og det sker THEN kan det få denne negative konsekvens eller resultat.
Så kom selve analysen, hvor der skulle sættes rating på konsekvens og sandsynlighed. Når dette skal ske er der selvfølgelig altid denne diskussion om det skal være kvalitativt eller kvantitativt. Jeg har i en årrække været fortaler for den kvalitative (f.eks. HØJ, MEDIUM, LAV) tilgang, idet jeg altid har syntes det var svært at sætte kroner på konsekvensen og en reel sandsynlighed i procent. Alt dette skal jo anvendes til at nå frem til risikoeksponeringen (exposure) - vi havde nogle gode diskussioner, og selvom jeg fik nogle gode eksempler med, så vil jeg nok fortsat hælde mest til den kvalitative vurdering. Men jeg er da blevet mere åben overfor den kvantitative metode - selvom jeg fastholder at det er ofte meget vanskeligt at fastlægge en ÆGTE kvantitativ værdi på konsekvens og sandsynlighed.
Der blev også præsenteret en anden model til prioritering af testen, hvor der blev inddraget kvalitetskarakteristikker og vigtigheden af disse, og så skulle der gives en rating og denne blev vægtet - dette resulterede så i en samlet risiko pr. område. En spændende metode, som jeg vil se om jeg kan få afprøvet fremover.
Så kom vi til 'Reponse Planning', og her blev der stated klart, at formålet med alt dette er 'find important problems early'. Det der blev behandlet her var beslutningen af teststrategien, hvilket overordnet skulle inkludere et 'statement of minimum level of testing for every area of the product' og en beskrivelse af testdybden: Mainstream (normal use), Guerilla testing, Formally planned testing og Planned regression testing. Her blev også omtalt testteknikkerne, og her kunne det godt mærkes, at det var testmanagere og ikke testanalytikere der var flest af i lokalet. Det udviklede sig til en spændende og noget anderledes del af workshoppen. Der kom, for mig, et nyt begreb ind - nemlig 'Incremental Testing'.
Så kom vi til dokumentationsdelen af strategien - og her kom der en række gode eksempler for 'letvægtsmodeller' og skabeloner. En anden god ting var disse ni punkter der skal huskes ved en god teststrategi:
- Testing should be optimized to find important problems fast, rather than finding all problems equal urgency
- Test strategy should focus most effort areas of potential risks, with some effort on low risk areas
- Test strategy should address test platform configuration, how the product will be operated and observed
- Test strategy should be diversified in terms of test techniques and perspectives. Need multiple dimensions of coverage
- Test strategy should specify how test data will be designed and generated
- Test strategy should incorporate reasonable variations (exploratory), nog all pre-specified
- The test schedule should be represented and justified to demonstrate dependencies on progress of development, testability of products, time to report problems and project teams risk assessment
- Try to keep test process off critical path - extend possible parallel testing and finding problems worth fixing faster than developers fix them
- Tight feedback loop with development
Afslutningsvis blev forskellige former og modeller for rapportering af produktrisici præsenteret. Der var et par spændende og nye imellem - og jeg glæder mig til at 'dyrke' dette noget mere, idet der til workshoppen og hører et bibliotek af skabeloner - herunder også til rapportering.
Samlet set en spændende første dag - meget intensivt med en workshop med kun 10 deltagere, men dette har selvfølgelig også den fordel, at man kommer tættere på emnet og diskussionerne.
Ingen kommentarer:
Send en kommentar