82 UFT interview questions with answers

What they are assessing

Basic orientation and current naming.

Model answer

UFT One is a commercial functional test automation tool, originally QuickTest Professional from Mercury, then HP, then Micro Focus, and now part of OpenText. It automates graphical user interface testing using VBScript, with add-in based support for a wide range of technologies. Its distinguishing strength is breadth: alongside web it covers SAP, Oracle, Siebel, mainframe terminal emulators, Java, .NET and desktop applications, which is why it persists in large enterprises where open source tooling does not reach.

Likely follow-up

Why do enterprises still use it when Selenium and Playwright are free?

What they are assessing

Honest tool positioning.

Model answer

When the technology is not covered by the alternatives, which is the main case: SAP GUI, Oracle Forms, mainframe emulation and some thick client applications have no practical Selenium equivalent. When the organisation already has the licences, the skills and a large existing asset base, since migration cost is real. And when ALM integration for traceability is a requirement. I would not choose it for a new web-only project, where Playwright or Selenium are stronger, better supported and have a far larger talent pool.

Trap to avoid

Claiming UFT is better than modern open source tools for web testing. It is a defensible choice for enterprise technology coverage and not for a greenfield web product, and saying otherwise suggests limited exposure.

What they are assessing

Tool structure.

Model answer

The test itself with its actions. The object repository, local or shared, holding the test objects. The data table for parameterisation, with global and action sheets. Function libraries holding reusable VBScript. Recovery scenarios for unexpected events. Environment variables for configuration. The results viewer for run output. And the add-in manager, which determines which technologies are recognised in a session.

What they are assessing

Awareness of the modern companion product.

Model answer

UFT Developer, previously LeanFT, is the shift-left oriented product: a set of SDKs used inside a standard IDE with Java, C sharp, JavaScript or Python, integrating with JUnit, TestNG and the usual build tools, with tests stored as code in version control. It targets developers and technical testers rather than the UFT One model of a dedicated tool with its own repository and interface. The two share the underlying object identification technology, so the recognition capabilities transfer. UFT Developer suits teams wanting automation in the delivery pipeline; UFT One suits the traditional model and the widest technology coverage.

What they are assessing

A setup detail that blocks beginners.

Model answer

Technology-specific modules that let UFT recognise objects in a given environment, loaded through the Add-in Manager when UFT starts. Web, ActiveX and Visual Basic are typically included; others such as Java, .NET, SAP, Oracle and Terminal Emulator are licensed separately. They matter because without the correct add-in loaded, UFT does not recognise application objects at all and falls back to generic Window and WinObject classes, which produces a script that appears to record and does not work. Loading unnecessary add-ins slows startup and can cause conflicts, so loading only what is needed is the practice.

Likely follow-up

What is the symptom of running with the wrong add-in loaded?

What they are assessing

A core concept in the UFT model.

Model answer

A test object is UFT internal representation, stored in the object repository with the properties it will use to identify the real object. A run-time object is the actual object in the application during execution. UFT matches the test object description against run-time objects to find the right one. The distinction matters because the properties available differ: GetTOProperty reads from the stored description and GetROProperty reads from the live object, and those can legitimately differ, which is itself a useful diagnostic.

What they are assessing

Routine tooling.

Model answer

Inspecting an object in the application to see its properties, their values, and the methods available on it. It is the first tool to reach for when an object is not recognised, when you need to know which properties are stable enough to identify it, or when writing descriptive programming and needing the exact property names. It shows both the test object hierarchy and the native properties, and the native view is often where you find a stable identifier that UFT default description did not use.

What they are assessing

Dynamic object handling.

Model answer

A method that returns a collection of objects matching a description within a parent, so you can work with objects that are not in the repository and whose number is not known in advance. The pattern is to create a description, call ChildObjects on the parent, then iterate the returned collection. It is how you handle a dynamic list of links, a table of varying rows, or a set of checkboxes whose count depends on data. It is also useful diagnostically, to enumerate what UFT can actually see on a page when identification is failing.

Likely follow-up

How would you use it to find a row in a results table by its content?

What they are assessing

A defining UFT concept.

Model answer

A store of test objects with their identification properties, which the script references by logical name. It separates the object description from the script, so when the application changes, the description is updated in one place rather than in every step. It is the equivalent of a page object layer in a code-based framework, provided as tooling rather than as something you build.

What they are assessing

The structural decision in a UFT project.

Model answer

A local repository belongs to a single action and is stored inside the test, so objects are not reusable across tests. A shared repository is a separate file, with a tsr extension, that many tests and actions can associate with, so an object is defined once for the whole suite. Local is the default and is fine for a small throwaway test. Shared is essential for any maintainable suite, because the entire value of the repository model is that an application change is a single edit, which local repositories cannot give you.

Trap to avoid

