A Case for Including Test Plan Efforts in Qualifying for the IIBA® CBAP® Exam

To qualify for taking the International Institute of Business Analysis (IIBA^®) Certified Business Analysis Professional (CBAP^®) exam, a certain level of training and work experience is required. This is a good thing. In particular the work experience requirement separates the CBAP^® from other certifications. When a potential employer reads CBAP^® on an applicant’s resume, it not only means that the applicant is trained in business analysis, but has worked in the field.

However, the IIBA^® excludes testing from the work experience qualification. Specifically, hours that are dedicated to: “creating and executing test scripts, reporting on testing status, creating test plans/strategies, etc.” [1] are excluded. I am willing to accept the exclusion of executing test scripts and even the reporting of their results. However, I think the IIBA^® needs to include the work effort involved in creating test plans/strategies; here are my four reasons.

• Customers define quality and testing makes quality visible. Quality is an invisible characteristic, but we can test for it. Look at any product or service; can you observe quality without some form of test? Even if it is as simple as product color; is it the correct shade? We need a comparison test. As a business analyst, can you imagine accepting a product or service without some form of quality assurance: applying standards, conducting reviews, and executing tests. If you believe in quality, you believe in testing.

• Testing is a significant portion of a successful project. Royce [2] advises that testing and implementation involves as much as 25% of project time and money. Testing involves both verification and validation. BAs verify by ensuring that developers build products and design services per technical specifications (i.e., the product or service is correctly built on best practices). Note that verification is actually planned and executed by the developers. BAs validate by ensuring that customers accept products and services per customer requirements (i.e., the correct product or service built). Validation is planned by BAs, but best executed by customers (user acceptance testing).

• Requirements without testing is “all talk and no show.” Let’s focus on test planning. The test plan consists of goals and strategies for accomplishing those goals. As a best practice, BAs trace test goals and strategies back to requirements and associated business rules. In fact, test planning completes the requirements in that it gives visibility to the quality of the requirements. There have been many times when a BA returns to clarifying a requirement due to difficultly in developing a test strategy (e.g., lack of specificity, missing business rules) – lessons learned source leading to best practices.

• The goal of business analysis is to achieve a business success. In other words, a positive satisfaction assessment that the business need is met. How do you prove a business success without testing? If BAs omit testing, where is the verification and validation of a business success? Is success the mere definition of requirements? That is like saying the business requirements document (BRD) is the end-goal; note one of the principles that drove agile development was the focus on functional software, not documentation.

A company initiates a project for an on-line operational system. The main feature of the system is a set of transactions that allows a customer to submit product orders and inquiries on those orders. The BA assigned to the project conducts interviews with customers on their requirements and business rules. In documenting the functional requirements, the BA utilizes use case scenarios referencing the appropriate business rules.

But, that is only half the story; it’s now time to make quality visible. Using the use case scenarios as a basis, the BA develops a user acceptance test plan consisting of a series of test scenarios and test cases by varying the business rule values (test case input); see Figure 1. The BA calls this test plan – validation. Note that the BA can develop the validation test plan prior to the software verification to the technical specifications. [3]

IIBA^® Response on Testing Exclusion

So there is my case with an example to boot. I invite you to comment. I sent an inquiry to the IIBA^® concerning the test plan/strategy exclusion. My thanks to the IIBA^® for their prompt response; see their comments below in quotes.

“Creating test plans and strategies is excluded from work experience in apply (sic) for the Certification exams because it is not aligned to the BABOK^® Guide.

Test plans are considered part of the Quality Assurance or Tester profession.

If a candidate has selected these options as the candidate may have interpreted the phrases as part of solution evaluation, there is an option to submit an appeal. Information in the decline email is provided for this option, if this is the case.” [4]

Essentially, the IIBA^® does not view “testing” as being part of the BA role. Obviously I disagree. When it comes to hours associated with test planning/strategies, the IIBA^® should accept them as work experience in qualifying to sit for the CBAP^® exam.

Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) International and the International Association of Facilitators (IAF).

Mark is the President of Monteleone Consulting, LLC and author of the book, The 20 Minute Business Analyst: a collection of short articles, humorous stories, and quick reference cards for the busy analyst. He can be contacted via – www.baquickref.com.

1. www.iiba.org , see CBAP^® Handbook
2. Royce, Walker, Software Project Management: A Unified Framework, Addison-Wesley Object Technology Series, Sept. 1998
3. Monteleone, Mark, A Proposal for an Agile Development Testing V-Model, www.modernanalyst.com
4. Golding, Mini (IIBA^® Operations Manager), e-mail to Mark Monteleone in response to inquiry, Feb. 17, 2016