You are on page 1of 13

ERP Test Plan

ERP test plan should consist of the following information for an effective and successful implementation.

The test plan has the objectives, quality metrics, features to be tested manually, features to be tested through automation tools, project environment,
team infrastructure, resource requirements, testing schedule, testing deliverables, test execution infrastructure, testing framework, assumptions,
dependencies, constraints, bug tracking mechanism, bug reporting tools and acceptance criteria etc.,

Below is the sample test plan for our ERP implementation project for XYZ Petrochemical LLC.

See also – if you need more information on how to write test plan please check these tutorials:
 Write test plan document from scratch
 Test plan sample and one more here.

Project Description
ABC Manufacturing ERP is an integrated ERP solution for the manufacturing industry. The product consists of the core modules like Accounting, Finance,
Budget, Inventory, Fixed Asset, Customers, Vendors, CRM, Sales, Purchase, Payments, Contracts, Human Capital, Payroll, Production Planning, Project
Management, Inventory, Material Management, Work Orders and Business Intelligence.

The customer’s vertical is into manufacturing and their business is manufacturing petrochemical bi-products and selling them to the domestic and
international clients. The raw materials are purchased from domestic and international markets. The company operates from New York, the USA with
branches in various parts of the Country.
The company also have warehouses at remote locations. The ERP system will be implemented in a centralized location at the corporate premises and
connect the other branches, warehouses, production plants, marketing offices from various parts of the Country through Internet, WAN, Wi-Fi, Cloud
Infrastructure. The proposed solution supports multiple languages like English (for International customers, Hindi (for IN users), Arabic (for Middle East
vendors) and supports multiple currency transactions.
The system also has an E-Commerce customer portal for online sales orders with credit card payment gateway and a Vendor portal for purchase
quotations. There are more than 300 system users going to use the system from various parts of the globe with at least more than 10,000 transactions
per day.

Objective
 Identify the modules to be tested manually.
 Identify the modules to be tested through automation tools.
 Define the testing strategy, testing scope and testing activities.
 Define testing criteria, assumptions, dependencies and constraints.
 Identify the testing team, their allocation, and their testing schedule.
 Setup the manual and automation testing framework.
 Setup the testing infrastructure with the software and hardware configuration.
 Define the stakeholders of the project for ERP implementation.
 Define the communication and escalation mechanism.
 Define the work environment, task details, and the responsibilities.
 Risk management with risk mitigation plans.
 Define the test deliverables and the reporting tools.

Module wise Features for Manual Testing


 Payments Module (Payment Creation, Approve Payments, Issue Cheques)
 Funding Module (Joint Payments, Approve Joint Payments, Issue Cheques)
 Payroll Module (Payroll Cheques, Issue Cheques)
 Fixed Assets Module (Asset Depreciation, Asset Disposal)
 …

Module wise Features for Automation Testing


 Sales Module (Sales Order, Shipping Sales Order, Backorders, Sales Invoicing)
 Purchase Module (Purchase Contract, Purchase Orders, Purchase Amendments)
 Customer Module (Customer Management, Customer Financials)
 Human Capital Module (Employee Management, Attendance, Loans, Leaves)
 …

Features to be Tested Off Premises


 Functionality Testing: All the functional test cases of all modules, which are reviewed and approved.
 Regression Testing: All the functional test cases for the customized modules, which are reviewed and approved.
 Smoke Testing: All the functional test cases marked for Sanity, which is reviewed, executed and approved.
 …

Features to be Tested On Premises


 System Testing: All the system test cases of all modules, which are reviewed and approved.
 Integration Testing: All the system test cases of all modules, which are reviewed and approved.
 Performance Testing: All the performance test cases, which are reviewed and approved.
 Load Testing: All the load test cases, which are reviewed and approved.
 User Acceptance Testing: All the user acceptance testing, which are reviewed and approved.
 …

Features to be Tested on Mobile, Wi-Fi & Cloud


Functionality Testing: All the system test cases of the CRM module, which are reviewed and approved.

Resource Requirements
Testing Schedule
Sl.No. Task Details Start Date End Date Tester

1 Preparing Test Plan 04/05/2015 06/05/2015 Tester A

2 Review and Update Test Plan 07/05/2015 07/05/2015 Test Lead B

3 Preparing Test Suite & Test Cases

Module 1: Sales & Distribution 16/05/2015 04/06/2015

4 Sales Order Process 16/05/2015 20/05/2015 Tester B

5 Sales Contract Process 21/05/2015 26/05/2015 Tester B

6 Return Merchandise Authorization 27/05/2015 01/06/2015 Tester B

7 Payment Receipts Process 02/06/2015 04/06/2015 Tester B

Module 2: Purchase & Payments

8 Purchase Indent Process 16/05/2015 19/05/2015 Tester C

9 Purchase Quotation Process 20/05/2015 23/05/2015 Tester C

10 Purchase Order Process 24/05/2015 28/05/2015 Tester C

11 Payment Approval Process 29/05/2015 31/05/2015 Tester C

Test Execution

12 Module 1: Iteration 1 01/06/2015 05/06/2015 Tester B

13 Module 2: Iteration 1 01/06/2015 04/06/2015 Tester C

14 Regression Testing: Module 1

15 Regression Testing: Module 2

16 Test Reports & QA Plan Updates

Test Case Execution

Test Coverage
A: Functional Testing, B: System Testing, C: Integrity Testing, D: Security Testing, E: Usability Testing, F: Performance Testing, G: Interface Testing, H:
Installation Testing

Deliverables

Risk Management

Issue Tracker
Confluence and JIRA tools are used for issue tracking in the project. Also, JIRA is customized and configured for all the testing team members to escalate
issue and report bugs and assigned to the concern development team with the responsibility and target dates.

Quality Metrics

ERP Test Suite


Like the normal testing process, ERP Test Suite is normally prepared as an Excel document. This document controls the complete revision history of the
various test suites of all the modules in ERP application. The test cases of each module, test execution history, list of bugs and the test report history are
maintained in an ERP test suite.
For automation testing, the “test scripts” are maintained in the test suite and the related iteration of test execution history is maintained. Depends on
the type of testing and the complexity of the test cases, automation test scripts are maintained in the suite which should be designed in such a way for
re-usability.
Find below the snapshot of an ERP test suite in excel document.

Sample Test Suite Template Download:


Below is sample test suite template for download. It contains templates for revision history, test report, bug report, smoke test cases, regression test
cases

=> Click here to Download ERP test suite template.

ERP Test Cases


Apart from the functional test cases, regression test cases, sanity/smoke test cases, ERP Testing requires other type of test cases for installation testing,
configuration testing, implementation testing, adaptability testing, network testing, server testing, offline testing, remote testing, multi-currency testing,
multi-language testing, device testing, intranet testing, real-time testing etc.,

Most important, ERP being a centralized automated solution, being accessed by multiple users concurrently online in real time, which involves a financial
transaction, each and every test cases should be written with a lot of dedicated effort and real-time data.

Also, the test execution status should be updated as “Pass” after verifying the output data with the predefined real-time data. So, the test cases should
always have a column for “test data” and “output data”.
Sample Test Scenario:
Find below a sample test case for our ERP demonstration This test cases may consist of a lot of small test cases which can segregate and maintained, but
for demo purpose, it’s combined with a single test case.

Test Case
ABC_ERP_SD_X0121
ID

Module Sales & Distribution

Feature Sales Order Process

Objective To check the sales order is booked and invoiced with proper data entered for sales
header and sales details.

Steps to 1. Sales & Distribution -> Order Management -> Sales Order List -> New Sales
Reproduce Order.
2. Select Order Date, Select Order Type, Select the Expiry Date, Select Customer
ID, Select Shipping ID, Select Warehouse ID, Select Shipping Date, Select Payment
Due Date, Select Sales Tax ID, Select Salesman ID.
3. Select New Sales Items and Select Item ID, Select Item UOM, Enter Item Qty,
Enter Item Price, Select Ledger Account, Select Project ID and Click OK.
4. Click Book Order button in the main screen.

Input Data Order Date (01/01/2015), Order Type (Sales Order), Expiry Date (31/09/2015),
(Positive) Customer ID (SABIC), Shipping ID (FedEx), Warehouse ID (NaviMumbaiWH),
Shipping Date (03/02/2015), Select Payment Due Date (28/02/2015), Sales Tax
ID (ST929), Salesman ID (Anand), Item ID (PolyPropylene), Item UOM
(Kilograms), Item Qty (1000), Ledger Account (23499949), Project ID
(DueTarget2015)

Input Data Order Date (01/01/2016), Order Type (Purchase Order), Expiry Date
(Negative) (31/09/2012), Customer ID (DEFAULT), Shipping ID (Blank), Warehouse ID
(Blank), Shipping Date (03/02/2013), Select Payment Due Date (28/02/2012),
Sales Tax ID (Blank), Salesman ID (DEFAULT), Item ID (DEFAULT), Item UOM
(Blank), Item Qty (0), Ledger Account (DEFAULT), Project ID (DEFAULT)

Expected 1. Order should be booked and invoiced.


Results 2. Picking Packing slip should be generated.
(Positive) 3. Shipping Order should be generated.
4. General Ledger transactions should be posted.
5. Inventory Ledger should be updated.
6. Debit Memo should be generated.
7. Email should be sent to the Customer and Stores.

Expected • Alert box should be coming for each negative data input as per the alert process
Results and the defined text.
(Negative) • Sales order should be backordered, if the items are out of stock.
• Sales order should be on hold, if the customer credit limit is low.

Actual
Result

Expected Sales Order, Sales Invoice, Packing List, Shipping List should be generated in the
Output predefined report format.

Actual
Output

Conclusion
ERP Testing is having a lot of risks and complexities compared to any software/product testing. Also, managing the quality metrics in ERP implementation
projects requires a lot of attention and dedicated efforts as a “team” from the multiple stakeholders.
Testing professionals need to understand the difference between the quality of the product and the quality of implementation. ERP testing requires
trusted sponsorship on time and budget from the management and the customers. Testing should be done by the ERP expert team and should not be
allocated to an inexperienced team for any reason.

It is very important to use the universally proven right process, methodologies, approaches, and automated tools. We should not assume that
“automation” completely replaces the “manual” testing, but should not compromise on using the required testing infrastructure and framework. Don’t
underestimate the time required for collecting live real data from the customers.

ERP Product Testing:

 Identify the components that comprise an Oracle Application system


 Navigation to Oracle Applications
 Explain basic application integration
 Identify Entities that are shared between multiple applications
 Explain different application versions & database versions
 Multi Org structure and explanation of Sample Org
 ccounting Basics

Oracle General Ledger

 The Heart of Accounting System & Overview of GL Concepts


 Overview of General Ledger and project requirements
 Configuring GL Module from scratch
 Defining Accounting Flexi field- Set Of Books
 Defining various types of Journals & Security Rules
 Interfaces in General Ledger Module
 Relationship with Other Financials Modules
 Standard GL reports
 Running Business Test Scripts for GL

Account Payables

 Overview of Payables Concepts


 Overview of payables project requirements
 Configuring AP Module from scratch
 Creating Various types of Invoices
 Approving an Invoice
 Payables Data model
 Relationship with Other Financials Modules
 Standard AP reports
 Running Business Test Scripts for AP

Account Receivables

 Overview of Receivables Concepts


 Overview of Receivables project requirements
 Configuring AR Module from scratch
 Customer setup
 Transactions setup
 Defining various types of Transactions
 Interfaces in Receivables
 Print setup & Document
 Relationship with Other Financials Modules
 Standard AR reports
 Running Business Test Scripts for AR

Fixed Assets
 Overview of Fixed Assets Concepts
 Overview of Fixed Assets Concepts
 Overview of Fixed Assets project requirements
 Configuring FA Module from scratch
 Key and Descriptive flex fields in Oracle Assets
 Assets Categories & additions
 Interfaces in Assets
 Configuring FA Module
 Standard reports in FA
 Running Business Test Scripts for FA

Cash Management
 Overview of Cash Management Concepts
 Overview of Cash Management project requirements
 Configuring CM Module from scratch
 Loading bank statements
 Reconciling Bank Statements
 Loading Bank Statements
 Relationship with other Modules
 Standard CM reports
 Running Business Test Scripts for CM

System Administration and Application Object Library


 Define Users , Monitor Concurrent programs
 Define Responsibility, Request group
 Define concurrent Program, executables
 Define Menu, Sub-menu, function and attach to responsibility
 Setup Functional profile options & Understand hierarchy
 Understand Key & Descriptive flex fields
 Define Document sequence
 Understand System & personal profiles

Miscellaneous
 Data Loader usage for financial modules
 Project documentation
 Sample Resume preparation
 Interview question and answers
 ADI awareness and testing screens documentation

Intercompany Setups
Intercompany Transactions are the transactions between two legal entities related to same Organization. Following are the setups need to be defined for Intercompany Transactions.

Selling Operating Unit: Vision Japan


Shipping Operating Unit: Vision Operations
Step1: Define Transaction Type
Responsibility: Receivables Manager, Vision Operations
Navigation: Setup → Transactions → Transaction Type
Define new transaction type as shown below.

Step2: Assign Document Sequence to new Transaction Type (Defined in Step1)


Responsibility: General Ledger Manager, Vision Operations
Navigation: Setup: Financials → Sequences → Document → Assign
Assign a document sequence to the transaction type 'Intercompany' as shown below.
Step3: Define Intercompany Transaction Flow and Intercompany Relations
Responsibility: Inventory Manager, Vision operations
Navigation: Setup → Organizations → Intercompany Transaction Flows
Define Intercompany Transaction flow and Intercompany Relations as shown below.

Mandatory Setups to Check:


1. Make Sure there are no security rules defined when shipping the item from other Operating unit and Auto Accounting rules are defined(for Selling OU) to default the balancing segment
values with Table Name as Standard Lines(Which will get the values from Standard line item or Inventory Item used)

Path for Security Rules:


Responsibility: General Ledger Responsibility
Navigation: Setup → Financials → Flexfields → Validation → Security → Define
Path for Auto Accounting:
Responsibility: Receivables Responsibility
Navigation: Setup → Transactions → Auto Accounting
2. Make Sure Shipping parameters are defined for both Shipping and Selling operating units.

Responsibility: Order Management Responsibility


Navigation: Shipping → Setup → Shipping Parameters

3. Make Sure that the COGS account is assigned to the Transaction Type used for SO in Selling Organization.

Responsibility: Order Management Responsibility


Navigation: Setup-> Transaction Type

4. Make sure that a value is assigned for System parameter 'Inventory Item For Freight'

Responsibility: Order Management Responsibility


Navigation: Setup → System Parameters → Values
Intercompany Transaction Process:
1. Create and Book Sales Order:
Responsibility: Vision Japan Order Management Responsibility
Navigation: Orders, Returns → Sales Orders

Create a Sales Order with Vision Operations Shipping Warehouse and book the order as shown below.
2. Release the Order and Ship the Item

Responsibility: Vision Operations Order Management Responsibility


Navigation: Shipping → Release Sales Orders → Release Sales Orders

Release and ship the order. Then notice the transaction status as 'Shipped' or 'Interfaced' on Shipping Transactions form as shown below.

Navigation: Shipping → Transactions

3. Run Workflow Background process

Responsibility: Vision Japan Inventory Responsibility


Navigation: Workflow Background Engine

Run Workflow Background Process.

4. Run Auto Invoice Master Program to create Customer Invoice

Responsibility: Vision Japan Receivables Responsibility


Navigation: View → Requests → Auto Invoice Master Program

The invoice created is shown below.

Navigation: Transactions → Transactions


5. Create Intercompany AR Invoice
Responsibility: Vision Operations Inventory Responsibility
Navigation: Reports → Intercompany Invoicing

Run the Program 'Create Intercompany AR Invoices' to create Intercompany AR invoice.

6. Import Intercompany AR invoice

Responsibility: Vision Operations Receivables Responsibility

Run Auto Invoice Master Program with parameter Source as 'Intercompany'. The Intercompany invoice created is shown below.

Navigation: Transactions → Transactions


7. Create Intercompany AP Invoice

Responsibility: Vision Japan Inventory Responsibility


Navigation: Reports → Intercompany Invoicing

Run the Program 'Create Intercompany AP Invoices' to create Intercompany AP invoice.

8. Import Intercompany AP invoice

Responsibility: Vision Japan Payables Responsibility

Run Payables Open Interface Program with parameter Source as 'Intercompany'. The Intercompany AP invoice created is shown below.
Navigation: Invoices → Inquiry → Invoices

Possible Errors while making Intercompany Transactions:


1. Please correct the revenue account assignment
2. INCIAP - Create Intercompany AP Invoices Terminated By Signal 11 Error
3. Can not retrieve payment term from bill-to site information
4. Returned warning from extra function

Solution: Check Mandatory Setups Section.

You might also like