Introduction

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.
d) Finance
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.
Example:
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.
Conclusion
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.
- See more at: http://www.sap-b1.com/project-management/testing-and-user-acceptance-testing/preparing-your-test-
plan-and-scripts/#sthash.Sh6PjsAA.dpuf