1 / 7

GFI ART Approach

GFI ART Approach. May 17, 2007. ART Team Services. Assembled in 2004 to build and execute automated regression test scripts for Program One rollout of SAP to US West Coast Services Test scenario automation and execution Interface automation, execution, and validation Error correction

trixie
Download Presentation

GFI ART Approach

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. GFI ART Approach May 17, 2007

  2. ART Team Services • Assembled in 2004 to build and execute automated regression test scripts for Program One rollout of SAP to US West Coast • Services • Test scenario automation and execution • Interface automation, execution, and validation • Error correction • Master data loading and conversions • Performance Testing • Security Profile Testing • Table updates • Tools site administration

  3. BP Automated Regression Test (ART) Team • Automation is cost effective when the same test is to be run multiple times (usually 3 or more times), e.g. for programs that deliver in phases (Cassis), for monthly packages (Production Support) or for short duration test cycles • For various projects/environments, the ART team now has automated SAP transactions and test scenarios for: • In the US, we have also provided automation services to : • IST Phoenix • SAP Real Estate • Fuels Capabilities • DJP Performance Testing • NGL Performance Testing

  4. Mercury Toolset Used by ART • QuickTest Pro 9.0 or Winrunner • Allows the recording of individual transactions • QualityCenter 9.0 • Originally called TestDirector • Main Mercury tool to • Create test scenarios by dragging and dropping components • Schedule tests to be executed • Store tests and results • Compare actual results to those expected to grade Pass/Fail • Can also be used to schedule and store manual test results • Can call both QTP and Winrunner test scripts • Business Process Test 9.0 • Additional component of QualityCenter • Allows single recording of individual transaction code to be used in multiple test scenarios • Change transaction code once, all scenarios using that code are updated • Can be used with Winrunner 8.2 and with QTP • Performance Center 8.2 • Originally called Load Runner • Main Mercury tool for Performance Testing and Monitoring

  5. QualityCenter 9.0 with add-ins (TestDirector) Business Process Test GFI QA Testing Team Tools (ART) Business Objects XI For Reporting Create test scenarios Create test schedule Input env. parameters Execute test cases Record test results Compare to expected Indicate Pass/Fail QuickTest Pro 9.0/ WinRunner Tcode 1 Tcode 2 Tcode 3 Outputs Case 1 Outputs Case 2 Outputs Case 3 Inputs Case 1 Inputs Case 2 Inputs Case 3

  6. GFI’s Basic Automation Approach • Identify individual transaction codes used in a business process, represented in the test scenario • Order to cash could comprise create order, then goods delivery, then invoice, then collect cash, then apply cash to open receivable • Record each transaction code using Quick Test Pro individually and store the result in Quality Center Business Process Test Module • Link the 5 transactions codes into a scenario and store in Quality Center Test Plan Module • Add different input data and expected results to represent different test cases for the scenario • Utilize Quality Center to schedule scenarios to be run and store the actual execution results • Utilize Business Objects to report on the results to highlight test failures

  7. GFI’s Basic Automation Approach, cont. • By recording individual transaction codes and then using them in scenarios, we are set up to maintain only one recording if a transaction code adds a new mandatory field instead of every test case that uses that transaction code • These individual components and scenarios can also be leveraged across similar environments, as we did between PRE and PRV • Typically, if you execute a test scenario 3 or more times, it is cost effective to automate it • Additionally, automated scripts run faster and are more accurate • While a project typically funds creating new and changed test scenarios/test cases, production support or subsequent projects gain the benefits

More Related