Risk Based Testing Packaged Software The PRICES Model Dennis Janssen LogicaCMG 1
Risk Based Testing Packaged Software The Prices Model Dennis Janssen Test Research Centre LogicaCMG dennis.janssen@logicacmg.com 2
Agenda What is packaged software (buy over make) Risks of implementing packaged software Risk & Requirement Based Testing (RRBT) Test strategy for packaged software PRICES model Summary 3
What is packaged software? Functionality out of the box which fits on the organization Proven technology Maintenance and support performed by supplier Cheaper than tailor made solutions Fittable and expandable with new modules and enhachements In a perfect world, the organizition will benefit from all these aspects 4
So we don t have to test?? 5
Risks of implementing packaged software Doesn t quite fit on business processes Do we fit the process on the packaged software? More functionality than the orginization uses Additional enhanchements (exactly what we didn t want ) Doesn t quite fit in architecture Packaged solution can t work (well) with legacy systems Interfacing Different data formats Conversion and historcal data Quality of packaged solutions isn t as high as promised Not much influence on supplier of packaged soultion Supplier decides when a new version is available and distributed Supplier decides what a new version of the packaged software contains 6
So we have to test!!! 7
What kind of packaged software? Office software (Word, Excel, McAffee) ERP (SAP, Peoplesoft) CRM (Siebel, Scope) (Project) Administration (NIKU) Branche specific applications (OMR/ TA, Globus, Flexcube ) 8
Test strategy packaged software Trust Match packaged solution & business Influence Risicomix Risk Test strategy $ $ $ $ $ $ static testing indirect testing dynamic testing 9
Place within risk mix Trust Package 1 Package 3 Package 2 Package 5 Package 4 Influence 10
The place within the riskmix decides which mix of test activities is the optimal approach for testing the packaged solution/ software 11
Test strategy in depth Static testing Starts with selection of packaged software More important than in tailor made projects Review & audit (reactive) Use test scenario s to test requirement (proactive) Indirect testing What can you expect from a vendor? Vendor visit Ask for the test report Test together with the vendor Dynamic testing PRICES model 12
PRICES model Parameters Releases Integration Conversion Enhancements Security 13
PARAMETERS Don t test basic functionality ( plain vanilla ) Do test the organisation specific configurations Do test scripting within the packaged solution 14
RELEASES Lots of changes on packaged software (hot fix, release, full upgrade, etc) Often not a lot of influence on timing of changes You have to implement all changes ( must upgrade ) Regression testing is the name of the game (more important which each new release) Automated testing is a must because of short amount of time between changes 15
INTEGRATION Integrate packaged software within IT architecture and business processes Test interfaces both technical and function Data integrity Performance aspects End to end testing 16
CONVERSION Testing data conversion from legacy to packaged software Conversion rules (functionality of the conversion) Testing the stuff that doesn t convert Performance of conversion Trail conversion Regular small conversions when expanding the use of the packaged software 17
ENHANCHEMENTS No implementation of packaged software without enhanchements! No difference with normal testing How much we have to spent on this, depends on priority, complexity and amount of the enhachements 18
SECURITY Authorisations have to be set correctly Watch out for security patches (think Outlook) Be sure that functionality that ISN T used, CAN T be used 19
Summary More and more packaged software, but testing stays very important Risks as the start for testing Distribute testing between static, indirect and dynamic testing for maximal coverage with minimal budget Use PRICES model to fill in dynamic testing 20