Why are testers abandoning Micro Focus UFT?

Given that Micro Focus’s Unified Functional Tester (UFT) may be the best-known, oldest commercial test automation tool, you’d expect it to have a large market share and customer base. Micro Focus UFT is bundled and integrated with other Micro Focus tools, like their Application Lifecyle Management (ALM) and Quality Center products. Leaving UFT inflicts a switching cost with a subsequent reduction in the value of the other products.

Yet for all those reasons to stay, customers are leaving UFT in record numbers.

What is going on here?

Let’s talk about the things that are pushing people away from UFT, and the tools they can use to replace it. You don’t have to take my word for it. Many of the facts I list below, like the existence of support communities and the quality of the answers, can be verified with a simple Google search. To learn about the skill of the people using the tool, check out random profiles on LinkedIn.

Let’s start with a few ideas, and see where we end up.

Reasons testers are leaving UFT

When HP Enterprise owned UFT, the software company held annual events. After the acquisition, Micro Focus offered no meaningful, official conferences or even first-tier training events for UFT. The results of that are sadly predictable.

No Community. The lack of training opportunities and real world connections left UFT bereft of a vibrant volunteer community. That is, while UFT has people who use the software to test, there aren’t many raving fans or evangelists answering questions on message boards sharing tips and tricks. Tips and tricks are needed, as UFT has its own proprietary scripting language. In other words, there is no code from the internet to reuse. When you go to the internet looking for help, there are a few ‘support’ communities out there, but those forums are filled with more questions than answers.

Lack of Support. If you search Google for UFT training, you’ll find a series of youtube videos, on-line courses, or maybe a class or two. Perhaps. In six months. Thousands of miles away. Try to locate a consultant for a month of on-site work and you will find it near impossible. Try to find support online and you’ll be directed to Help pages that may or may not actually help you. Here’s a challenge: Try actually talking to a support person from the parent company. Offer money if you have to. Then measure the wait time.

Price. At $3,200 per user, per year, UFT isn’t the kind of software that testers are going to buy for themselves, which means they learn the software on the job. And, then when they go onto the next job, they’ll use whatever software they get next. People don’t buy their own copies, which means they aren’t volunteering to code at night, which means they won’t be making open-source extensions. In checking github, I found a couple of libraries from several years ago, which might make sense for a new, upstart tool. However, if you combine the established nature of UFT while noting that the few “nugget” contributions are from the 2015 timeframe, it tells us that the community is less active today then it was then.

Here’s my theory on why that is.

Over Maturity / Harvesting Model. Dr. Michael Porter from Harvard proposed that industries go through phases – cycling from innovation to growth, maturity, and decline. Products often go through that cycle as well. As products reach maturity, they may stagnate and become less profitable. Mature products are not inherently bad. I live in Atlanta, the home of Coca-Cola, which has not changed its formula in a hundred years. (The one time it tried in the 1980’s didn’t go well…) UFT is, in essence, very similar to the WinRunner and Quick Test Pro products that preceded it – built out of a paradigm of testing Windows applications. Windows passed, the web arrived, continuous integration became computer, native mobile has arrived. UFT tests all of these, but uses the same strategies and patterns that it established when Windows95 was the hot new revolutionary operating system.

When companies use the Harvesting Model Dr. Porter proposed in his book Competitive Strategy, they reduce all costs – R&D, support, even marketing – and simply collect as much money as possible until the product is not viable. Given the lack of investment in new features, it is another reason why testers would flee UFT.

It appears to me, as an outside observer that Micofocus is using a harvesting model for UFT. Of course, I encourage you to do you own research.

Switching Costs. Earlier I mentioned the cost, but that amount is only a small fraction of the cost of the integrated suite, which likely includes ALM and Quality Center. One one hand, you may have a vendor lock in, but one that comes with a large total price tag. In addition, teams that switch away from ALM or Quality Center, toward Jira or a different competitor, suddenly lose the bundling discount thereby makings UFT more expensive, while decreasing the value it provides since it will not be deeply integrated with the new tool stack.

Switch off the HP stack, and you might just want to switch all of it.

The second huge switching cost is the loss of the tests. After all, teams will have to “throw away” those UFT tests, written in a proprietary scripting language. Except you might not have to — companies like Tricentis are creating migration tools to reduce the pain from the conversion.

Lack of Test Design / Model Driven Support. There’s more to test planning than creating a document that creates one flow that works and a second or third that fails for some reason. “Happy Path” testing is easy enough to do, and you don’t need a test plan to do it. Most reasonably intelligent people can do that manually. What we find in software is that there are a huge number of combinations and integration points. You select the right tests to run from the infinite combinations possible and create visual representations of them — that is the job.

UFT doesn’t offer infinite combinations. Check for yourself, look for how UFT can help with test design, and you’ll see data-driven tests. That is, you can populate a spreadsheet with different inputs and expected results, and re-run the spreadsheet — but you have to create the spreadsheet yourself.

UFT doesn’t help with test design either. It is simply test execution. Once you’ve struggled through the bugs to get the tool to work and it finally runs… it won’t find anything. At least, not until a new defect is introduced in the same place the test was recorded, and passed, before. That is just automation of regression testing, which is a tiny fraction of the overall test effort.

That might just be why testers are leaving it.

Where are they going?

If you look at the list above, the place to go seems obvious. Tests should go to a tool with a stronger, more technical community, with less switching costs and modest prices that supports model driven testing and test design. I expect they’ll want a newer tool in its growth phase, one that isn’t stuck in the record/playback paradigms of the 1990s. Perhaps one that doesn’t force the user to learn a custom programming language.

But those are just my thoughts.