Your Guide to Successfully Plan and Test your R12 Upgrade

Our webcast “How to Successfully Plan and Test your R12 Upgrade” was held yesterday and we had many questions on automation, testing time frames, test planning, and more. Our experts took the time to answer all the questions and today we bring you a transcript.

Would you tell us what are the automated tools for testing and if is necessary make a implementation process?

There are many automated tools available in the market today. Just like any other project efforts, you should create a list of requirements of what you think the tool needs to do. Then you will need to prioritize that list to help determine the “best fit” for your organization. When selecting tools one must take into account several factors:

  • Platform and apps to be tested: can the tool support them all?
  • What testing are you emulating? GUI, database backend, API services, reporting, mobile, security, performance.  All these factor into the tool you would select.
  • Does the automated tool integrate with the Test Management tool, requirements management tool, monitoring tools, etc.
  •  Licensing limitations? Does the tool only worked on your workstation and the immediate network? Does it need to work across branches of your company, different states and different countries?
  •  Do you need application specific add-in’s (I.E. Oracle add in for either the OATS or HP toolsets.
  • Common tools for Oracle testing are:
  • Oracle Application Testing suite-OATS & UPK tool including; FlowBuilder, OpenScript, OTM and Oracle Load Testing Tool
  • HP Suite; QTP, UFT and Quality Center/ALM
  • IBM suite; Functional Tester

What type of time frames are you seeing on projects to upgrade from 12.1.3 to 12.2.4?

A lot of factors come into play that determine the timeframe of your upgrade project, including:

  • How many Oracle modules are you implementing?
  • What customization is being done?
  • Does your company have ERP experience (specifically Oracle). Do you have dedicated resources to work on the project?
  • Will you need to do a data conversion prior to or as part of the upgrade?
  • Do you have a dedicated testing team?
  • Will you be using automated tools?

That said, these factors will help guide you to creating your length of schedule.  We have seen upgrades take as little as 6 months and as long as 18 months.  If you would like help in your upgrade journey, contact ITC and we can partner with you to successfully plan and execute your upgrade.

Can we test faster and with higher quality using automation? Can we suffix with manual testing?

Creating automation is a development effort that must be scoped, planned and scheduled. Many of these activities can happen in parallel as part of your upgrade project. Most importantly, great automation is a result of strong manual testing and good requirements.  Both contribute to building effective automation. You should plan to create the automation in the early cycles of your project to be used in repetitive fashion for the later cycles of the project.

Many companies focus on creating an automated regression test suite. These efforts can take several months but are very cost effective for testing the later cycles in your upgrade and can be re-used for future Patch testing cycles. It is during these testing cycles where you will experience faster execution of your testing.  It will also help you ensure more accurate test coverage that can be quantified for your company leadership via reporting, metrics and KPI’s.

If we automate, we can test faster and finish the project sooner, right? How do you determine what tests to automate?

Once automation is created, future test cycles can be executed faster than manual testing and be more effective by limiting human data entry errors. To determine what tests to automate – well, that’s a much longer conversation, but here are a few pointers to guide you:

  • How many manual test cases do you have?  What test coverage does that provide?
  •  Look at complex code modules that may require a variety of functional path and data combinations.
  • There are several types of automation; Data Driven, Event Driven, and Message Driven, to name a few
  • Look at if you are GUI testing, API or web services testing, SOA testing, Mobile testing, Security testing, Performance testing or any combination.
  •  Also consider: Functional or task specific test vs. Business flow/Integrated tests

Now take all your test cases, prioritize them and then map them to the factors noted above and you will have a good start to what tests should/CAN be automated.  Once you know this, then look at the schedule, available resources and start determining the effort to create, troubleshoot and execute your automation.

Every project cycle our schedule gets shorter but we still have to test everything… How do we accomplish this?  What options do we have?

You need to understand the total number of tests to be executed and the test cycles you need to execute.  This will help you estimate effort and schedule. If there is not enough time to execute all tests, you have a couple of options:

  • Add resources
  • Prioritize testing and focus of high priority tests first.  Make sure that project leadership understands and accepts that all testing may not be completed but it will be based on priority.
  • Finally, automation can be created to help shorten the time to execute testing.  Automated testing can then be reused for later test cycles which can also shorten your test prep time.  Make sure to allow time for performing maintenance on your automated test scripts for when application code changes or you receive app patches from Oracle. It should take less time to update your test scripts and execution will be considerably faster than manual testing.

We run out of time for comprehensive testing whenever the development phase is delayed. Can you suggest some strategies to overcome these challenges to ensure proper testing even under strict deadlines?

You have to know and understand what needs to be tested.  Where necessary, prioritize your test cases based on the criticality of the business functions to be tested.  Make sure to support this with timely, accurate metrics.  It is hard to argue how long it takes to execute 500-1000 test cases.  Be ready to test application functionality as it is delivered.  If you have good requirement traceability and test case mapping, you can quickly switch gears and continue testing functionality that is available with the code builds you are receiving.

Remember you can always view all of our Testing entries, or visit our website for more information. If you missed the webcast, you can also click here to download the recording.