Preparing your test plan and scripts
In the previous article, we explained how the overall testing should be managed and the different steps involved. You now appreciate how critical it is to prepare it thoroughly and how challenging it can be. This article will assist you with the creation of your test scripts and give you some direction to put together the test plan which will guide key users through this phase.
Understanding your process streams
Before the business starts writing test scripts, it is important to identify the high level process streams and discuss the sequence in which the testing should be performed. Process streams can be usually identified as followed:
a) Quote-to-cash (QtC)
QtC includes activities around customer relationship management, quoting, lead management and sales ordering. Some SBO Partners also cover debtor management in this part but we recommend that anything to do with finance should be tested in a separate process stream as it involves different people.
b) Procure-to-Pay (PtP)
PtP represents the interpretation of a customer need in terms of supply. It includes transactions such as purchase requisitions and purchase orders. As in the QtC, we recommend to cover PtP financial transactions in a separate process stream.
c) Demand-to-Supply (DtS)
DtS is the central nerve of your business. It covers a wide range of functions from sourcing to supplying (if we have orders, how can the business fulfill the demand?). Some typical examples of modules included in this stream would be MRP, Production, Inventory Management, etc.
In this stream, you would include all processes managed by the finance team: general ledger management, debtors and creditors, banking, fixed asset management, etc.
Depending on your implementation of SAP Business One, you will need to classify your test scripts in other streams such as service management (repair and maintenance), project management (task, budget, resource management) and even possibly a more generic category in which you will test the performance of the system, validate user authorisations and the administration module, etc.
Preparing test scripts
Now that the project manager has identified your process streams and potentially other categories, the project manager and the team should concentrate on the functions of each stream and the content of the test scripts.Test scripts should be written at the time when the business is the least busy with the implementation. It will probably be half way through the building phase. Before the project manager starts the exercise, he/she should consider dividing the scripts into two types: business process scripts (which should be written by the business) and functional test scripts, which should be written by the SAP Partner (however, the ownership of the tests should remain with the business).
Business Process test scripts
Written by the business, the scripts must cover high level processes and should not go down to the technical functions implemented in the ERP. The difficulty will be to cover all processes of the business.
A new walk-in customer wants to get a quote and understand if or when the products will be available. The customer comes back a few days later and decides to order the goods but would like to negotiate the price (discount of 10%). The products must be delivered to his place on a specific day. As he is a new customer, a deposit of 25% is required.
Functional test scripts
During the design phase of the implementation, the project team has identified some gaps to ensure that the ERP can work perfectly for the business. Some gaps might not have been approved and others had to be developed during the building phase. Each gap must be thoroughly tested to ensure they have been developed as per the specification documents. Ideally, each function of the ERP should have a separate test script. Although it is ideal when the process owners write the scripts, it is often not very realistic because of a lack of technical knowledge and sometimes a lack of understanding of the ERP. In this case, the SBO Partner should write the test scripts and have them reviewed and approved by the business.
Very often test scripts are poorly written because they do not try to ‘break’ the system or processes. A typical example would be to test that an approval procedure in SAP Business One is working but not to try to work around it. It is common to see SBO consultants testing an approval procedure when a purchase order is over a certain limit, but nothing prevented a user from creating a purchase order for one dollar, then to increase the price later to $1,000,000 without the approval process being triggered.
Do not forget:
- To cover authorisations, layouts and reports in the testing.
- To measure performance. At least once during the testing, all users should try to connect simultaneously.
- To test the infrastructure (sending emails, faxes and printing are typical things that project teams forget to test).
Reviewing test scripts
In a typical SAP Business One implementation (20 users), you will probably have a set of 30 business process test scripts and close to 50 functions to test. The difficulty is to ensure that every aspect of the business is covered and that all gaps have an attached test script. Test scripts must be distributed to key users (each of them having the ownership of a full or part of a process stream). The project manager will ideally give them up to three weeks to review all scenarios. Once test scripts have been reviewed, they must be signed off by the business project manager.
Preparing your test plan
You have to prepare the test plan which will record critical information about how the testing will be performed and by whom. A typical test plan will list all test scripts grouped by process stream. For each test script, the following information should be recorded:
- the owner,
- the person who will run the test,
- whether the test has been successful or not,
- the run number
- and finally, dependencies.
In order to keep track of the progress of the testing, the project manager will record the status of each script (pass/fail, run number, issues logged, etc.).
Ideally, testing should start with the quote-to-cash process. A customer expressing a demand is usually the trigger to all other processes. Procurement should be treated next, followed by Demand to Supply. Testing will finish with finance and performance testing. It is difficult to estimate how long testing will take. It heavily depends on how many test scripts you have and how complex they are. As an example, run one of testing for am 80 users implementation took one full week and run two took the same amount of time. In calendar days, the phase took 4 weeks (including fixing) for this implementation.
Each implementation is different and there is not only one way to prepare User Acceptance Testing. However, it is critical for the business to understand how important this phase is to ensure that they allocate the right people and the appropriate amount of time (and therefore budget). If this phase is not conducted well, it will definitely impact training and later on go live.