Risk Based Testing van pakketsoftware Dennis Janssen Test Research Centre LogicaCMG dennis.janssen@logicacmg.com

Agenda Kenmerken pakket Risico’s pakket implementatie Risk & Requirement Based Testing (RRBT) Teststrategie pakkettesten PRICES model Samenvatting

Kenmerken van een pakket Veel functionaliteit “out of the box” die bij de organisatie past Bij meerdere organisaties geïmplementeerd, dus “proven technology” Beheer en onderhoud door de leverancier Goedkoper dan een maatwerk oplossing Inpasbaar en uitbreidbaar met nieuwe modules en met maatwerk In een “perfecte wereld” komt dit allemaal ten goede aan het resultaat van de organisatie

Dus niet testen??

Risico’s van een pakketimplementatie Het past toch niet helemaal in de bedrijfsvoering Aanpassen processen op pakket Overbodige functionaliteiten Extra maatwerk (en dat wilden we toch niet…) Het past toch niet helemaal in de systeemarchitectuur Inpassen huidige architectuur (passen in keten van systemen) Interfaces Andere data formaten Conversie en omgang historische data Kwaliteit van het pakket is toch wat minder dan verwacht/ beloofd Weinig invloed op de leverancier Zij bepalen wat er in een nieuwe versie komt Zij bepalen wanneer er een nieuwe versie komt (vaak!!!)

Dus toch testen!!!

Risk & Requirement Based Testing Basis voor het uitvoeren van testprojecten In kaart brengen productrisico’s en deze prioriteren Koppelen aan requirements voor volledigheid, maar risico’s zijn leidend Altijd het belangrijkste als eerste getest Uitstekend communicatiemiddel richting business Fysieke vorm van RRBT is de teststrategie

Teststrategie pakkettesten Vertrouwen Match pakket & bedrijfsvoering Invloed Risicomix Risicomix Teststrategie $ $ $ $ $ $ statisch testen indirect testen dynamisch testen

Verdeling teststrategie Statisch testen Al bij pakketselectie Belangrijker dan bij maatwerk Review, audit, toetsen van testscenario’s op eisen organisatie Indirect testen Wat mag je van de vendor verwachten? Vendor visit Opvragen testrapport Meetesten bij vendor, vendor testset aanleveren Dynamisch testen PRICES model

PRICES model Parameters Releases Integration Conversion Enhancements Security Het PRICES model geeft de specifieke aandachtspunten voor het inrichten van een testtraject van een pakketimplementatie op basis van veelvuldig geconstateerde risico’s

PARAMETERS NIET het testen van (basis) functionaliteit WEL het testen van organisatie specifieke instellingen WEL het testen van aangepaste rekenmodules in het pakket (bijvoorbeeld op basis van BASEL-2 implementatie)

RELEASES Veel wijzigingen op pakketsoftware (hot fix, release, full upgrade, etc) Vaak geen invloed op aanleveringen wijzigingen Wijzigingen overslaan geen optie (“must upgrade”) Regressietesten van levensbelang (per release belangrijker) Geautomatiseerde testuitvoering vanwege korte tijd tussen wijzigingen

INTEGRATION Inpassen van pakket in bestaande systeemarchitectuur en bedrijfsprocessen Interfaces testen op technisch en functioneel gebied Data integriteit (koppeling met bestaande systemen & data) Performance aspecten (koppeling met bestaande systemen) Ketentesten

CONVERSION Testen van eenmalig omzetten van gegevens naar pakket Conversieregels (functionaliteit van de conversie) Testen van uitval regels Performance van conversie Proefconversie Reguliere “kleine” conversies bij uitbreiding gebruik pakket

ENHANCHEMENTS (MAATWE|RK) Geen pakketimplementatie zonder maatwerk! Testaanpak gelijk aan het testen van maatwerk software Hoeveel aandacht hiervoor is afhankelijk van prioriteit, complexiteit en omvang van het maatwerk

SECURITY Alleen toegang tot toegestane functioliteiten per functionarisgroep (autorisatie) Opletten voor security patches (denk eens aan Outlook) Afschermen van niet gebruikte functionaliteit

Samenvatting Steeds meer pakketsoftware, testen blijft belangrijk Risico’s als basis voor het testtraject Verdeel de testinspanning over statisch, indirect en dynamisch testen voor het maximale resultaat tegen het minimale budget Gebruik het PRICES model om dynamisch testen verdere invulling te geven