OpenText Functional Testing for Developers Reviews

LeanFT is used a lot more by our less experienced testers and developers who want to get more point-and-click type automation. Then obviously I also manage the automation team, so we use UFT for a ton of all of our XLC automation as well as anything with a UI. So we also bring it into our business functions as well. If we need to do clean-up, data entry, management of manual tasks where you're putting yourself in a UI scenario, we'll run scripts for that for productivity.

We pretty much use that to streamline workflow and enable productivity in a business context in our business unit as well as in our IT shop, so just reducing workload on IT people as well as testing. It's used pretty extensively beyond that.

I'd like to not have to use Selenium. I'd like to be able to do headless scripting and not just always be UI serving.

It's stable.

We're already at enterprise scale, so it's used across the enterprise. I would say that we're at that point.

I have an entire team, so I'm a director and I have an entire tools team that does that. I did get involved in the planning and the strategy of how we're going to do it. My team said that first installation is relatively easy. When we go to upgrade and migrate, that's where there's pain.

We're still trying to get the adoption on that for the user community. It's very usable though. I rate adoption pretty high, so when people are using it, for instance, UFT, I'd definitely give that a ten because we use that a lot. I'd like to see some enhancements in the product, and we're working with HPE on that.

Have a well-defined process, have a strong reporting structure, meaning in your process you want a lot of measurability. If you define your output, the reports and the questions you need to answer from what you're doing, which your process should be managing for you. In our company, we are very specific about what our executives and stakeholders want.

We have a very well-defined set of measurements that we have to take. We then put a process designed to ensure those measurements are always taken. That then allows you to deal with your outputs and your reporting structure, which then allows you to properly architect your tooling. The technology is very flexible. You have to decide as a client area how you really want to use it and that's going to start with what your business needs are the values that you're trying to get out of it.

That's the biggest advice that I have, it's not even on the technology. The technology will do great things for you if you have a plan and a structure and you know what you want it to do for you. Half the time they don't know, they want the tool to do it for them and it's the other way around. So that's what I advise people to do.

Think about it, have a vision, have a plan, tie that to outcomes, and measure those outcomes. If you're answering the right questions and asking the right questions, your technology will really enable you. You've got to look at it from that standpoint.

LeanFT's been very good. It's a little more complex than standard testing products like the standard UFT. It's a little more developer oriented. I'm not really a developer per say, but I was able to pick it up fairly quickly.

I think the biggest issues that I've seen, and this is a personal view of mine, is that most of the HPE products have a common look and feel to them. I'd really like to see it be a little more customizable to a use and user standpoint. For example. I happen to be colors blind, so I'd like to see more vivid colors on the UI, and things like that. It would make it a little more flexible from the customer standpoint.

I was formally an HP employee, so I've used the HP products in the past. I also was a former Mercury Interactive employee who was acquired by HP.

It's been extremely scalable as far as the testing that we've done with our customers. They've all been really satisfied with the scalability of the HPE products.

We've gone through the standard customer support and it’s been good. It's not quite to the level that an R&D would be, because they really get really under the covers to fix things.

Since it was a slightly different way of doing things, it was a little complex. It was just the idea of ... this is something new that we have to understand. It wasn't like we're building on a product that already existed, it was right out of the box. It's fairly new, so it was a little more complex that way but R&D made it very easy.

Integration with other IDs. It being in the IDs that the developers are using is big. Another big thing is my staff is mostly automators and they are very technical folks. Most of them have development backgrounds, so they are much more comfortable and familiar in IDs like Eclipse or Visual Studio then they are in UFT, which is where we are coming from.

With my staff, it's retention. Keeping them happy, things like that. That's important. Happy folks are more productive, but also as we spin up agile delivery teams having that integration where the developers are more or less the kings, we can sell that, and say "Hey, use this product." It's already sitting there in Eclipse, sitting there in Visual Studio, so that's pretty big.

To the business, I would say overall it increases the amount of testing that gets done, with more people interacting with automating. Obviously, automation is what we need to do to get more testing done in a shorter amount of time. With more people doing the automation, we are able to get more tests automated, more tests done, so overall we are turning over a more quality product.

Number one thing is we are an Oracle shop, so we do Oracle ERP testing, and that add-in from UFT, that technology is not in LeanFT right now. So all of those automations continue to be run in and maintained in UFT. In order to transition those we would need that support, so that is probably the number thing.

Additionally, just more of the UFT functionality that they have now brought in. We're BPT users as well, so they brought in some BPT functionality, but limited. So we can't have a UFT and a LeanFT component existing in the same BPT for example. That is a limitation to us. It's a step in the right direction that we can do some of it now, but we're not there.

Light users - it's only been out for a year, and we haven't been using it all of the year, but if you were to compare day to day usage with UFT, I would say it's probably less so. It seems to be a little more stable than UFT. We consistently see UFT crashes and things like that, and it's kind of just our cost of doing business. We're used to it, so when I go back to that staff satisfaction, that's a key factor there as well.

We're limited in our use right now, probably less than 10 people.

I've not had to use HPE tech support for LeanFT.