Building a suite on local repositories. It works initially and means the same object is redefined in dozens of tests, so a single interface change becomes dozens of edits.

What they are assessing

Practical maintenance.

Model answer

Through the Object Repository Manager, which opens shared repositories independently of a test and provides a merge tool for combining two, with conflict resolution where objects clash. The manager is also where repositories are edited while in use, since a repository opened through a test is read-only if associated. On a large suite I would structure repositories per application area rather than having one enormous file, since a single repository shared by everything becomes slow to load and contentious when several people need to edit it.

What they are assessing

A real weakness of the tool.

Model answer

With difficulty, because repository files are binary rather than text, so they cannot be meaningfully diffed or merged by a version control system and concurrent edits produce conflicts that must be resolved through the Object Repository Manager rather than by the tool. The practical mitigations are splitting repositories by area so fewer people touch the same file, coordinating edits explicitly, and using ALM where its versioning handles these assets. It is one of the genuine disadvantages against code-based frameworks where everything is text.

Likely follow-up

How does descriptive programming change this picture?

What they are assessing

The identification mechanism, asked in nearly every UFT interview.

Model answer

By comparing the stored description against objects in the application, in stages. First the mandatory properties, which UFT always records for that class. If that is not unique it adds assistive properties one at a time until it is. If still not unique it uses the ordinal identifier, which is index, location or creation time depending on configuration. If identification fails at run time and Smart Identification is enabled for that class, it falls back to that mechanism.

What they are assessing

A specific identification mechanism with a caveat.

Model answer

A positional identifier used when properties alone are not unique: index, which is the order among matching objects; location, which is position on screen; and creation time, which applies to browsers and is the order in which they were opened. It is a last resort, because all three are inherently fragile: adding an element earlier on the page shifts every index, and a layout change breaks location. An object relying on an ordinal identifier is a maintenance liability and worth replacing with a better property if one exists.

What they are assessing

A feature with a genuine trade-off.

Model answer

A fallback mechanism that activates when normal identification fails: UFT uses a base filter of properties to find candidates, then applies optional filter properties to narrow to one, and if exactly one remains it proceeds. It is configured per object class. The argument for it is resilience, since minor application changes do not break the script. The argument against is that it can silently identify the wrong object and continue, producing a test that passes against something other than what was intended, and it masks genuine application changes that should have been noticed. I would generally disable it on a mature suite and investigate failures properly.

Trap to avoid

Treating Smart Identification as a straightforward improvement. It converts a visible failure into a possible silent misidentification, which is worse in a regression suite.

What they are assessing

The core maintenance problem.

Model answer

By identifying on what is stable rather than what was recorded. A regular expression in the property value handles a predictable variation such as an identifier containing a session number. A different property entirely is often better, since the recorded set may include something volatile. Descriptive programming lets the description be built at run time from a value the test knows. And where nothing is stable, ChildObjects with a filter and then matching on content is the fallback. Asking developers for a stable attribute is also legitimate and frequently overlooked.

Likely follow-up

How do you use a regular expression in an object property?

What they are assessing

A precise distinction.

Model answer

GetTOProperty returns a value from the stored test object description. GetROProperty returns a value from the live run-time object, so it reflects the actual application state and has a wider set of available properties. SetTOProperty changes a property in the test object description for the current run only, without altering the repository, which is how you adjust a description dynamically. The common use of GetROProperty is verification, since reading the live value and asserting on it is usually better than a checkpoint.

What they are assessing

Language awareness including the honest part.

Model answer

VBScript, which is simple to learn and adequate for test logic. Its limitations are real: it is not object oriented in any meaningful sense, it has no native exception handling beyond On Error Resume Next and the Err object, it has limited data structures with no built-in collections beyond arrays and Dictionary, and it is a language with essentially no future outside this context, so skills do not transfer. For a suite with complex logic those constraints are felt, and they are part of the argument for UFT Developer where a real language is available.

What they are assessing

Error handling, which is unusual in this language.

Model answer

With On Error Resume Next, which suppresses the error and continues, then checking the Err object number immediately afterwards and handling it. On Error Goto 0 restores normal error behaviour. The hazard is that On Error Resume Next left on suppresses every subsequent error, so a script continues past failures silently and produces a misleading pass. The discipline is to enable it around the specific statement that may fail, check immediately, and turn it off again, rather than setting it at the top of a library.

Trap to avoid

Putting On Error Resume Next at the top of a function library. Every subsequent failure is swallowed and the test reports success regardless of what happened.

What they are assessing

Basic language mechanics people get wrong.

Model answer

Dim declares a variable. Set is required when assigning an object reference, and omitting it on an object assignment produces an error. An ordinary assignment is used for values. The confusion arises because VBScript is loosely typed, so the distinction between a value and an object reference is not visible in the declaration, and forgetting Set when storing a returned object is one of the most common errors a new UFT scripter makes.

What they are assessing

