Appendix B – Key Points

The chapters in Part II described the process leading up to the acceptance decision from the perspectives of the Business Lead, Product Manager, Test Manager, Development Manager, User Experience Specialist, Solutions Architect, Enterprise Architect, Operations Manager, and Legal. For convenience, we summarized the key points here. There are Key Points common to all roles and others specific to each individual role.
The following table lists Key Points that are role specific and what roles they are specific to.
<The table will be updated and available on testingguidance.codeplex.com>
vol1-App-figure-3.png
Figure 1 Key Points specific to individual roles

Key Points Applicable to All Roles

Key Points for Business lead

  1. Treat acceptance as a process not an event: Appreciate the fact that acceptance testing will not be a single discrete event, but a process with a distinct start and end.
  2. Recognize there may be many decision makers: The process may require decisions by many parties each supported by data collection activities. Each party likely has very different requirements and interests; you need to be aware of them and communicate them to the supplier(s) to ensure they address them.
  3. Define the scope of testing: Have a clear understanding of what will be tested by the supplier and what you are expected to test. Typically, supplier is expected to do thorough (e.g.) testing of all capabilities and quality characteristics (such as performance, reliability, usability etc.) before handing off system for AT. Does the supplier have the environments for integration testing without in-house systems?
  4. Delegate decisions: If you don’t have enough time or understanding to take part in the project, assign a proxy to represent you and have a clear understanding of the kinds of decisions they can make with/without consulting with you.
  5. Delegate work/testing: Have a clear understanding of your (organization’s) abilities w.r.t. testing skills. Contract other parties to help you test if necessary. But don’t underestimate the effort involved in managing the testing outsourcer as they will need to learn your business domain and requirements before they can be effective.
  6. Understand the test environments: Understand where you will test. Be clear on how you’ll get the new release candidates delivered
  7. View tests as requirements: Acceptance criteria/tests should be articulated/prepared before the software is built and shared with vendor as a way to flesh out the details of the requirements.
  8. Recognize the choice of process impacts everything: Two key styles of AT: Final Test Phase and Incremental AT. The former concentrates most acceptance activities at the end of the project. Incremental acceptance testing spreads out the work and reduces risk but requires all parties to work in different ways.
  9. Estimate acceptance effort & duration while realizing it is difficult to estimate: Estimating the effort & duration of acceptance testing is hard; time-boxing the final acceptance testing cycle is common but requires past experience to come up with reasonable duration/effort. If in doubt, guess high and allow for several cycles of acceptance testing to give the vendor time to fix bugs.
  10. Use incremental acceptance testing to reduce uncertainty of estimating: Can avoid some of the uncertainty and most of the risk by doing incremental acceptance testing. Bugs found earlier identify ambiguity in the spec while there is still time to address it and can be fixed long before the final acceptance test phase.

Key Points for Product Manager

Key Points for Test Manager

Key Points for Development Manager

Key Points for User Experience Specialist

Key Points for Operations Manager

Key Points for Solution Architect

Key Points for Enterprise Architect

Key Points for Legal