Business Testing in Projects
Tuesday, November 26, 2013
Have you ever been involved with a project that didn't deliver what was expected?
The project may have failed to meet expectations because the new process or system didn't work properly.
Perhaps users didn't follow the new procedures and caused problems for others.
Or maybe they couldn't understand the training or documentation they'd received.
Do you recall hearing people say things like "It was better the way we did it before"?
So, how can you avoid this problem?
Effective "Business Testing" can help. Testing has a fundamental role in making sure that your projects' end-products are delivered successfully.
Business testing (also known as User Acceptance Testing, or UAT) is usually carried out by the people who will be using the product in practice. It ensures that proposed changes actually work – BEFORE they're put into use.
In this article, we'll show you how to set up a successful business test. This will help you involve business users and other stakeholders to check that your project delivers the desired results. It also helps you ensure that the systems and procedures you implement work efficiently, effectively and accurately.
How to Use the Tool
Consider using business testing in any project where you want to ensure that deliverables are robust and usable before they're implemented.
Here are some steps to help you think through your business testing requirements.
Step 1: Learn from other projects
Make sure you understand the testing challenges and problems faced on previous projects. Ask your colleagues, or check previous
Post-Implementation Reviews , if they're available. This will give you insight into what tends to work, and what tends not to work in your organization. Remember, history often repeats itself: for example, if other projects have had difficulties getting resources for testing, it's likely that yours will too.
Step 2: Decide what to test
Figure out what needs to be tested by considering the following:
Handover points – Consider all handovers between different systems and different groups of people. You'll often find issues in these areas.
Key project risks – Determine your key project risks by using our
risk analysis and risk management tool . This analysis will help you identify areas where you need to focus.
End-to-end processes – If possible, test process and system changes from start to finish, including tests for each variation of the process.
Impact assessment – Consider the potential impact of launching your project outputs without testing them. Would errors cost you more money, lose customers, or cause delays? Would these errors be acceptable to the business? Prioritize testing in high risk areas.
Other options – What other options do you have? For example, if you're revising an internal classroom-based training program, you may want to consult key staff in its development. By running a pilot with the first training group, and then making revisions for subsequent groups, you may be able to manage risk sufficiently well to avoid carrying out business tests.
Step 3: Consider what support is needed for your testing process
Think about the following elements of testing:
Budget – You may need to include all sorts of cost in your budget. Here are some examples:
Room rental.
Computer equipment.
Printing costs for training material.
Expenses for participants.
Additional staffing or contractors' fees.
The right people – Involve people who perform, or will perform, the tasks being tested. Also, consider the extent to which you want to include the following people:
Key influencers – This is useful where you want to build support for your project with major stakeholders.
Advocates of the new process/system – Advocates will often work hard to make sure that the deliverables meet the requirements.
Resisters to the project (handle with care!) – They're likely to show you how new processes can be broken, and they'll give you ideas for points to include in any training or support documentation for users. You may even change resisters into advocates as they learn about the benefits of the new system or process!
As well as having the right people to perform the tests, think about how you'll manage testing. Your testers will need to know what tests to conduct, and your project team will need to know what changes to make as a result of the tests.
Testing location – Consider how much space you'll need and where it must be located. For example, if a process involves working remotely, you may want to simulate this in the way you set your testing up.
Tester training – Determine what training your testers need.
Tip:
Use your end-user training documentation during business testing. When you do, you'll be able to test the training material and the new process or system at the same time! If this isn't possible, use feedback from testing when you develop or finalize your training material.
Documentation – Consider what documentation your testers need. For example, when testing systems, testers often use a series of "test scripts." These take them through individual roles and activities within an end-to-end process. You can then group test scripts to test your whole process.
Note:
If you've mapped your new or amended processes using Swim Lane Diagrams , it's usually easy to see how many test scripts you'll need for each end-to-end process.
Step 4: Determine how much testing time is needed
You may be able to conduct the testing phase quickly with a small group of people, or you may need more extensive and comprehensive planning. To figure out what's right for your project, consider what you need to test and how you should organize testing. You may have other goals too. For example, it's often appropriate to consider testing as a way to gain support for your project from key stakeholders.
Allow time to prepare and train your testers. Without this, they may focus on how the new system or process works and not on finding its problems! Also, include sufficient time and resource to conduct the tests, make any changes needed, retest any revisions, and provide for a contingency.
Note that testing usually takes place toward the end of the project. So, if the project has had delays, there may be pressure to shorten the testing time. Be clear about the essential components in your testing approach (there's more information about planning approaches in our article on Critical Path Analysis and PERT Charts ). Remember, if the deliverables don't work once they're implemented, no one will thank you for skimping on testing!
Check when the testing phase is due to take place. It's often difficult to get people released from their regular duties during holiday times or when the business is particularly busy. And make sure that you schedule time after testing to update any training material, supporting documentation, and procedures for users. This will ensure that this information is accurate once testing is complete.
Step 5: Determine what reporting is needed.
Consider whether to collect statistics during your testing phase (for example, the number of problems found, the number of problems fixed, and so on), and discuss the overall reporting requirements with your sponsors and other stakeholders.
Tip:
Making revisions based on business testing results is often stressful!
Project managers want to ensure that their project is delivered on time, within budget, and to the required quality standard; and compromises are sometimes needed to balance these different goals.
You can minimize this conflict by putting a scope management process in place, ensuring that roles and responsibilities for managing changes are clear, and including time in the plan for implementing and retesting revisions.
You may also need to be assertive to manage unrealistic delivery expectations!
Key Points
Business testing is a useful tool for making sure that a new process or system works properly before you implement it.
By using this tool, you'll ensure that your testing phase is set up effectively, and that you can influence any decisions that must be made to get the right balance between delivering a project on time, on budget, and to quality standards – even if compromises are needed.
Tags:
Project Management, Skills
The project may have failed to meet expectations because the new process or system didn't work properly.
Perhaps users didn't follow the new procedures and caused problems for others.
Or maybe they couldn't understand the training or documentation they'd received.
Do you recall hearing people say things like "It was better the way we did it before"?
So, how can you avoid this problem?
Effective "Business Testing" can help. Testing has a fundamental role in making sure that your projects' end-products are delivered successfully.
Business testing (also known as User Acceptance Testing, or UAT) is usually carried out by the people who will be using the product in practice. It ensures that proposed changes actually work – BEFORE they're put into use.
In this article, we'll show you how to set up a successful business test. This will help you involve business users and other stakeholders to check that your project delivers the desired results. It also helps you ensure that the systems and procedures you implement work efficiently, effectively and accurately.
How to Use the Tool
Consider using business testing in any project where you want to ensure that deliverables are robust and usable before they're implemented.
Here are some steps to help you think through your business testing requirements.
Step 1: Learn from other projects
Make sure you understand the testing challenges and problems faced on previous projects. Ask your colleagues, or check previous
Post-Implementation Reviews , if they're available. This will give you insight into what tends to work, and what tends not to work in your organization. Remember, history often repeats itself: for example, if other projects have had difficulties getting resources for testing, it's likely that yours will too.
Step 2: Decide what to test
Figure out what needs to be tested by considering the following:
Handover points – Consider all handovers between different systems and different groups of people. You'll often find issues in these areas.
Key project risks – Determine your key project risks by using our
risk analysis and risk management tool . This analysis will help you identify areas where you need to focus.
End-to-end processes – If possible, test process and system changes from start to finish, including tests for each variation of the process.
Impact assessment – Consider the potential impact of launching your project outputs without testing them. Would errors cost you more money, lose customers, or cause delays? Would these errors be acceptable to the business? Prioritize testing in high risk areas.
Other options – What other options do you have? For example, if you're revising an internal classroom-based training program, you may want to consult key staff in its development. By running a pilot with the first training group, and then making revisions for subsequent groups, you may be able to manage risk sufficiently well to avoid carrying out business tests.
Step 3: Consider what support is needed for your testing process
Think about the following elements of testing:
Budget – You may need to include all sorts of cost in your budget. Here are some examples:
Room rental.
Computer equipment.
Printing costs for training material.
Expenses for participants.
Additional staffing or contractors' fees.
The right people – Involve people who perform, or will perform, the tasks being tested. Also, consider the extent to which you want to include the following people:
Key influencers – This is useful where you want to build support for your project with major stakeholders.
Advocates of the new process/system – Advocates will often work hard to make sure that the deliverables meet the requirements.
Resisters to the project (handle with care!) – They're likely to show you how new processes can be broken, and they'll give you ideas for points to include in any training or support documentation for users. You may even change resisters into advocates as they learn about the benefits of the new system or process!
As well as having the right people to perform the tests, think about how you'll manage testing. Your testers will need to know what tests to conduct, and your project team will need to know what changes to make as a result of the tests.
Testing location – Consider how much space you'll need and where it must be located. For example, if a process involves working remotely, you may want to simulate this in the way you set your testing up.
Tester training – Determine what training your testers need.
Tip:
Use your end-user training documentation during business testing. When you do, you'll be able to test the training material and the new process or system at the same time! If this isn't possible, use feedback from testing when you develop or finalize your training material.
Documentation – Consider what documentation your testers need. For example, when testing systems, testers often use a series of "test scripts." These take them through individual roles and activities within an end-to-end process. You can then group test scripts to test your whole process.
Note:
If you've mapped your new or amended processes using Swim Lane Diagrams , it's usually easy to see how many test scripts you'll need for each end-to-end process.
Step 4: Determine how much testing time is needed
You may be able to conduct the testing phase quickly with a small group of people, or you may need more extensive and comprehensive planning. To figure out what's right for your project, consider what you need to test and how you should organize testing. You may have other goals too. For example, it's often appropriate to consider testing as a way to gain support for your project from key stakeholders.
Allow time to prepare and train your testers. Without this, they may focus on how the new system or process works and not on finding its problems! Also, include sufficient time and resource to conduct the tests, make any changes needed, retest any revisions, and provide for a contingency.
Note that testing usually takes place toward the end of the project. So, if the project has had delays, there may be pressure to shorten the testing time. Be clear about the essential components in your testing approach (there's more information about planning approaches in our article on Critical Path Analysis and PERT Charts ). Remember, if the deliverables don't work once they're implemented, no one will thank you for skimping on testing!
Check when the testing phase is due to take place. It's often difficult to get people released from their regular duties during holiday times or when the business is particularly busy. And make sure that you schedule time after testing to update any training material, supporting documentation, and procedures for users. This will ensure that this information is accurate once testing is complete.
Step 5: Determine what reporting is needed.
Consider whether to collect statistics during your testing phase (for example, the number of problems found, the number of problems fixed, and so on), and discuss the overall reporting requirements with your sponsors and other stakeholders.
Tip:
Making revisions based on business testing results is often stressful!
Project managers want to ensure that their project is delivered on time, within budget, and to the required quality standard; and compromises are sometimes needed to balance these different goals.
You can minimize this conflict by putting a scope management process in place, ensuring that roles and responsibilities for managing changes are clear, and including time in the plan for implementing and retesting revisions.
You may also need to be assertive to manage unrealistic delivery expectations!
Key Points
Business testing is a useful tool for making sure that a new process or system works properly before you implement it.
By using this tool, you'll ensure that your testing phase is set up effectively, and that you can influence any decisions that must be made to get the right balance between delivering a project on time, on budget, and to quality standards – even if compromises are needed.