The only useful collection available.

Model answer

A key and value collection from the Scripting runtime, created with CreateObject, providing the associative array VBScript otherwise lacks. It is useful for test data held in memory, for configuration read once and looked up by name, and for accumulating results during a run. Given the poverty of native data structures in VBScript, knowing it exists is a meaningful capability difference: suites that do not use it tend to pass data through long parameter lists or global variables instead.

What they are assessing

The alternative to the repository.

Model answer

Describing an object directly in the script using its properties rather than referencing a repository entry. There are two forms: static, where property and value pairs are written inline in the object call, and dynamic, where a Description object is created, properties are set on it, and it is passed to the object call. It is used when the repository is impractical: objects generated dynamically, large numbers of similar objects, or descriptions that must be built from data at run time.

Likely follow-up

What is the advantage of the Description object form over inline properties?

What they are assessing

A design judgement with arguments both ways.

Model answer

When objects are genuinely dynamic and cannot be stored meaningfully, when the same pattern applies to many objects so a parameterised description is more maintainable than hundreds of repository entries, and when the team wants everything in text files for version control, which is a real advantage given that repositories are binary. Against that, descriptions scattered through scripts are harder to maintain than a repository when an application changes, which is the problem the repository exists to solve. The pragmatic answer is a shared repository for stable objects and descriptive programming for the dynamic ones, with descriptions centralised in a library rather than inline.

What they are assessing

Practical discipline.

Model answer

By centralising the descriptions rather than writing them inline at every call site, which reproduces the problem the repository solved. A function library holding description builders, so a script asks for the submit button of a given form rather than constructing the description itself, keeps the knowledge in one place. Constants for property names and values rather than string literals repeated across files. And a consistent convention, since the main cost of descriptive programming in practice is that every person writes descriptions differently.

What they are assessing

Breadth of the verification features.

Model answer

Standard, verifying object properties. Text and Text Area, verifying text in an application or a region. Bitmap, comparing images. Database, verifying query results. XML, verifying structure and content. Accessibility, checking against defined guidelines. Page, checking load time and links. Image, Table and a few technology-specific ones. Each is inserted through the interface and stored as a step with its expected values.

What they are assessing

A genuine debate in UFT practice.

Model answer

Programmatic verification for most things, using GetROProperty and an explicit comparison with a reported result. The reasons are maintainability and visibility: a checkpoint stores its expected value inside the test where it is hard to see, review or parameterise, whereas a comparison in code is readable, diffable and can be driven from data. Checkpoints are convenient for a quick test and are genuinely useful for the cases that are hard to code, such as bitmap comparison. On a suite intended to live for years, a wall of checkpoints is harder to maintain than equivalent code.

Trap to avoid

Building a large suite entirely from recorded checkpoints. The expected values are invisible in review and changing them means opening every test.

What they are assessing

A related feature.

Model answer

A step that captures a value from the application during the run and stores it, usually into the data table, so it can be used later in the test or in a subsequent action. It is the counterpart to a checkpoint: a checkpoint compares, an output value captures. It is how you carry a generated reference number from a creation step into a verification step, though the same thing is usually cleaner done programmatically with GetROProperty into a variable.

What they are assessing

Reporting from script.

Model answer

With Reporter.ReportEvent, passing a status of micPass, micFail, micDone or micWarning, a step name and a detail message. It is how programmatic verification produces visible results, and it is what makes a code-based approach viable, since without it a failed comparison would only appear as a script error. Good practice is a wrapper function that performs the comparison and reports in one call, so verification across the suite is consistent and the message format is uniform.

What they are assessing

The modularity unit in UFT.

Model answer

An action is a modular unit within a test, with its own data sheet and optionally its own local repository. Reusable actions can be called from other tests. Non-reusable actions exist only within their test. External actions are reusable actions called from another test, inserted either as a call to the existing action, which references it so changes propagate, or as a copy, which duplicates it and breaks the link. Choosing call rather than copy is what makes modularity worth having.

Likely follow-up

What is the difference between calling an action and inserting a copy?

What they are assessing

Action parameterisation.

Model answer

Through action parameters, declared as input and output on the action and supplied at the call site, which is the explicit mechanism and the one that keeps actions self-contained. Alternatively through the global data sheet, which every action can read, or through environment variables for configuration. Action parameters are preferable where the data genuinely belongs to that call, because global sheet usage creates hidden coupling where an action only works if something earlier populated a value.

What they are assessing

A structural decision that divides UFT practitioners.

Model answer

Function libraries for the logic, with actions kept thin or avoided for reuse. The reasons are that libraries are plain text so they version and diff properly, they support real functions with parameters and return values, and they can be organised into a coherent structure. Actions carry the repository and data sheet with them, which is convenient initially and becomes coupling, and calls to external actions across many tests produce a dependency graph that is hard to reason about. Most mature UFT frameworks I have seen use a small number of driver scripts and put everything else in libraries.

