OOP’s is the best way to describe Business Process Testing?
Part 2 – Testing Evolution Series:
Have you ever used Business Process Testing (BPT) as a modularized process for manual testing or as an add-on for requirements management? In the past when I talk to clients, 
If we could just digress for minute, I will attempt to draw a line between the past and present with 1000 words or less without boring you too much.
Object-Oriented Programming (OOP) has been around since the 60s, and it's taken 40+ years for application development methodology to match that type of thought process. OOP was introduced as a concept of doing more with less by leveraging the idea of reusability. The key items to OOP are data abstraction (parameterization), encapsulation (commonality or combination), messaging (passing results), modularity (business components), polymorphism (change), and inheritance (re-use). All the items mentioned above are currently found within the tool called BPT, which allows the business users, analyst, and testers using BPT to leverage the same concepts presently enjoyed by developers during the build phase of an application or system. To understand how BPT and OOPs are related within this document, please feel free to replace the word “subroutine” (function or Sub) with the words “business component,” that refers to a business or design requirement.
- Data Abstraction – can be described in BPT as a way of removing the static data from a test or use case thus allowing the business component to be more dynamic in the way it can be used. For example, the login module or component can be used for either a regular user or administrator logging into a website, as far as a business case states both login are the same the only change is the data that is passed to the business component.
- Encapsulation – typically a developer using the OOP method will take a single business requirement and enclose that functionality within a subroutine, so that whenever that business' rule is used, "All personal data must be stored on a secure database," the subroutine is called inside the code or application to ensure that the same process is followed every time. If something goes wrong the developer can then look at a single subroutine to fix the whole application. BTP works in the similar fashion, you take a business requirement and turn that statement into a modular business' component that can be reused when writing a test case or designing a process.
- Messaging – subroutine acts just like a smaller computer program; however, it is isolated from the larger program thus allow the subroutine to be call time and time again within an application. To invoke the functionality a developer must call the subroutine with the needed data known as inputs to make that piece of code work correctly, intern when the code or function has completed is execution the function will then pass back the results also known as output data. This information or results are often referred to as messaging, which can then be used either by the larger computer program or in another subroutine. BTP input and output parameters work in a related manor by passing information to or from a business component.
- Modularity – In BPT modules or business components interact with other components to achieve its purpose or process. Similar is how one puzzle piece will not reveal much, but put all the puzzle pieces together, and you get the whole picture.
- Polymorphism – is the ability to make one business component within BPT to be used to perform a different task within a business or test case. As shown in the example above the same business component can be used for a regular user or and admin login, even if they have different home pages. Usually this is done inside BPT business components by passing data inputs, which will trigger distinct outcomes.
- Inheritance – referring to two key features used by BPT to make a Subject Matter Expert (SME) job easier. The first being the ability re-use business components within the same business or test case, and the second is the ability to re-use the same business or test case and yet have a completely different outcome by just changing the data.
The increase of workload place on the manual testing groups has very few manual testers writing detail test cases in fact, if you look at most test cases resembles a statement of work “Check the inventory overstocked in the accounting menu on the vendor management screen for the update from testing the inventory order list test case.” and a lot less like a detail process that a typical IT trainee can follow. The 
The first idea that a user of BPT must realize is that test automation is not a result of BPT is just one of the many benefits of using this product. The second concept is changing the meaning of “T” within BPT from “Testing” to “Tool" for the reason that BPT is not just a testing tool, it’s also used as a within the design phase of application development. Over the years, I had great success using BPT as:
- Generating use cases using BPT can be quite simple, by using flows with BPT as a
decision point within a story. As shown in Figure 2 BPT can give the Business and Designers the ability to visualize a key business rule and how it could impact the rest of the business flow on a given application or process.
- User acceptance testing (UAT) and manual testing can take advantage of the concept BPT to enhance and speed up testing. Manual testers and business users can interchange business components taking advantage of the reusability of the components while still using their own data and test cases. In one case, I had developers use BPT components to validate unit testing.
- Another feature I just learned about was the ability to import data models into Application Lifecycle Management (ALM) and then have ALM automatically create the business component saving a great deal of time.
- If you don't have a modeling tool, I would also recommend using BPT as a pseudo modeler. It does have its limitation as a modeling tool, but on a small scale. I enjoyed the functionality and visual insight to the use cases.
- With-in ALM you can derive a business component from a single
requirement giving you the capability to collect information on that requirement every time that component is called within a test case. Furthermore, when linking requirement or component to one or more requirements the user can expose bigger security risk or unknown business issues anytime that component is called within a test case.
I watch consultants and contractors advice clients not to invest in BPT or sell their own home-grown version of a data-driven testing tool or modular testing. I've also seen and heard the stories of how slow automated testing is with BPT, and we will include solutions for each one of those issues in a later editorial called, “Attended and Unattended Testing." What I hope to change for just a minute is the user thought pattern of BPT, less as an enhancement to automated testing and start to think of BPT as part of the application design and testing solutions.
If I had to include BPT in my fictional testing Hall of Fame as mentioned in my other blog, it would be titled “the most misunderstood tool of the ALM suite of tools ever." If you’re using BPT, I would like to hear how your company or group is currently using the tool. If you have access to BPT, and you shelved it for one reason or another, I like to ask you to blow the dust off and start thinking of BPT in the context of helping tester and analyst within your groups. I’m not a sales person, I'm only a tool avocet so if you don’t have access to BPT and would like more information, please contact me. I will send you some information about the tool. In my next blog, I’ll address how automated testing is as simple as putting a 10 piece jigsaw puzzle together and also how to increase performance of your automated testing.