There is a lot of Selenium usage and that still occurs. A lot of our agile delivery teams are tools in a toolbox, so, they put up the guardrails on the road and say, "Pick where you want to go, as long as you don't go outside of there, you are good."

It's actually fairly straightforward. For us, it's a simple download, pointed at our concurrent license server and we are good to go. I would characterize it as easy. Like I said, it's simple as long as you already have the ID you want to integrate with.

Being frank, the number one reason is it works off our existing UFT licenses. So we already have those procured and existing, so that's an easy transition for us from a cost perspective.

Make sure your staff has the technical skill set to be able to properly use it. I guess I didn't mention that in limitations, but it is a fairly more technical tool than UFT. The UFT, I would say for a non-developer, non-technical person, UFT is easier to grasp and use than LeanFT. So you just have to make sure that skill set is there, and the background is there on your team.

I like the direction that it's heading, and as I said, I'm a servant of my team and they're very excited about the product and excited to see the direction it is heading as well.

What’s awesome about it is you can use the same language the developers already use.

LeanFT integrates with our developers work-flow. Our developers can now perform automation using familiar tools, programming language, and IDE. This helps get the whole team involved in test automation.

In the next release I'd like to see HP enable LeanFT to work with Sauce Labs. I know HP has their own solution, but it would be better if it were more integrate-able in the spirit of being more open-source, more friendly.

We haven’t been using it that long, but it has been stable for the last month we’ve been using it. It works as advertised thus far.

Very positive: seems like it’s a lightweight solution that's not going to impact what we were already doing as it's just a "wrapper" on top of what we already do.

Haven’t had any technical support yet, but the demo team was great.

We had used a lot of different applications and we needed to shift left to new development practices. So we ended up using Selenium without native Java. Unfortunately, before LeanFT, we ran into issues where Selenium couldn’t handle the functionality of all the applications.

It's very straightforward-- you just import a library like you would any other tool and go.

Smartbear.

To me, it has to be using the same tools that the developers already use and that it fits in with their workflow. Testers should be using the same tools as the developers, making the development process easier.

The fact that it is so easy to go between UFT with its large install base and LeanFT. Whoever has used UFT will quite easily become productive with LeanFT, but with the added benefit of “shifting left”, to move testing closer to the development cycle.

As the releases come, support for all technologies in the systems under test that UFT currently support will be the obvious place for improvement.

I have not been using LeanFT in a professional capacity yet. I have participated in the LeanFT beta testing program and in that capacity I used the product for three months.

Deployment, as far as it was completed during the beta test, went smooth and without complications. I have not yet tested the installation alongside UFT, as it is shipped with UFT 12.5.

As I tested the product during the beta test period, the product was obviously not completed, but that never affected stability. Any issues with functionality that I had was quickly and resolutely resolved.

In my professional career as Test Automation Developer, I have mainly used UFT. While I will not switch to LeanFT completely, as the products are complementing rather than replacing each other, I will use LeanFT whenever projects dictate that test automation be done during the development process.

Setup simply installs the product as an add-in to Visual Studio or Eclipse. No other setup is necessary. It cannot be easier.

The product is new, but builds on a solution that has a long history. Comparable products do not, in my opinion, have as large a coverage of target technologies as LeanFT has.

Go for it, but do not expect that it will replace all other Test Automation products. This is a complement.

The most valuable features are the ability to customize, if needed, and to integrate with ALM because its our test management. The ability to implement with Jenkins for dev ops is also a valuable feature.

In our case, because we’re in the insurance industry, we have technologies from 20 years old to brand new. That’s one reason that LeanFT is so great -- because it can support all those technologies, even the older ones.

In the next release, I'd like to see ties into C# and Java, enabling us to work more closely with development. However, from what I’ve seen, LeanFT object recognition looks great. The identifiers for an object can be the same for multiple objects, and test automation can detect that. But LeanFT object identification center allows you to see that the identifiers are not necessarily unique, which is very beneficial.

The issues were variable. If you’re using the tools capabilities and the actual traditional test automation you put into a script, it can be unreliable. We try to use descriptive programming, but it becomes more of a test driver rather than creating automation for its test capabilities.

It depends on how you design your solution. If you design a good framework then you can design a scalable solution.

Technical support was not very good. We do reach out, but often they're unable to help. Customer support was similar.

We are a subsidiary, so decision making was limited. Most recently they decided ALM would be the enterprise standard. For automation they decided to use UFT.

Fairly straightforward because it integrates well with ALM. One issue is that if you're using compass, which has its own Java versions etc., it can conflict with LeanFT.

My most important criteria when selecting a vendor is compatibility with my systems, applications, platforms, and whatever apps I am using.

Automate where you can and also try to shift your testing to the left. Testing management is key.

The solution helps to accelerate software testing automation. It will help to reduce lead time and increase productivity and efficiency. 

The tool could be a little bit easier. 

I would rate the tool's stability an eight out of ten.

I would rate UFT Developer's scalability an eight out of ten. 

Support is very good. 

Positive

The tool's setup is deep and it took me almost two to three months to complete. You need to have great knowledge of software transformation. I would rate the installation a ten out of ten. 

I would rate the solution a ten out of ten.