We build helper utilities. For example, your particular test is one where when you do the test, you have 30 minutes of setup, but then at the end, you need a real human eye because it is brand new stuff and you don't know what to do. However, if you could have an automation build that 30 minutes worth of stuff and not be worried about it over and over again, thinking about it as your test prerequisite, then we have an awful lot of stuff for that.
The real good stuff is that we have full-blown replacements for manual tasks, whether it would be for desktop applications or hybrid web applications. There are a lot of apps out there, especially in the enterprise space where it is in a web browser, but there is an installer on your computer and the web browser is the view. We have PureWeb, our websites, and others, and we do a lot of mobile testing with UFT One. We do almost all our API testing with it for our web services. We also do a good amount of data testing with it as well.
The use case is really just to add testing efficiencies in any way, shape, or form that we can through a helper for some prerequisites, since we do a lot of data builders with it. In fact, that is a project that I am working on today, building test data where an actual person doesn't have to sit there and build test data because that is boring and unproductive. We have scripts to do full-blown test case replacements. So, any one of our projects or applications can have anywhere between 20 percent and mid-sixties percent automation coverage for the application of automated replacement of manual tests.
It is a development IDE. When you're working with a development IDE, you need to proof it through a bunch of different techniques that you use to make sure that there is no recompiling you need to do. So, we are in the process of getting version 15.0.2, but we are using version 15 across the entire team.
It is all on-premises. So, UFT can encompass a couple of things. There is UFT One, which is like any automation software that you would use. Technically, the most prevalent that people see the marketplace is Sauce Labs working with Eclipse, or something like that. Think of this as is Eclipse (or your favorite IDE) and the automation software all bundled into one. It is only applicable for on a desktop computer of some sorts, whether it is a laptop, desktop, or virtual machine. We use it all on-premises.
Cloud is a little bit iffy for some of the things that we do, being in the healthcare space. We do use some cloud stuff, but for this particular one, I would imagine we use on-prem as long as we can. Now, it is mostly all virtual machines. We have almost no physical desktops left with it because gone are the days of trying to figure out a problem. Because you have templates to base it off of, it's like, "Listen, just rebuild my machine. I'll use it tomorrow." We are using it on Windows 10 virtual machines.
Our virtual machines are constantly running. It is not like we turn them down and stand them up. If I discuss the side that a block of them are bad for whatever reason, we can destroy them and get new ones built, but they are all pretty standard. I am actually sitting on one right now, which is a dual-core, two and a half gigahertz machine with 8 GB memory. This represents your slightly above average laptop that you would buy at a store. One of the reasons that we shifted to all virtual machines is when you are doing normal office work, you have to open your chat windows, Outlook, browsers for different things, and maybe Word or Excel. All that is just stuff that muddles up the water for your development environment, regardless of what development you are doing. By using VMs, even for scripting, we have our ID and the application you are testing open on that machine, and nothing else. So, that machine gets to just do automation stuff and nothing else. It's not interrupted by Outlook things. If you have 15 Chrome browser tabs open where you are researching something, then the hog of some of those sites aren't impacting you. You just have the application that you are testing and the IDE open. We have had really good success with this. The perfect mix for this is what we have: dual-core 8 GB memory. That is really good enough. We even have that for the machines with an AI engine on them. At this point, the AI engine is local. So, all the stuff that it does to look at the screen, interpret things, read it, tell you where menus are, etc., those are all running on that machine. I haven't really seen a blip on it. We tried to run it with four 4 GB memory once, and it was so-so. Let's face it - Windows 10 on 4 GB of memory isn't good anyway.