Risk Based Testing van pakketsoftware

Post on 19-Jan-2016

33 views 0 download

description

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. - PowerPoint PPT Presentation

Transcript of Risk Based Testing van pakketsoftware

1

Risk Based Testing van pakketsoftware

Dennis Janssen

Test Research Centre LogicaCMG

dennis.janssen@logicacmg.com

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