BPT - Business Components v/s Scripted Components

BPT aka Business Process Testing framework has gained popularity in recent years. BPT tightly integrates with QC and gives its user easy to use UI for creating Business Process Tests. I have been working with BPT for over 2 years now and have been involved in implementing framework solutions for the same. Today I would be discussing on Business Components v/s Scripted Components. Note, This article is purely based on my experience with BPT and my personal/professional view on the same. One may or may not agree with the same

Before we dive into the comparison, I would like to define the key terms for this article

• Business Component – A component created using keyword view and doesn’t support Expert View
• Scripted Component – A component created using Expert view, keyword view is also supported but different from the view in Business Components
• Business Process – Business process combines Business Components or Scripted Components in a sequence to create a Business flow or the complete Test Case

It is important for us to understand the key difference between a QTP Test and a Business Process Test. A QTP Test can involve re-usable keywords through use of Actions and Functions. A QTP test can call these Actions and functions in sequence within in the same Run session

Same run session, now this is where the key difference lies when it comes to BPT. In BPT each component (Scripted/Business) is similar to an individual QTP Test which contains only one Action. So when a business process runs it runs each component one by one. Since each component is similar to a QTP Test, QC loads the component in QTP, starts the run, once the run finishes; the next component in the Test is loaded. BPT then collates all the results under a single test result summary. The load, run, stop and unload sequence of components decreases the performance of Business Process execution over normal QTP frameworks. The more the no. of components in your script, the slower it would be.

Business Components v/s Script Components

A business component is a keyword driven component which can be used to perform operations on selected objects present in OR. Business components are easy to create and the process can be easily taught to manual testers as well. This point which projects that BPT testing can be handed over to manual testers for maintenance is the key attraction to companies for going for Business Components over Scripted components.

When choosing Business components the development phase becomes easier, as not a great deal of technical or scripting skills are required by the team. Though most project miss to see is the maintenance and execution cost involved when going with Business components. Business components with advantage of being simple take away the power of flexibility. We cannot use loops, if-else, select statements inside a business component. This increases the number of components that needs to be developed. Consider a online product ordering system, the general sequence to order a product may be something like below

• Launch Application
• Search Product
• Add product to Cart
• Product Configuration
• Checkout
• Login to Account
• Checkout Process
• Logout

Now Launch Application and Logout are two very common components that would be used across almost all the test case. Product Configuration for different products may involve different screens on the UI. This means for every product we might need to create a different business component. Now these components may have some code in common and rest different from others. To support 15 products in our Test Suite we would need 15 product configuration components + 7 components.

Not every test in our component uses all these components, some test cases may require additional components to do extra verification or they do deviate from the normal flow. This makes it necessary to create as many re-usable components as possible, which are required to implement the test.

Assume that our 15 product test suite requires additional 13 components for product specific verification. Our final test suite implementation now has 35 components and 15 Business process tests. Each business process would use Avg. of 8-9 components. This no. is not huge as such but in projects which involved E2E (End to End) testing the no. can grow as huge as 80-100 components for some of the tests.

In BPT when a test fails, it needs to be run from the start. The test cannot be resumed from a component in between. This is a limitation of BPT. So if our test fails on the 8th component, there is now way to re-run it from that position. This makes it difficult to unit test business process tests and makes the process a bit more time consuming than normal

Now during maintenance consider that one of the objects common across all product configuration gets removed. This change would require us to open each product configuration component and then remove the object. This not a huge task for 15 products, but certainly a huge task when you are supporting over 100+ product configurations. QTP only allows opening one component at a time which means the update can be applied one by one only

To summarize using only Business components would lead to

• Higher number of reusable components
• Higher avg. no. of component calls in Business Process
• Higher execution time
• Higher maintenance effort

Now I will show how using Scripted Components we can overcome the above issues

• The first step is to convert all the components to scripted components
• Once the components are converted to scripted components, copy the code inside a function with the same name as component

   

  Function LoginToAccount() Browser("").Page("").WebEdit("userName").Set Paramater("sUserName") Browser("").Page("").WebEdit("password").Set Paramater("sPassword") Browser("").Page("").WebButton("Login").Click End Function

• Now instead of having code in the component we would directly call this function
  
  

   

  Call LoginToAccount()

  The advantage of using this approach is that everything moves into library file. We cannot open multiple components in QTP but we can open multiple libraries at the same time. This makes it easy to maintain scripts when multiple components need to be updated

• Another enhancement that can be done is merging of the components to perform multiple operations. When adding a product to cart we would always be performing Search Product and Add product to Cart. Though it may not be necessary that when we search a product we would always add it cart i.e. we might want to call a component which does product description validation. So we need to create the component in such a way that we can control which action is performed. This can be done by adding 2 flag parameters to the component bSearchProduct and bAddProductToCart. In the component we can modify the code as below

   

  If UCase(Parameter("bSearchProduct")) = "TRUE" Then Call SearchProduct() End If   If UCase(Parameter("bAddProductToCart")) = "TRUE" Then Call AddProductToCart() End If

  This merging of component reduces the average no. of components required to create a Business Process test. This reduction will result in performance improvement in execution. To give an example, I was able to reduce avg # of components in our project from 15 to 5. This gave an execution time reduction by 120 sec per script. This in a test suite of 1600 scripts was a huge saving. It also reduces the number of components in the Test suite, making maintenance easier.

• Next step is to merge similar components into one. Consider the product configuration component in this case. We created 15 components for 15 products, instead of that we can break the code into 16 functions. 1 function for common configuration and rest 15 function for product specific configuration. The component can be then update as
  
  

   

  Call CommonProductConfig() Select Case Parameter("strProductName") Case "ProductA" Call ProductAConfig() Case "ProductB" Call ProductBConfig() Case … End Select

  This approach makes maintenance easier when something in the Common product configuration changes as the changes only need to be done in CommonProductConfig function. This also increases the code re-usability in components.

• Another improvement that can be done is based on adding flexibility to parameter values. To give an example if we add multiple products in our scripts then instead of calling our newly merged component twice, we can add flexibility to our component to take “;” separated product names in the component parameter
  
  

   

  arrProductNames =  Split(Paramater("sProductName"), ";") For each sProductName in arrProductNames Parameter("sProductName") = sProductName If UCase(Parameter("bSearchProduct")) = "TRUE" Then Call SearchProduct() End If   If UCase(Parameter("bAddProductToCart")) = "TRUE" Then Call AddProductToCart() End If Next

  Note: We didn’t touch the core functions here and they still process the normal product name, they don’t interpret “;” separated products. This logic is instead kept in our scripted component code. That is the reason we add the code Parameter(”sProductName”) = sProductName inside the loop

We can see how using scripted components we have enhanced our test suite to be more flexible and easily maintainable. But for few this may also appear as a disadvantage as it requires some coding skills for maintaining the suite. But isn’t it worth to upgrade skills for people maintaining the test suite? Well I will leave that answer to you