Risk Based Testing van pakketsoftware
description
Transcript of Risk Based Testing van pakketsoftware
1
Risk Based Testing van pakketsoftware
Dennis Janssen
Test Research Centre LogicaCMG
2
Agenda
• Kenmerken pakket
• Risico’s pakket implementatie
• Risk & Requirement Based Testing (RRBT)
• Teststrategie pakkettesten
• PRICES model
• Samenvatting
3
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
4
Dus niet testen??
5
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!!!)
6
Dus toch testen!!!
7
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
8
Teststrategie pakkettesten
$$
$$
$$
indirect testenstatisch testen dynamisch testen
Teststrategie
VertrouwenMatch pakket &bedrijfsvoering
Invloed
RisicomixRisicomix
9
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
10
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
11
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)
12
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
13
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
14
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
15
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
16
SECURITY
• Alleen toegang tot toegestane functioliteiten per functionarisgroep (autorisatie)
• Opletten voor security patches (denk eens aan Outlook)
• Afschermen van niet gebruikte functionaliteit
17
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