Idhasoft - Vision Packaged. Delivered

The challenges of manual testing

For many companies, manual testing is increasingly unable to handle the lengthy and time-consuming job of comprehensive E-Business Suite testing. Since manual testing is linear, meaning that twice as many test cases requires twice as much testing effort, increased application complexity has increased the demand for testing resources and personnel. This, however, is often a non-starter for organizations. All too frequently, the budget is simply not available to significantly increase the testing staff. And even if it is, acquiring the experienced E-Business Suite resources with the necessary company-specific knowledge needed to do the testing can be difficult, if not impossible.

If the resourcing problem can be worked around, another roadblock appears: time. Since most companies are not able to double their testing personnel whenever their testing needs or sets of test data double, they have to simply extend the amount of time for testing. This can easily push project implementation dates and milestones past their due dates. This impacts productivity and the ability of the company to put its large software investment into the hands of the people who can use it to improve the bottom line.

Testing repeatability

On top of the resource and time issues, there is also the problem of testing repeatability. In other words, how can you be sure that you are executing the tests the same way and checking thoroughly for all of the expected results each time? With manual testing, this is a very real problem. Often, test cases are poorly documented, if they are documented at all. This leaves much of the decision on what to test and how to test it up to the individual tester.

No way to test for data operability

Another problem faced when performing E-Business Suite testing is data variability. This is the need to use different sets of testing data, also called scenarios, to test business process variations in the E-Business Suite.

Having just three data scenarios triples testing work versus a single scenario when manual testing is being employed. Your company may have far more scenarios than this for your core modules, such as Financials, Order Management or Inventory.

Why prior generations of test automations have struggled to meet the need

Test automation has held the promise of resolving all of the current problems of manual testing while meeting the quality needs of the future. Test automation tools have been around for over a decade; however, as most E-Business Suite testers and users know, the use of test automation is far from universal. To understand the reasons why, we need to take a look at how test automation tools have worked, and how they have been used.

In the past, test automation tools have used what is called "record-and-replay" technology to create and execute automated tests against software systems such as Oracle's E-Business Suite. In theory, the recorders, that are a part of these tools, watch a person perform a manual test and then generate a script in a specific programming language. This script can then be re-executed against the application when re-testing is needed. Unfortunately, the reality on the ground is that these recorders can only capture about one-half to two-thirds of the script, and the remaining part of the script must be programmed manually.

Programming is needed to add items, such as:

• Validations - The recorder cannot tell what the tester's eyes are looking at or what they are looking for
• Adding looping to input or check multiple lines or rows of data - If the recorder watches five rows of data being input, it does not automatically know how to modify this to input only one row, or 20 rows
• Error handling for unexpected situations - Unless the recorder sees the error and how it was handled, it will not know how to deal with it, and also will not know when the error will and will not occurM

Since it is not possible to create a functioning script without this programming step, the person creating a script - or maintaining it later when changes occur to the E-Business Suite environment - must not only be functional in Oracle Applications, but must also have technical programming skills. This significantly limits the number of people able to do this type of work, as the work itself is very technical. Staffing shortages, in turn, can lengthen the amount of time needed to create or maintain scripts, putting project completion dates at risk.

The difficulty of securing properly skilled resources in the past often led to the assignment of functional people without the needed technical skills, or the assignment of technical people without functional E-Business Suite knowledge. Frequently, this meant the creation of scripts that were very difficult to maintain, or a lack of the skill sets needed to maintain scripts once they were created. This ended up creating a phenomenon called "shelfware," in which the use of the tools and test automation itself was suspended due to lack of success and poor Return on investment (ROI).

Summary of what is needed

To meet your E-Business Suite testing challenges, your organization needs:

• A functional testing approach that does not require a linear increase in personnel for a corresponding increase in application functionality
• A method that can shorten the length of time needed to complete testing
• A process that enables testing to be performed thoroughly and repeatedly each time, and with full traceability
• A procedure that can reduce the cost of testing and the impact on resources and personnel