UFT BPT Framework is it worth it?
I am just looking for some advice from the more experienced people on this site. I have used QTP in previous positions and have used datadriven and keyword driven frameworks with relative success. What I like about them is the control you have and the simplicity of use.
I have just started with a new position and have not used QTP in 1.5 years and its my first introduction to UFT.
The engineer here got some training from HP and has gone down the QC/BPT/UFT route.
I don't understand it enough to expand on this...lots of defining parameters on business components, redefining them on the Test Plan level and then further mapping them the an external data file.
To me it just seems to be overly complex and error prone (hp defects, user inexperience etc).
Is it an advantage to go down this route (cause I can't see one at the moment)? I am only using it 1.5 days so its difficult for me to make a call.
I will be asked for my opinion and at the moment I would go for a keyword driven approach any day over this QC/BPT/UFT approach.
Any information or experiences would be very greatly appreciated.
Last edited by gerfoy3; 09-20-2013 at 06:02 AM.
The advantage of BPT or homegrown frameworks like it is supposed to be that the business folks can write/review test cases in plain english.
I sat in on BPT training a few years ago. I followed along with the class, but it still made very little sense to me. I think that I would have had to have a lot more practice to get some understanding.
It seemed as if I would catch on with some practice until someone asked "how does this work with custom SAP trasactions" The answer was a third party could program it for us or we could have someone on the team learn how to do this. I looked at the code for customizing and it looked mysterious.
BPT looked like it would be good to know, but I saw some learning curve and then a lot of work that looked like being stuck in Keyword View of QTP/UFT for ever.
I haven't used BPT. Listening to their pitch, it seems like it's a way of organize tests by requirements and components. I think BPT's advantage over a simple Keyword driven framework is you have associated your test to it's requirement and dependencies. For example, 'flows' and 'steps' are associated with components. One can say, I made a change in the Login module, here are all the tests you want to run. Or say, I have changed the requirement adding a step in the registration process, then here are all the tests that need to be updated and run.
It's not uncommon for an enterprise to have 2000 or more tests. Enterprises need to prioritize which tests are run, and need to know which tests need to be updated with every requirement or component change.
Last Fortune 500 I worked at had around 400,000 tests. Management of tests, reusability, and test efficiency becomes very important at that scale. We did something like BPT but it was custom written. Was efficient enough that I was able to keep the associated automation up to date by myself. The test data and flow was handled by the manual testers.
Last edited by NoUse4aName; 09-20-2013 at 08:47 AM.
BPT is no different from a zillion other frameworks that abstract the code in such a way as to expose it to non-automators, you can do pretty much exactly the same thing with manual templates and a driver script. BPT just gives you an easy way to expose parameterised blocks of code outside the automation team. Anyone can then use those parameterised blocks of code to build data driven tests in QC without the need to use external data files (not sure why your engineer is using them as they are not required unless you are doing multi-lingual as QC doesn't cope with multi-lingual - at least not in 9.2 anyway with the way we have it set up - the joys of being in the dark ages). The automation team don't even need to do all the coding either, if you record the application objects, then the manual team can actually use a keyword view to "write" the code. Unless there has been improvements though the keyword view for BPT in QC doesn't allow you to use control structures so can end up with a whole bunch of duplicated code if you let them do that, although you can write your own keywords as well that do more than just click, select etc. You basically end up with a keyword framework at the component level and a data driven framework at the test level.
Personally, I don't like letting non-automators write components, I prefer only to allow scripted components and have as little code in those components as possible. I try to keep the components pretty high level and aligned with business process and just call into function libraries that do most of the work. When I've had to take over projects that other people have done using BPT I've typically found lots of small, very specialised components, with lots of duplicated code and nothing in shared function libraries, poor performance and a maintenance nightmare. BPT while being very easy to use, also makes it very easy to end of with a lot of poor quality scripts.
All that said, BPT does make it easy to involve people outside the automation team with very little upfront work. You really can do as little as record the application objects and let the manual team have at it. Just don't expect great results.
Oh, and another downside, you may be locked into a similar version to QC that the company is using. QC/BPT/QTP being more integrated you don't have as much flexibility when it comes to using the latest and greatest QTP as your QC version might not allow it. I'm still waiting for a QC upgrade so we can upgrade QTP from 9.5, I wouldn't have that constraint if we weren't using BPT.
Probably too late for the OP, but...
It's certainly been worthwhile in my experience. In the large corporation I work in, we've been using BPT for about 3 years now and it it still maturing. I'd repeat many of the comments that brendan_dick made above. If done the right way, it can be very successful for the life of the AUT. If done the wrong way, you can be left with maintenance issues that you hoped to have avoided by moving to BPT in the first place.
BPT marries the automation and manual testing experience and this has been the best benefit for our company. A big accomplishment has been deriving metrics directly from QC that allow us to track the reuse of components with the aim of those savings being realized in future projects. It's taken a while, but our various QA teams are starting to see the benefits of BPT.
Again, I have the benefit of being in a large corporation that allowed for the process to mature. It really starts with one Technical Testing person (or small team) that has a very firm grasp of Business Process Testing, who can own the process and suite of tools, and who can roll out the necessary training and best practices across QA.
I'm slowly coming around to it...Thanks for all the comments..Gave me the patience to persevere..
I think it is advantageous if you have no alternatives. But a lot of posters already mentioned BPT needs a good design and practices. I feel if you are going down the route of investing in a good design and setup good practices, why not invest in a good scripting framework where you can borrow design and practices from most traditional scripting/programming languages.