What they are assessing

Data table structure.

Model answer

The global sheet is shared across the whole test, and iterating it runs the entire test once per row. An action sheet, also called a local sheet, belongs to one action, and iterating it repeats only that action per row. So global iteration drives whole-test data-driven runs and local iteration drives repetition within a step, such as entering several line items. Confusing the two produces either a test that runs once when it should run per row, or an action repeating when the whole test should.

Likely follow-up

Where do you configure how many iterations run?

What they are assessing

Practical data handling.

Model answer

Through the DataTable object, addressing a parameter by name and optionally by sheet, with dtGlobalSheet and dtLocalSheet as the sheet references. Values can be read and assigned. DataTable.Import and Export move data to and from an external file, and ImportSheet and ExportSheet handle individual sheets. The important detail is that writes during a run affect the run-time copy rather than the design-time file, so results written back are lost unless explicitly exported.

What they are assessing

A design preference with reasons.

Model answer

External for anything substantial, typically Excel or a database read through a library function, with the data table used only where its iteration mechanism is genuinely convenient. The reasons are that the data table is embedded in the test so it does not version well, it is awkward for non-testers to maintain, and it couples the data to the test. An external source lets the data be managed separately, shared across tests, and generated or refreshed independently. The data table remains the simplest way to drive iteration, which is why it persists.

What they are assessing

The flakiness question.

Model answer

With the specific waiting mechanisms rather than a fixed Wait. WaitProperty polls until an object property reaches a value or a timeout expires, which is the general-purpose answer. Exist with a timeout checks for an object appearing. Sync waits for a browser to complete loading, for web applications. Beyond those, the object synchronisation timeout in test settings governs how long UFT waits for an object before failing. Wait with a fixed number of seconds is the thing to avoid, since it is both unreliable and slow.

Trap to avoid

Using Wait to fix timing problems. It is the most common thing in inherited UFT suites and the reason they take hours to run.

What they are assessing

A subtlety about defaults.

Model answer

The object synchronisation timeout, set in test settings, is how long UFT waits for an object to appear before a step fails, so steps already have an implicit wait. Exist called with no argument uses that same timeout, while Exist with a number uses that instead, and Exist with zero returns immediately. That matters because a common pattern of checking Exist in a loop is often slower than intended, since each call waits the full timeout when the object is absent. Passing zero in such a loop is usually what was meant.

What they are assessing

Diagnosing a timing failure properly.

Model answer

Identify what the script is actually racing with rather than inserting a wait. Usually it is an object not yet present or not yet enabled, which WaitProperty on the relevant property addresses directly. Sometimes it is an application still processing a previous action, where waiting for an observable consequence such as a status indicator is the right condition. Where a page is still loading, Sync. The thing I would avoid is a fixed Wait, which fixes the symptom at the cost of making every run slower and still failing under load.

Likely follow-up

What condition would you wait for before clicking a button that is briefly disabled?

What they are assessing

The reuse mechanism.

Model answer

A text file, with a qfl or vbs extension, containing VBScript functions and subroutines, associated with a test through its settings or loaded at run time with ExecuteFile or LoadFunctionLibrary. Associated libraries are available to every action in the test. It is the main mechanism for shared code, and because the files are plain text they version and diff properly, which is why framework logic belongs there rather than in actions.

What they are assessing

Configuration handling.

Model answer

Named values available throughout a test. Built-in ones supply information such as the test name, the operating system and the current iteration. User-defined ones come in two forms: internal, defined within the test and editable at run time, and external, loaded from an XML file and read-only during execution. External environment variables are the standard way to hold environment-specific configuration such as URLs and credentials references, since the same test then runs anywhere by pointing at a different file.

Likely follow-up

Why would you use an external XML file rather than internal variables?

What they are assessing

Security practice.

Model answer

Not in the test, the repository or a committed configuration file. The practical approaches are reading them at run time from a secured location the test has access to, or from an encrypted value, since UFT provides a password encoder whose output can be used with SetSecure. The encoder is obfuscation rather than strong encryption, so for anything sensitive a proper secret store accessed through a library function is better. The failure to avoid is credentials typed into a recorded step, where they are stored in the test and visible to anyone who opens it.

What they are assessing

A distinctive UFT feature.

Model answer

A configured response to an unexpected event during a run, so the test can continue rather than failing outright. It has a trigger, a recovery operation and a post-recovery action. Triggers are a pop-up window appearing, an object reaching a particular state, a test run error, or an application crash. Operations can be a keyboard or mouse action, a function call, closing a process, or restarting the application. Post-recovery determines what happens next: repeat the step, proceed to the next step or action, restart the test, or stop.

What they are assessing

Judgement about a feature that can hide defects.

Model answer

