You are here: Home Software Testing Techniques Testing ERP Packages

SoftwareQAtestings.com

...Your Hub for Software Testing and Quality Assurance

~ Contact Us ~ Privacy Policy ~ Register ~

Testing ERP Packages

Companies are investing heavily in ERP solutions, such as SAP and PeopleSoft, to support their business critical processes. Often, a lot of money is spent on customizing and integrating the ERP package. However, because the importance of structured testing is often underestimated or forgotten, a lot of ERP implementations do not deliver to the promise.

The idea that "out-of-the-box" solutions do not need to be tested is widely accepted. Reality however is that ERP systems are always customized, are linked to other legacy systems and other software packages and require different local implementations. Furthermore, after deployment, regular upgrades and hot fixes will have to be planned.

This makes testing even more complex than for traditio nal software. As a result, the testing discipline needs to be carefully managed. We need to know some basics about ERP (Enterprise Resource Planning) first to get our feet wet.

Enterprise Resource Planning

Enterprise resource planning (ERP) systems attempt to integrate several data sources and processes of an organization into a unified system. A typical ERP system will use multiple components of computer software and hardware to achieve the integration. A key ingredient of most ERP systems is the use of a unified database to store data for the various system modules.

The two key components of an ERP system are a common database and a modular software design. A common database is the system that allows every department of a company to store and retrieve information in real-time. Using a common database allows information to be more reliable, accessible, and easily shared. Furthermore, a modular software design is a variety of programs that can be added on an individual basis to improve the efficiency of the business. This improves the business by adding functionality, mixing and matching programs from different vendors, and allowing the company to choose which modules to implement. These modular software designs link into the common database, so that all of the information between the departments is accessible in real time.

Overview

Some organizations — typically those with sufficient in-house IT skills to integrate multiple software products — choose to implement only portions of an ERP system and develop an external interface to other ERP or stand-alone systems for their other application needs. For example, one may choose to use human resource management system from one vendor, and the financial systems from another, and perform the integration between the systems themselves.

This is very common in the retail sector[citation needed], where even a mid-sized retailer will have a discrete Point-of-Sale (POS) product and financials application, then a series of specialized applications to handle business requirements such as warehouse management, staff roistering, merchandising and logistics.

Ideally, ERP delivers a single database that contains all data for the software modules, which would include:

Manufacturing

Engineering, Bills of Material, Scheduling, Capacity, Workflow Management, Quality Control, Cost Management, Manufacturing Process, Manufacturing Projects, Manufacturing Flow

Supply Chain Management

Inventory, Order Entry, Purchasing, Product Configurator, Supply Chain Planning, Supplier Scheduling, Inspection of goods, Claim Processing, Commission Calculation

Financials

General Ledger, Cash Management, Accounts Payable, Accounts Receivable, Fixed Assets

Projects

Costing, Billing, Time and Expense, Activity Management

Human Resources

Human Resources, Payroll, Training, Time & Attendance, Rostering, Benefits

Customer Relationship Management

Sales and Marketing, Commissions, Service, Customer Contact and Call Center support

Data Warehouse

and various Self-Service interfaces for Customers, Suppliers, and Employees

Enterprise Resource Planning is a term originally derived from manufacturing resource planning (MRP II) that followed material requirements planning (MRP). MRP evolved into ERP when "routings" became a major part of the software architecture and a company's capacity planning activity also became a part of the standard software activity.[citation needed] ERP systems typically handle the manufacturing, logistics, distribution, inventory, shipping, invoicing, and accounting for a company. Enterprise Resource Planning or ERP software can aid in the control of many business activities, like sales, marketing, delivery, billing, production, inventory management, quality management, and human resource management.

ERP systems saw a large boost in sales in the 1990s as companies faced the Y2K problem in their legacy systems. Many companies took this opportunity to replace their legacy information systems with ERP systems. This rapid growth in sales was followed by a slump in 1999, at which time most companies had already implemented their Y2K solution.

ERPs are often incorrectly called back office systems indicating that customers and the general public are not directly involved. This is contrasted with front office systems like customer relationship management (CRM) systems that deal directly with the customers, or the eBusiness systems such as eCommerce, eGovernment, eTelecom, and eFinance, or supplier relationship management (SRM) systems.

ERPs are cross-functional and enterprise wide. All functional departments that are involved in operations or production are integrated in one system. In addition to manufacturing, warehousing, logistics, and information technology, this would include accounting, human resources, marketing, and strategic management.

ERP II means open ERP architecture of components. The older, monolithic ERP systems became component oriented.

EAS — Enterprise Application Suite is a new name for formerly developed ERP systems which include (almost) all segments of business, using ordinary Internet browsers as thin clients.

Now back to ERP testing discussion.


TestFrame for SAP: realise the benefits

Fitting, structuring and tooling are the key principles within TestFrame,for structured testing. Since implementing SAP differs from standard system development, the key principles of

TestFrame have been customized.

Fitting

Fitting means determining and defining the right test approach by looking at the organisation and the chosen development approach. Business Scenarios are developed

for the business processes that SAP supports.

 

Structuring

Within TestFrame Action Words help to determine the Business Scenarios. These Action Words describe the processes to cover in a structured way and at a high level. On a lower level, the transactions and the data required to carry out a business process are identified. This structured approach enables you to identify, after the execution of the tests, both parts that fail and pass the tests. Thus the quality of the SAP implementation can be comprehensively measured.

Tooling

The structured description of the business processes can be used for manual testing but,

with limited effort, can also be used as input for the automated testing of the SAP system, even in combination with other systems. In practice, executing a manual test three times or more will exceed the costs of automated testing. Tooling for SAP exists of the CATT module within SAP and a CAST-tool (Computer Aided Software Testing). This combination ensures the fast and effective processing within SAP and also enables you to execute automated tests on other integrated systems.

When you also consider the short lead time of executing the tests and the possibilities of repeated testing, TestFrame provides a unique and complete solution.

 

An Approach to testing ERP Packages

A specific approach to is required to deal with the ERP testing challenges. We will discuss such an approach.

The Developer's Tests (component testing) are technical tests of low-level components (e.g. a conversion module).

Transaction Testing is testing of a single transaction (e.g. Create Sales Order) to

confirm the operation of transactions and related configuration checks (e.g. default

values, mandatory fields, etc.)

In-Stream Testing covers chains of transactions that flow together and which reflect

important business process and scenarios (e.g . within the Sales process).

Cross-Stream Testing is end-to-end testing of integrated processes through execution

of predefined business flows (within the ERP system or collaboration with legacy

systems).

Acceptance Tests are in-stream or cross-stream tests by the user community with the

objective of formal acceptance.

This ERP Testing approach is an extension of the general Test Methodology .

Conclusion

We conclude our discussion by listing some of the benefits of ERP Testing:

Allow organizations to manage and implement ERP packages better for their requirements.

Increase the quality and ROI (Return on Investment) on ERP Solutions of organizations.

Increase end-user confidence.

Reduce cost and duration of implementation.

Result in reusable regression tests for future upgrades and maintenance.