We migrated a number of the tests from OpenText UFT One to SOAtest. The biggest change was moving from validating in the GUI with OpenText UFT One to validating in the database. We are not currently testing the browser extensively because our webpage is not customer-facing but is instead an administrative tool.
OpenText UFT One offered valuable features by allowing us to build up libraries to streamline repetitive tasks, making scripting much easier. However, it required knowledge of the scripting language, VBScript, which is limited compared to Visual Basic. Despite handling web pages effectively, dependency on the browser for validation presented stability issues when Windows would exhaust memory, causing regression testing crashes.
OpenText UFT One required knowledge of VBScript, which is a limited version of Visual Basic. We frequently encountered stability issues when the browser dependency caused Windows to consume memory without releasing it, leading to crashes during regression testing. This experience suggests a need for improvements in handling memory efficiently.
One of the key stability issues was that Windows would consume memory without releasing it, leading to regression testing crashes.
It is not current, but when we dealt with HP, I would rate the support as a six or a seven.
We switched from OpenText UFT One to SOAtest.
Setting up OpenText UFT One was generally straightforward. However, we had to develop some DLLs to perform certain tasks that the system couldn't handle by itself, requiring additional effort. We built various libraries to improve scripting efficiency and speed, which took time and evolved over the course of our use.
I might rate OpenText UFT One around a five or six, based on my past experience, so my rating would be a 5. Name usage should be limited to personal names for publication. I am currently in a low-level manager position and plan to retire in three months, which may affect my access to follow-up communications.