Legitimately for genuinely unpredictable environmental interruptions: a session timeout dialogue, an unrelated system notification, or an application crash in an unattended overnight run where continuing is better than losing the whole run. It is a mistake when used to handle a predictable application behaviour, because then the test is routing around something that should either be scripted explicitly or raised as a defect. A suite with several recovery scenarios firing regularly is usually concealing instability rather than tolerating it.

Trap to avoid

Using recovery scenarios to make an unreliable suite pass. The runs go green while the underlying instability is never diagnosed.

What they are assessing

A practical detail people overlook.

Model answer

They are evaluated according to the configured trigger timing, and with pop-up triggers set to check on every step, UFT performs that check continuously, which measurably slows execution across a long suite. The mitigation is to activate recovery scenarios only where needed rather than globally, and to set the trigger timing to the least frequent option that still works. On a suite that has accumulated several scenarios over the years, disabling the ones no longer relevant is often a noticeable speed improvement.

What they are assessing

Standard vocabulary.

Model answer

Linear, which is recorded script with no structure and suits only throwaway work. Modular, where functionality is broken into reusable components. Data-driven, where the same script runs with external data. Keyword-driven, where tests are defined as sequences of keywords in a spreadsheet and a driver interprets them. Hybrid, which combines data and keyword approaches and is what most real frameworks are. Business Process Testing is the commercial component-based approach integrated with ALM.

Likely follow-up

What is the appeal and the cost of keyword-driven frameworks?

What they are assessing

Design rather than feature knowledge.

Model answer

In layers. Driver scripts that read the test definition and sequence calls. A business function layer, in libraries, with functions in domain terms such as creating an order. A page or screen layer wrapping the interactions for an area. A utilities layer for data access, logging, reporting and configuration. A shared object repository per application area, or centralised descriptions where descriptive programming is used. Test data external. The property to aim for is that an interface change touches one layer, and that a test reads as business steps rather than as clicks.

What they are assessing

Knowledge of the ALM-integrated approach.

Model answer

A component-based methodology where tests are assembled in ALM from reusable business components, each of which can be automated in UFT or kept manual. The appeal is that subject matter experts can compose tests from components without scripting, and that components are maintained once. The cost is the licensing and the ALM dependency, plus a structure that is heavier than most teams need. It is found in large enterprises that have committed to the ALM toolchain, and rarely chosen fresh today.

What they are assessing

Enterprise toolchain integration.

Model answer

By connecting UFT to the ALM server and storing tests, repositories and libraries in the ALM test plan rather than on the file system, so versioning and access control are handled centrally. Tests are then organised into test sets in the test lab and executed from there, with results written back automatically and linked to requirements and defects. That traceability is the main reason organisations use the combination, particularly in regulated sectors where the link from requirement to test to result is a compliance requirement rather than a convenience.

Likely follow-up

What does ALM give you that a CI server does not?

What they are assessing

Modern integration, which UFT handles less naturally.

Model answer

Through the command line or the automation object model, or through the Jenkins plugin that OpenText provides, which can trigger tests directly or run an ALM test set. The practical constraints are real: UFT requires an interactive Windows session because it drives the actual interface, so it cannot run on a headless agent, which means dedicated execution machines kept logged in with screen lock disabled. Licence availability also has to be managed, since a concurrent licence model limits parallel execution. These constraints are a genuine disadvantage against code-based tools in a modern pipeline.

What they are assessing

The most common UFT problem.

Model answer

Check the add-in first, since the wrong add-in produces generic recognition and is the most frequent cause. Then use Object Spy to see what UFT can actually see and which properties are available. Then compare the live properties against the stored description to find what changed. Then check whether the object is inside a frame or a different window that the hierarchy does not account for. If the object is genuinely not recognised by any add-in, the fallbacks are Insight image-based recognition, a virtual object, or low-level recording, all of which are last resorts.

What they are assessing

A fallback mechanism with significant caveats.

Model answer

A definition that tells UFT to treat an area of the screen as an object of a given class, defined by its position relative to a parent. It is used when an application renders a control in a way no add-in recognises, such as a custom drawn element. The caveats are substantial: it depends on screen position and resolution, so it breaks on layout changes, and it does not work with all recording modes. It is a last resort when the alternative is not automating that area at all.

What they are assessing

The modern image-based option.

Model answer

Insight identifies objects by image recognition, matching a stored picture of the control against the screen, rather than by position as a virtual object does. It is more robust than a virtual object because it follows the control when the layout moves, and it works where no technology add-in applies, including remote sessions and applications UFT cannot otherwise reach. Its weaknesses are the usual ones for image matching: it is sensitive to resolution, theme and rendering differences, and it is slower. It is a legitimate tool for a genuinely unrecognisable interface and a poor default.

What they are assessing

Recording modes.

Model answer

