We primarily use the solution for automation testing.
The test data management is very easy to use. It is a very valuable feature. The client application testing is relatively easy in UFT as well.
The parallel execution of the tests needs improvement. When we are running tests in LeanFT, there are some limitations in terms of running the same tests simultaneously across different browsers. If I'm running a test, let's say to log in, I should be able to execute it through IE, Microsoft Edge, Chrome, Mozilla, etc. This capability doesn't exist in LeanFT. Parallel execution of the test cases across different browsers needs to be added.
The default activation of the services should be reduced to a bare minimum. When you install it out of the box, it enables everything and slows down the system. This needs to be adjusted to improve performance.
The solution should have better integration with the test management tool.
I've been using the solution for four years.
The solution is slightly buggy, but there are certain workarounds. It's a maturing product that's still being developed. That means there are certain bugs we have to deal with. For example, we have to restart the machines where the tests had been running for a sustained period because the solution crashes. This happens occasionally, not every time.
The solution is quite scalable. You can go to thousands of developers because it works on the client-side. UFT itself has limitations, but when you move to UFT Pro, which is now called LeanFT, it is moved to the client-side. Scalability has improved significantly.
We have about 40 developers on the solution currently. We use it extensively as part of continuous testing and we intend to do have 100 people for automation testing. This wasn't possible earlier because it was not at the developer end.
Since LeanFT gets pushed to the developer, it's on the same IDE, and it always has the developers developing the code. Alongside co-development deal, the same developer also develops the test scripts. We are using it extensively and we intend to achieve 100% coverage for automation testing.
Technical support is not good.
It's a new product and the developer community's using it aggressively and it's fitting in well with the dev-ops life cycle as part of continuous testing. The demand is high, the product is new, but the product support team is not able to cope with the dynamic requirements from different customer segments. Support is very slow in addressing issues because of these dynamic requirements.
In our case, eventually, the company arranged for the LeanFT project manager and global project manager to come to our office to spend two days and listen to our concerns and to prioritize addressing those concerns. I think that until the product is matured, the support will take time to stabilize.
No other product has been able to provide continuous testing and to make a developer responsible for automation testing and all the tools needed except the LeanFT. Mainly, there was only one competitor, Selenium, which is open-source. Since it's open-source, it has its own limitations, which is why we did not choose them.
The initial setup was very straightforward.
We implemented the solution on our own.
We use the on-premises deployment model.
I would recommend the solution. I don't think there is any substitute for LeanFT as of now. Some users may be charmed by Selenium because it is open-source, but there is a good part of that community which has gone through the Selenium curve and they know how much time it takes to develop the test scripts with Selenium.
If they were to evaluate LeanFT, they would easily see the difference. One of the important features, which speeds up the automation testing development with LeanFT, is its object repository functions. Object identification is the most time-consuming aspect of building automation tests. LeanFT offers that out of the box. It helps you identify the objects. After that, once you got the object in place, then it's just about building the test scripts. So it reduces your development time significantly.
The most important thing we learned is that it really fits into the continuous testing model. There are many products out there which promise you continuous testing, but it can't be continuous unless it's with the developer. If it's with a developer you can be much more agile, you can be much more continuous, and have faster and shorter delivery times.
Other than LeanFT, we didn't find any other product delivering that. There are many others, like Tricentis, etc. But all of these are independent tools and independent applications. Tricentis themselves said that they're supposed to be used by the quality testers and not the developers. Our approach was to have dev testers on the team, not quality testers.
We have eradicated the QA role in our organization. Developers are testers. That's why we call them dev testers. They develop the code and then test it themselves and they are responsible for that. The accountability increases, the code quality increases and you have better productivity.
I would rate this solution 8.5 out of ten.
Worksoft is so much better