1 / 12

Integration Test Scope Review – Kickoff Meeting

Integration Test Scope Review – Kickoff Meeting. 18 TH June 2007. Agenda. What is the High-Level Testing Process on the DART-GSS Program? What is Integration Testing on the DART-GSS Program? How is Integration Test Scope reviewed and approved? Why is your involvement important?

yair
Download Presentation

Integration Test Scope Review – Kickoff Meeting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Integration Test Scope Review – Kickoff Meeting 18TH June 2007

  2. Agenda • What is the High-Level Testing Process on the DART-GSS Program? • What is Integration Testing on the DART-GSS Program? • How is Integration Test Scope reviewed and approved? • Why is your involvement important? • What do Integration Test Conditions look like? • Specific Examples • How will the sessions be run? • What is the schedule for these reviews? • Next Steps • Questions

  3. High-Level Testing Process on DART-GSS Program • Unit Testing • As individual code modules are built, in each system • Test conditions created by development team • No business user involvement • Product Testing • Treats groups of systems as ‘sub-assemblies’ • Ensures internal consistency within an application group • Test conditions created by test prep teams based on functional designs • No business user involvement • There are 3 separate product tests being conducted: • Dart Product Test (under way) • SAP / Informatica / POSDM / BW • Local Product Test • S2K / Quickbooks / EFT / other • GSS Product Test • Integrated test of site components

  4. R4 Product Test Methodology

  5. High-Level Testing Process on DART-GSS Program • Technical Testing • DART Volume and Performance Testing • To validate performance of system meets non-functional requirements e.g. batch windows • Business input into defining Business Volume Indicators • GSS Technical Testing • Volume and Performance Testing of site systems based on Business Volume Indicators • Disaster Recovery / Operations Testing etc.

  6. What is Integration Testing on DART-GSS Program? • Integration Testing is the bringing together of the 3 ‘sub-assemblies’ from Product Test • It is the first time that end to end business processes can be tested • Parallel activities taking place in integration testing • US Integration Testing • Ensuring DART R4 works with GSS R4.1(US) • AU / UK regressive Integration Testing • Ensuring DART R4 works with existing AU / UK site landscape (GSS R3.2 / R3.1) • NZ Integration Testing • Ensuring DART R4 works with GSS R4.2 (NZ) • AU Integration Testing • Ensuring DART R4 works with GSS R4.2 (AU)

  7. How is Integration Test Scope Reviewed and Approved? • Integration Testing is the bringing together of the 3 ‘sub-assemblies’ from Product Test • It is the first time that end to end business processes can be tested • Parallel activities taking place in integration testing • US Integration Testing • Ensuring DART R4 works with GSS R4.1(US) • AU / UK regressive Integration Testing • Ensuring DART R4 works with existing AU / UK site landscape (GSS R3.2 / R3.1) • NZ Integration Testing • Ensuring DART R4 works with GSS R4.2 (NZ) • AU Integration Testing • Ensuring DART R4 works with GSS R4.2 (AU)

  8. INTEGRATION TEST MODEL • Business Process ( note Tim there was no standardization on this but there is in the process chains.)> Requirements > Scenarios > Condition • Show slide of process chains • Each business process links to a PPD (this needs to spelled out) and can have many requirements • Each requirement links to a number of scenarios which should provide a description of the steps involved from end to end in order to clarify the flows involved Some maybe set up this way but others it doesn’t work this way. It really varies. Maybe this point really doesn’t make a difference and do they need to know this. • Integration Test Conditions should provide enough information to • Identifies what scripts that have to be written and run for a scenario • Enable the business to understand the scope of testing.

  9. EXAMPLE • Within the FoodService Blue Print area: • Business Process: Set Up Recipe • Business Requirement: Ability to create a BOM (bill of materials) to capture ingredients, costs and inventory levels • Scenario: R3_INT_05 New Recipe Created - Recipe: create in SAP/ download to Retalix; ensure that recipe data applies correctly at site; view recipe within BOS ensuring all required details are correctly displayed • Condition: Recipe: Create with INGR (ingredient) items. The recipes are available on the BOS, cannot be edited but can be used for production plans

  10. NEXT STEPS • Release 3 Scenario and Conditions have been completed for all areas except Invoice and Pay • Sign Off Process • Written confirmation that scenarios and conditions satisfy the global process requirements for each area • Suggestion of any additional areas • Comments or feedback

  11. TEMPLATE

  12. AGENDA • Explain how will the process will be done. • Give them the conditions first to have them review them. At the initial meeting tell them the overall scope for the subject • Get back together and walk thru every scenario with the business owner if no question it’s an approval or you go back and add the information.

More Related