Normal recording captures operations on recognised objects, producing a script in terms of those objects. Low-level recording captures coordinate-based mouse and keyboard actions on the screen, used when objects are not recognised. Analog recording captures exact mouse movement and is used for things like signature capture. Both low-level and analog produce scripts that are tightly coupled to screen position and resolution, so they are fragile and should be confined to the smallest possible portion of a test.

What they are assessing

Environment differences.

Model answer

Screen resolution and display scaling first, since UFT interacts with a real interface and layout differences affect visibility and any position-dependent steps. Then the add-ins loaded, since a different machine configuration recognises objects differently. Then browser or application versions. Then whether the session is genuinely interactive, since a locked screen or a disconnected remote session breaks execution. Then file paths, if anything references a local location. Then licences, since an unavailable concurrent licence produces a failure that looks like something else entirely.

Likely follow-up

Why does a locked screen break a UFT run?

What they are assessing

Debugging tooling.

Model answer

With breakpoints and stepping, which UFT supports with step into, over and out. The Watch and Local Variables panes show values, and the Command window lets you execute statements against the live application state, which is the most useful feature since you can try an object expression and see whether it resolves. Beyond that, Reporter messages at key points for unattended runs, and the results viewer which shows the step that failed with a screenshot. Checking an object expression in the Command window resolves most identification problems in a minute.

What they are assessing

A specific maintenance technique.

Model answer

Replacing a fixed property value in the repository with a parameter, so the description is resolved at run time from the data table, an environment variable or a test parameter. It is how one repository entry handles an object whose identifying property varies by environment or by data, such as a link whose text differs by locale. It is a cleaner solution than duplicating objects, and it is often overlooked in favour of descriptive programming when the repository would have handled the case.

What they are assessing

A common and awkward verification.

Model answer

Programmatically rather than with a table checkpoint, in most cases. Reading the row and column counts with GetROProperty, then iterating cells with GetCellData or the technology equivalent and comparing against expected values from the data source. That gives control over which columns matter, tolerance for row ordering, and a failure message that identifies the specific cell. A table checkpoint captures a snapshot that is hard to maintain and reports a difference without clearly saying where. For finding a specific row, iterating to match on a key column is more robust than assuming a position.

What they are assessing

A routine requirement.

Model answer

Through the Excel automation object created with CreateObject, opening the workbook, reading or writing cells and then closing and releasing the objects. The critical discipline is cleanup: failing to quit the application and set the objects to Nothing leaves Excel processes running, and over a long suite the machine accumulates dozens of them until something fails. Wrapping the access in library functions that guarantee cleanup, including on error, is the practical answer rather than scattering the code through tests.

Trap to avoid

Leaving Excel objects unreleased. Orphaned processes accumulate and cause failures that appear unrelated to the test that created them.

What they are assessing

Configuration design.

Model answer

With external environment variable files per environment, selected at run time, holding URLs, database connections and references to where credentials come from. The test code reads these through the Environment object and contains no environment-specific values. The repository should also be environment-neutral, which means parameterising any property that differs, such as a title containing an environment name. The test of whether it is right is that the same test assets run against any environment with only the configuration file changing.

What they are assessing

A common web scenario.

Model answer

By identifying the new browser explicitly rather than assuming UFT will follow it. The creation time ordinal identifier distinguishes browsers by the order they were opened, which is the standard approach, and descriptive programming with creation time is often clearer than repository entries. Before interacting, waiting for the new browser to exist and to finish loading with Sync avoids a race. For a window that should be closed afterwards, closing it explicitly matters, since an accumulation of browser windows across a long suite affects both identification and memory.

What they are assessing

An execution setting with a real effect.

Model answer

Normal mode displays each step in the editor as it executes, highlighting the current line, which is useful for observation and debugging. Fast mode does not, and runs noticeably quicker as a result. Fast is the correct setting for unattended execution and for any long suite, and the difference over hundreds of tests is substantial. It is a simple setting that is frequently left on normal, which is one of the easier performance improvements available on an inherited suite.

What they are assessing

A failure mode specific to this tool.

Model answer

Several ways. On Error Resume Next left active, so failures are suppressed. A checkpoint that was disabled or whose expected value was updated to match the current behaviour. Smart Identification matching a different object that happened to satisfy the step. A recovery scenario routing around the failure. Or a script that performs actions and makes no verification at all, which recorded scripts frequently do. The habit that catches all of these is deliberately breaking the application behaviour and confirming the test fails, before trusting that it passes.

What they are assessing

A decision many organisations are facing.

Model answer

Not as a direct port, since the structures differ and translating step by step produces code that fights the new tool. First I would establish whether it is viable at all, because if the suite covers SAP GUI or a mainframe emulator, the open source alternatives do not reach those and the migration stops there. For the web portion, I would rebuild rather than convert, reusing the test cases and the domain knowledge rather than the scripts, and run both in parallel while coverage transfers. I would also expect the business logic in the libraries to be the valuable part worth preserving conceptually, rather than the recorded steps.

