OpenText Business Processing Testing Reviews

This solution is very helpful to me. I use it to execute my use cases without a manual interface. 

There's only one thing that I think needs improvement. When I started off using this solution, I used the Google search engine to learn how to use the tool. I would also check with my colleagues who have a lot of knowledge about it. Selenium has fields of information available. If you click on that field there will be an explanation about how to use the tool. It will be a lot easier to understand if Micro Focus included this feature. It is easy to find with the search button, but it would be a great help to the users who are new to this tool.

I have been using Micro Focus Business Process Testing for the last two years. 

I have not contacted their technical support. 

I would rate it an eight out of ten. 

I would definitely recommend it. 

The most valuable feature of the solution is that even a nontechnical tester, like a functional tester or a business analyst, can use it once the components are ready. It becomes easy after a certain point. Its usability is its best feature.

The solution shouldn't be so tightly integrated with the ALM tool that they have. It should have its own base rather than the repository. If we could save it in other repositories or some other spaces, then that would be a plus.

We should also be able to create a BPP script on its own.

The solution is quite stable with SAP. It's nice. I use it extensively. With the web sometimes, it can get a bit difficult, especially with the flex objects. There's no clear solution to a flex object. That's something that I have trouble with.

Scalability depends on the framework, and also the team that sets it up. If it is set up properly, then yes, it is scalable. You can scale it well. We have about 15 people using the solution currently. I'm not sure at this time if we plan to scale further.

Overall I'm satisfied with technical support. I wouldn't say it is as great as Tricentis Tosca, but they are good. I know for sure that Tosca is very efficient in getting back to users if there are issues. 

The initial setup is very straightforward. It's not complex at all.

I did the implementation myself.

We use both the cloud and on-premises deployment models of the solution.

In terms of general advice, I would say that any tool that you plan to use, you need to plan it well. You need to outline the complex and specific scenarios that you plan to use in your project. You should do a POC first, whether you choose Micro Focus or something else.

I would rate the solution at seven or eight out of ten.

The biggest advantage of Business Process Testing is that not only technical skilled people can participate with test automation but also business analysts, which will create better test cases then test automation experts can. The maintainability is also much better than in traditional approaches, but that also might depend on the architecture which is used.

Because everyone can create test cases, not only the quantity but also the quality is improved, which results in less defects in production. Also, there is less dependency on technical consultants so they can focus on other tasks.

The run speed is not as fast as if a local script would be running, but that is one of the downfalls of using a client/server approach.

I started using it for about four years ago. Back then we used ALM 11 and BPT with QTP technology.

We have a DTAP environment, deploying in production takes a bit more effort than in a test one because of the security dependencies we have.

There are no stability issues.

Scalable is key for BPT as for one project we are using it with 50-100 users. When scaling up, it’s important to have a small team which is responsible for the framework while the rest of the team is just using it.

To be honest, technical support is not that great. We use CGI for technical consultancy who are a bit faster and better than the support of HP. The R&D part of HP is helping us with issues that they cannot solve.

Before using BPT, I mostly used TD/QC in combination with QTP. We used it with a custom framework. The main issue with most test automation frameworks (including the last one) is that they are highly technical and are hard to maintain. This resulted in a high dependency on third parties instead of being able to let the scrum team being able to be self sufficient.

Test automation specialists helped us with setting up the framework. It should be done with experts because the architecture has to be setup in a way that matches with the client.

The BPT framework is very flexible, which can result in suboptimal results when used by inexperienced users.

CGI helped with implementing and training the teams. We have three defined levels of test automation; level one is creating test cases, level two is modifying components, and level three is changing the framework components.

ROI is in most projects within a year if you compare it with manual testing. For smaller companies the HP tooling is indeed an expensive one.

ROI is not easy to calculate because there are some benefits which are not comparable with currency. For example, how do you rate quality.

It has room for improvement, but in my opinion it’s at the moment “best in class” when used in a (bus) DevOps environment. The most important part is that the components and flows should match with your product under test. Involve the business at the start of the implementation phase.

Various features provide us with various benefits. We use UFT for the scalability and cross-technology diversity, UFT API for the web-service and database related testing, and HP BPT for the modular testing.

We can now take test automation through the entire business process -- testing web service availability before automated test packs start, sending and retrieving data via web-services and control of all web service testing in a single tool, along with the GUI testing of business processes across a multitude of platforms from java web through to AS400 green screen terminal apps. BPT allows you to manage all the test resources and artifacts inside of Quality Center, including all data and test flows, and to have a single point for reporting.

To give you an example, we built a series of tests that would firstly fire off web-service calls to ensure the required services were running. We would then do data creation using a series of Excel VB functions (called by UFT through BPT), and then launch into GUI testing of complex webmethods Java web portals to take a business process through a series of screens, capture required data and test screen functionality, write all runtime data back to QC datasets, then call the data later in the BPT test to validate it across database checks using HP UFT API, build and execute SQL queries, and finally validate information for accounting purposes of data sitting on AS400 or payment databases.

