Join Haydn Thomas for an in-depth discussion in this video Using testing techniques, part of Business Analysis Foundations.
- Watching waves roll in on the beach can be peaceful. When you want to surf the waves you spend some time assessing them. Can you surf the set, or is there too great a risk of getting dumped? You go on out and test the set, if you get dumped by one of the waves you get up and try it all over again. If you're constantly getting dumped you need to reassess. Testing deliverables from projects is no different. We start with a test strategy document. This high-level document defines the testing approach to achieve testing objectives.
Test strategy is normally derived from the requirements package. The test strategy document is a static document, meaning that it is not updated too often. It sets the standards for testing processes and activities and other documents, such as the test plan draws its content from those standards set in the test strategy document. By involving the business in this you'll create a sense of ownership, and they'll become familiar with the solution before it's implemented, providing them with a sense of comfort and confidence and ownership of the output.
Supporting the test strategy is the test plan document. The focus of this document is to describe what to test, how to test, when to test, and who will do what test. A test plan should be created for each phase of testing. The test plan should contain the following information. The identified scope and objectives for the test phase. Testing roles may include testers, managers, business analysts, business experts. The required testing tools and documents, and entry and exit criteria for the test phase.
The test strategy in test plans provide the overall roadmap for testing. These documents become the foundation of the testing activities, and expectations for the project. As the business analyst you may be writing these documents, or at very least providing significant contributions to the content. It's very important for you to understand and support the information contained in these testing documents. As soon as a subset of the solution has been created the business analyst should be formally testing the set of functionality via a test case.
The sooner execution based testing can be performed the better. Lessons learned can be applied immediately to ensure the same types of defects are not further developed into the solution. Testing is not a one-time event. Testing should be performed throughout the project life cycle. For instance, once the requirements are written they should be reviewed, and agreed by a variety of key stakeholders. This review process is non-execution based testing technique, as you are testing the documented requirements.
As soon as the requirements are written and agreed, test cases can and should be written. As you are writing the test cases you may realize the requirements were not as specific or clear as originally thought, making it difficult to write measurable test case. This provides the opportunity to update the requirements for clarity earlier in the project lifecycle, and write very good detailed test cases. The solution is ultimately being created for the business. You need to engage the business actively throughout the testing phases.
Not only can they assist with a significant amount of work that needs to be completed, the business will provide insights that you can't possibly have. Testing of the requirements is the final hurtle to ensure what was asked for will be delivered, and meet the expectations of the stakeholder. The verification and validation exercising testing is normally carried out by completing the test groups in cycles. Testing can be effective and efficient if it's performed in a systematic fashion. You may need to run through a number of testing cycles until you consistently achieve the expected result.
Testing of a solution does not need to be complex. Testing in waves is the key to success. Creating testing opportunities throughout the project lifecycle, coupled with comprehensive execution of your test plans will prevent big surprises near the end of the project, and hopefully you'll be riding the big wave of project success.
Discover where business analysis lives in the project life cycle, how to initiate a project, the best way to gather requirements, and smart strategies to monitor results and test outcomes.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Understanding what business analysts do
- Defining business opportunities and objectives
- Identifying stakeholders
- Gathering requirements through observation and brainstorming
- Validating requirements
- Developing project acceptance criteria
- Implementing, testing, and closing your project<br><br>
- The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.