Likely follow-up

What would make you recommend staying on UFT?

What they are assessing

A routine maintenance technique.

Model answer

By marking the property value as a regular expression in the repository, or by including the pattern directly in a descriptive programming description where regular expressions are supported by default for property values. It handles values with a predictable variable portion, such as a title containing a date or an identifier containing a session number. The caution is making the pattern too loose, since a description that matches several objects then relies on the ordinal identifier to choose, which reintroduces the fragility you were trying to remove.

What they are assessing

Diagnostic design.

Model answer

Through a single logging function in a library that every other function calls, writing to the UFT results with Reporter.ReportEvent and optionally to an external file for runs where the results viewer is not convenient. Centralising it means the format is consistent, the detail level can be changed in one place, and failures carry the context needed to diagnose them without rerunning. For unattended runs I would also capture a screenshot on failure, which UFT does for some step types automatically and which is worth doing explicitly for programmatic verifications.

What they are assessing

A distinction that shapes framework design.

Model answer

An action is a UFT construct carrying its own data sheet and optionally its own repository, callable from tests, and visible in the test structure. A function is plain VBScript in a library, taking parameters and returning a value, with no UFT-specific baggage. Functions are better for logic because they are text, they version properly, they compose, and they do not drag a data sheet along. Actions are better where you genuinely want the iteration mechanism or the modular structure visible in the test. Most well-built frameworks use few actions and many functions.

What they are assessing

Performance improvement on an inherited suite.

Model answer

Fixed Wait statements first, which in an inherited suite usually account for a large share of the runtime and are pure dead time. Then run mode, since normal rather than fast costs noticeably. Then recovery scenario trigger frequency, since pop-up checks on every step are expensive. Then unnecessary add-ins loaded, which slows startup and identification. Then Exist calls in loops using the default timeout. Then the structural question of whether the suite drives the interface for setup that could be done through an API or a database, which is usually the largest available saving.

What they are assessing

Cross-layer verification.

Model answer

With an ADO connection created in VBScript, executing a query and reading the recordset, rather than with a database checkpoint. The reasons are the same as for other checkpoints: a coded query is visible, parameterisable and maintainable, while a checkpoint stores the query and expected result inside the test. Wrapping the connection handling in a library function matters, both for consistency and because connection cleanup is easy to get wrong and leaves open sessions. The connection details belong in environment configuration rather than in the test.

What they are assessing

Scope beyond the interface.

Model answer

Yes, through the API testing component, which provides a visual activity-based model for building service tests covering REST, SOAP, JMS and several other protocols, with data-driving and validation. It can be combined with GUI tests in the same solution, which is its main advantage: a single test can set up state through an API and verify through the interface. For teams already invested in UFT it is a reasonable option, though for API testing alone a code-based library in a mainstream language is usually more maintainable and far easier to run in a pipeline.

What they are assessing

Maintenance at scale.

Model answer

By splitting it by application area rather than having one file for everything, since a single large repository is slow to load and becomes a contention point when several people need to edit. By a naming convention, so objects are findable and duplicates are visible. By periodic review to remove objects for features that no longer exist, since repositories only grow otherwise. And by preferring stable properties over ordinal identifiers at the point objects are added, because an object added with an index-based description is a future failure that nobody will attribute correctly.

What they are assessing

Long-term design thinking.

Model answer

Logic in function libraries so it is text, versionable and composable. A shared repository split sensibly, or centralised descriptions, so an interface change is one edit. Tests reading as business steps rather than clicks, with the mechanics pushed down. No fixed waits. Data external to the tests. Environment configuration external. And verification written programmatically so expected values are visible in review. The suites that die are flat recorded scripts with local repositories, where a redesign breaks everything at once and nobody can tell which failures are real.

What they are assessing

Library organisation.

Model answer

Libraries associated with a test are all loaded into the same scope, so a function in one is directly callable from another without any import, which is convenient and means naming collisions are a real hazard. ExecuteFile and LoadFunctionLibrary load a library at run time, which is used when the set of libraries depends on configuration. Because everything shares a namespace, a prefix convention on function names is worth adopting early, since two libraries defining the same function name produce behaviour that depends on load order.

What they are assessing

An alternative approach.

Model answer

By checking for it at the points where it plausibly occurs and dismissing it, wrapped in a library function so the check is one call. That is more explicit than a recovery scenario, since the handling is visible in the script and does not carry the continuous evaluation cost. The trade-off is that it only covers the places you anticipated, whereas a recovery scenario covers everywhere. For a genuinely unpredictable event, the recovery scenario is the right mechanism; for one that occurs at known points, an explicit check is clearer and faster.

What they are assessing

An operational limit that affects planning.

Model answer