Initial releases we used of the product (v12) were a little unstable, but with the release of v12.01, we had no further issues.

I've used it for three years.

There have been no issues with the deployment.

The tool is extremely versatile and robust, so much so that we hooked QC into Jenkins to handle all of the test runs (scheduled times) and executions and to fire off customized reports on completion of the test runs, for a total autonomous solution. I could even say that any task that was presented to us was achievable using this solution. So scalability and cross-platform usability were not an issue at all.

There were no issues scaling it.

Customer service is always high with HP.

We did find that technical support was a little limited as no-one really has the technical knowledge in South Africa to assist us.

Fairly straightforward, but then we sourced and employed a skilled adaptable automater (Marco), who had previously worked with the product, and brought a wealth of information and know-how to the table. If the solution is understood and the capabilities of the product are understood, then the product is not that complex. There are many facets on how the product needs to be setup and configured which play a huge role on how you design and implement your BPT solution, specifically around data and shared assets in QC.

In-house, but we had the right-skilled resources on our team as mentioned above, coupled with working closely with out in-house development teams and architects to get the best out of the solution. Hire the right people for the job, or get skilled consultants in to aid with setup, configuring and training – it makes a world of difference.

ROI is a hard one, but one project we automated, took a little under three weeks to do using BPT, and saved over 180 hours of manual testing per test cycle. Obviously, not every automation effort has a high return, but where you see your investment ROI, is where tests have to be run multiple times. Automation effort vs. repetitive natures of test = visible return.

The product is fairly reasonably priced, so make sure you get the full BPT functionality enabled, but speak to someone who currently works with the product if you have any concerns around limitations. Also get someone in to show you how to do things. Trying to figure things out for yourself takes time, and can lead to frustration, rather get a head-start and get stuck in with a pro. You will then get exposure to what the product suite can do, and all the functionality available, so that you can get the best out of the experience.

Its simplicity and easy to integrate approach. By using this solution it is relatively simple to design test suite that can be further drilled down to very simple and atomic business components. The other part is that even functional testers/SMEs can actively take part in designing automated scripts by using the pre-designed automated components without going into the details of implementation. As a result the team productivity increases very rapidly.

In our agile team, the functional testers started designing the automated test scripts by using the automated business components and requesting for new components to be designed. As a result the team productivity increased a lot after switching to this framework. Also the SMEs can review the test script on a high level to check for accuracy.

Since all the artefacts are maintained in Quality Center sometimes accessing tests to maintain and modify takes a lot of time. If there is network failure while opening then the corresponding script gets locked for a long time. So it would be really convenient if they create a local copy of the component or give option to the user to edit the component or script offline.

Another thing is components should have the ability to copy within the script itself rather than dragging the component from the repository each time it is required to be used.

I've used it for two years.

Few scripts got corrupted in design time while trying to delete the components that are having dependency in parameters early in the tree.

There was no issue with the stability.

There was no issue with the scalability.

Really the weak link of this otherwise so good product. Technical support lacks efficiency and all they do is to move in circles by opening new tickets and all the related stuffs without any intention of solving the real problem.

This was chosen by the client as a necessary link up of automation with HP Quality Center.

Setup is quite straightforward and scalable.

Setup and implementation of the framework was done by our organization.

ROI is pretty good as the approach of framework allows virtually everyone to take part in designing test cases.

The price could be reduced though to make it more competitive with other products available.

Go for this product only if you have a long time vision of the software under test as this will yield significant output only after investing good amount of time.

The most valuable features for us are the re-usability of content and the ease of building test content. We also like the reusability of content and the fact that both manual and automation engineers can run the same test cases.

The BPT framework is very modular. It has drastically reduced the amount of content we manage for each application, which in turn reduced the amount of maintenance we had to perform. This, of course, resulted in a faster ROI.

Test Execution speed has been my biggest concern. HP has improved on it over releases, but there is still room for improvement.

We haven't had any issues with deployment.

It's been stable for us.

We've scaled it sufficiently for our needs.

There is learning curve involved in developing best BPT automation framework. Please research on best practices to implement BPT.

I like the modularity in the framework.  

BPT is a fast way to develop automated tests.

The big difference with BPT over conventional frameworks with which I have worked is that BPT allows me to separate test development from automation development.

We implemented this in complete regression suite in an automated fashion.

The only one I can really think of is speed to test execution.

5 Years

We used QTP and we switched to BPT. In BPT everybody can participate in designing automation. Even a manual tester can also write the automation component and then later an automation tester can automate the component. 

It's pretty simple to implement this framework as compared to other frameworks in QTP.

A vendor team was not required.