Introduction Acceptance Testing is a critical phase during which the design of your system and the configuration performed

by the ERP team will be put to test. This is a unique opportunity for the business, the users and the implementation partner to ensure that training can be delivered with a working system and that go live is not compromised. Acceptance Testing is the last hurdle before training and go live. The phase, which can take up to a month and half for a 50 user site, should be carefully prepared and executed to get the maximum benefit out of it. The business should have full ownership of this phase and not fully rely on the implementation partner. There are three major components to the Acceptance Testing phase: unit testing,to ensure that each function is working as designed; user acceptance testing, during which users perform their daily tasks in the system and validate the overall business processes; and finally performance testing, to determine if system behave normally when all users are connected and performed high CPU requirement tasks. Identification of resources and prerequisites During the preparation of your implementation, key users were identified and involved in the design phase. At this stage of the project it helps to have a clear understanding of the philosophy of SAP Business One and an appreciation for new business processes. Your key users should have reached an appropriate level of knowledge with the system to ensure that the user acceptance testing is efficient and the time allocated to it is not spent on training. The project manager will involve all key users during this phase based on the functions and processes covered during a session. You can split your functional area (and therefore the testing) in four major categories: - Quote to Cash - Procure to Pay

- Demand to Supply - Finance In some companies, other process streams can be identified (e.g. construction, sales & operation planning which covers in reality all business streams etc.). For each major stream, you must have a key user who will have the overall understanding and owneship of the process inside and outside the system. Each key user will be responsible for the acceptance testing of his/her area. Training The final phase of acceptance testing (user acceptance testing) is difficult if key users have not been trained and upskilled. Ideally, the functional consultants would have spent a full day - for a 20+ user site - with each key user to explain the process stream in SAP Business One. Key users must also have received a full system overview or navigation training prior to the start of the phase. Test scripts - Keep an eye out for the next article to know how to write test scripts Test scripts must be written to cover the functional aspects of the system but also the overal business processes and the documents that are oustide the system which will also support processes. Test scripts must be carefully reviewed by key users and the project manager prior to the start of the phase. The project manager must ensure that scripts cover all aspects of the system. Publishing a test plan The project manager will need to publish a detailed test plan so users understand what they are trying to achieve. Usually, the project manager will plan for at least two runs of acceptance testing where the second run will include only the test scripts that failed the first time. Typically, in an SAP Business One implementation (but also depending how well the test scripts are written), 50% of test scripts will have to be retested. When all test scripts went through run one and two, a final end-to-end testing should be organised. End-to-end testing focuses more on processes and is executed based on the process streams detailed earlier. What should you consider in your test plan? A simple test plan should include a full list of all test scripts grouped by process streams. Each test script must be assigned to a functional consultant and a key user who will test it later. Ideally, the project manager should also indicate if a test script has any dependencies on other test scripts. It will save a lot of time by not running test scripts if a parent script failed

previously. Some project managers try to identify which scripts must be succesfull before going through training and even go live. What is unit testing and how do you manage it? Refer to the article conducting the functional testing. Unit testing is conducted by the functional consultants (the client is generally not involved in this phase) and is a fundamental step to eliminate bugs in the final solution. Each consultant is responsible for the testing of the functions they have been working on. Issues must be documented in the issue log, evaluated and prioritised by the project manager. The number of issues and the time required to fix themhave the potential to impact on the timing of the user acceptance testing. The project manager should have factored in enough contigency in the project plan to allow for the most critical issues to be eliminated. However, he/she could decide that some low priority issues could be covered or fixed during user acceptance. This is not an ideal situation, but should still be tolerated as to avoid compromising go live. What is User Acceptance Testing (UAT)? - Refer to the article user acceptance testing. User Acceptance Testing is more than simply testing the system with users. The project team should focus on testing the system of course but also anything that will help users running the ERP. Typically during UAT the team will test functions, documentation (operating manuals, cheat sheets, etc.) and, above all, processes. Remember that the goal of UAT is for users to take full ownership of the system and feel comfortable with the new business environment. Again, test scripts should assist the process and issues documented in the issue log. Ideally, the issue register should be reviewed by the project team on a daily basis, priorities assigned (required to be fixed before training or go live) and resources allocated to fix the issue. Scripts will have to be executed again if they fail during the first run. Performance testing The project team will need to ensure that the overall performance of the system is in line with the business expectations. This phase will depend heavily on the architecture that you have selected to support SAP Business One (installation of fat clients on each workstation, remote desktop connection, Citrix etc.). Typically, for a site under 20 users, the project team will simply test that each user can print, create documents in a reasonnable time, that the network does not drop etc. In a bigger implementation, you will need to identify the possible bottle necks of the system (i.e. what if 20 people add a sales order at the same time? What if every body connect at the same time?). Results of the performance will be documented and compared against the benchmark if one exist. Conclusion After user acceptance testing, the project team can discuss what we call a go/no-go decision to allow the project to move to the training phase. In a small implementation, and typically for

SAP Business One, most of the users would have participated to the UAT and will require only a limited training after the phase. For bigger implementation, classroom training is probably more appropriate. In any case, the testing phase is one of the most important phase of the project.

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.