By planning around it, since concurrent licences cap how many machines can execute simultaneously and that is a hard limit on parallelism. The practical responses are managing a pool of execution machines matched to the licence count, scheduling long suites overnight when contention is lower, and reducing what needs to run through the interface at all by moving verification to API or database level. It is a genuine structural disadvantage against open source tooling where parallelism is limited only by infrastructure, and it is worth stating plainly in a tooling discussion.

What they are assessing

Basic data-driving.

Model answer

By putting the data in the global sheet and setting the test to run on all rows, or a specified range, in the run settings. Each iteration runs the whole test with the next row. For repeating only part of a test, the data goes in that action local sheet and the action iteration is configured in its call properties. Getting these two confused is the usual reason a data-driven test runs once or repeats the wrong portion.

What they are assessing

Honest career judgement, which a candidate should have.

Model answer

Declining but not disappearing. New projects rarely choose it for web, where open source tooling is better and the talent pool is far larger, and OpenText direction has shifted toward UFT Developer and the cloud offerings. What sustains it is the installed base in large enterprises with SAP, Oracle and mainframe estates that the alternatives do not reach, and those systems change slowly. So it remains a viable specialism in that context and a poor sole skill, which is why anyone building a career on it should also be competent in a mainstream language and a modern tool.

Trap to avoid

Claiming UFT is as relevant as ever. Interviewers in organisations that use it are usually aware of its position and a candid answer reads better than advocacy.

What they are assessing

A common modern web problem.

Model answer

By not identifying on the generated id at all. The alternatives are a regular expression matching the stable portion if there is one, a different property such as name, text or a custom attribute, a relative approach using ChildObjects filtered on a parent that is stable, or innerhtml and innertext matching for web elements. The best answer, where the application is ours, is asking developers to add a stable test attribute, which UFT can use through the attribute property. That conversation is worth having early, because the alternative is permanent maintenance cost.

What they are assessing

Image comparison with its caveats.

Model answer

A comparison of a captured image against a stored baseline, optionally with a tolerance. It is appropriate for things that genuinely cannot be verified any other way: a rendered chart, a signature capture, or a graphical element with no readable properties. It is inappropriate as a general verification because it is sensitive to resolution, theme, font rendering and anti-aliasing, so it produces failures on machines that differ in ways nobody considered. Where it is used, it needs a defined execution environment or the baseline is meaningless.

What they are assessing

A constraint affecting reliability.

Model answer

Through the fastest reliable path rather than the interface, which usually means database inserts or API calls from a library function, so a test spends its time on the behaviour being verified rather than on setup. Each test creating its own data keeps it independent and resilient to a shared environment. Unique values generated rather than hardcoded so parallel or repeated runs do not collide. And cleanup, with the caveat that a suite killed mid-run does not clean up, so a periodic purge or a namespacing convention is a necessary backstop.

What they are assessing

Recovering a failed investment.

Model answer

Establish what actually runs and what has ever found a defect, since a minority usually carries all the value and a large proportion will be broken or disabled. Then decide deliberately rather than attempting to repair everything: the high-value scripts are rebuilt properly against a library-based framework, the rest are retired. That is uncomfortable and is nearly always the right call, because repairing eight hundred recorded scripts costs more than rebuilding the eighty that matter. In parallel, fix the structural causes, which are usually local repositories, fixed waits and no reusable layer.

Likely follow-up

How would you justify retiring most of an existing suite to a sceptical stakeholder?

What they are assessing

A subtle source of failures.

Model answer

By formatting explicitly rather than relying on defaults, since VBScript date and number conversion follows the machine regional settings, so a date produced on one execution machine can differ from another. CDate and CStr behaviour varies accordingly. The practical approach is formatting dates to an explicit pattern with the format functions rather than converting implicitly, and comparing parsed values rather than strings. It is a classic cause of a suite that works on one machine and fails on another with no apparent cause.

What they are assessing

Operational reliability.

Model answer

By removing the things that need a person. That means no reliance on an existing application state, since each test starts from a known point and cleans up after itself. Recovery scenarios for the genuinely unpredictable interruptions. Explicit waits on conditions rather than fixed sleeps, so a slow night does not cascade. Logging detailed enough to diagnose a failure without rerunning, including screenshots. A dedicated machine with a stable configuration, kept logged in with screen lock disabled. And a check that the run actually started, since the most common overnight failure is nothing executing at all.

What they are assessing

A closing question revealing depth of experience.

Model answer

Treating recording as the method. Someone records a script, it works once, and the suite grows that way until there are hundreds of flat scripts with local repositories, fixed waits and expected values buried in checkpoints. Every application change breaks dozens of them, nobody can tell which failures are real, and the suite is eventually abandoned. The tool genuinely supports a good framework with shared repositories, function libraries and programmatic verification, and the projects that fail are the ones that never moved past the recorder, which is as much a process failure as a technical one.