UST QA Interview Questions (2026)

TL;DR

Prepare for UST QA interviews with role-specific practice in test design, manual QA, browser and API automation, SQL, CI, and stakeholder judgment. These 50 questions are representative prompts, not a fixed UST interview process.

Key Takeaways

• Use the current opening and recruiter instructions to choose topics and confirm the assessment format.
• Build tests from rules, boundaries, states, side effects, and observable results.
• Validate API contracts along with authorization and persisted business state.
• Explain browser reliability through selectors, synchronization, isolated data, and traces.
• Run small coding examples and state their input contracts and edge cases.
• Report release uncertainty with specific coverage, impact, options, and a recommendation.

UST QA interview questions are best practiced as discussions of risk, evidence, and decisions. This guide gives you 50 representative questions with specific answers about test design, manual QA, automation, APIs, SQL, coding, CI, and release judgment. These are preparation prompts, not a claimed list from an actual UST interview.

Start with the current UST posting and recruiter instructions. UST's published quality engineering work includes browser, API, integration, mobile, and performance testing, while a given project may use only some of these. Use the opening to select topics, and attach each answer to a project result you can defend. Sources: UST careers and UST quality engineering case study.

TL;DR

1. UST QA Interview Questions: Role and Preparation

Use the job description as your syllabus. The automation testing interview questions guide provides more general drills after you identify the role's stack.

Q: How would you prepare when the client project is not named?

Extract the technologies, application type, domain, and seniority from the posting. Prepare one real story each for test design, defect investigation, automation maintenance, and a release decision. Ask the recruiter whether coding or a practical exercise is part of the assessment. A UST case study illustrates company capabilities, but it does not establish the format of your own interview.

Q: How do you summarize your QA experience in two minutes?

Name the product type and users, then the failures your team is responsible for preventing. Explain the layers you test and one result with a baseline you can substantiate, such as a measured reduction in smoke-test time. Separate your contribution from work done by the whole team. Close with the experience most relevant to the opening and leave room for follow-up.

Q: What if the posting requests Selenium but your recent work used Playwright?

Explain transferable concepts: locators, state waits, isolated sessions, assertions, and diagnostic artifacts. Then name the Selenium-specific topics you would refresh, including WebDriver sessions, explicit waits, and stale elements. Offer a small practice exercise in the required language. Do not pretend that the tools have identical APIs or that adjacent experience equals production experience.

Q: How can you discuss a confidential former client project?

Replace client names, internal URLs, production data, and architecture secrets with a neutral system description. Keep the technical decision intact: which rule was at risk, what evidence you gathered, and how the outcome changed. Be clear about what you personally owned. If a follow-up would expose protected information, explain the general test method instead of revealing it.

Q: What do you say when asked about an unfamiliar domain?

State the unknown and ask for one business rule or example transaction. Map actors, states, inputs, and irreversible side effects before proposing checks. For an unfamiliar insurance claim, ask who can approve it and when it becomes payable. Reasoning from an explicit contract is stronger than inventing details about a client's system.

2. UST QA Interview Questions: Test Design

Test design starts with expected behavior. Practice explaining why each case exists with manual testing interview questions.

Q: How would you test a transfer amount limited to 1 through 10,000?

Confirm currency precision and whether the endpoints are inclusive. Test just below, at, and just above both bounds in the smallest accepted unit; add negative, missing, and malformed values. Check that rejected requests do not change balances or audit state. If the UI sends decimals while the API stores integer minor units, verify conversion at that boundary.

Q: When would you use equivalence partitioning?

Use it when groups of inputs should follow the same rule. Shipping destinations might partition into supported domestic, supported international, and unsupported regions. Select a representative from each group, then add boundaries for weight, dimensions, or postal-code length where behavior changes. Revisit partitions when eligibility or pricing rules change; a representative is only useful while the rule remains valid.

Q: How would you build a decision table for a discount?

List independent conditions such as membership, coupon validity, cart threshold, and excluded items. For each meaningful combination, state the expected price and rejection reason. Remove impossible combinations only after documenting why they cannot occur. Test precedence if two discounts compete. The table should expose missing business decisions, not merely produce more rows of test data.

Q: How do you test cancellation of a stateful order?

Draw allowed transitions among requested, confirmed, fulfilled, and canceled. Attempt cancellation in each state, then repeat it and race it against fulfillment. Assert the visible status and side effects such as inventory release or refund creation. Identify which transition owns the irreversible effect; otherwise duplicate messages can cause two refunds while the UI still shows one cancellation.

Q: What do you do with an ambiguous acceptance criterion?

Write two examples that would pass under different interpretations. If a promotion ends at midnight, ask which timezone applies and whether checkout start or payment time controls eligibility. Record the decision next to the story, then test both sides of the cutover. Until there is an agreed oracle, report the coverage as unresolved rather than labeling surprising behavior a defect.

Save this executable boundary example as amount_rules.py. Run python3 amount_rules.py; it should print Amount rules passed.

from decimal import Decimal, InvalidOperation

def valid_amount(raw):
    try:
        value = Decimal(raw)
    except (InvalidOperation, TypeError):
        return False
    return value.is_finite() and value == value.quantize(Decimal('0.01')) and Decimal('1.00') <= value <= Decimal('10000.00')

cases = {'0.99': False, '1.00': True, '10000.00': True, '10000.01': False, '2.001': False, 'oops': False}
for raw, expected in cases.items():
    assert valid_amount(raw) is expected, raw
print('Amount rules passed')

3. Manual Testing, Defects, and Exploration

Manual testing is valuable where requirements or dependencies are changing. A requirements traceability matrix can make a coverage claim inspectable.

Q: What makes a defect report actionable?

Include observed and expected behavior, build and environment, minimal reproduction steps, and sanitized test data. Attach a request ID or trace segment that shows the first divergence, not just the last error screen. State frequency and user impact separately from your suspected cause. The report should let a developer reproduce the issue or ask one precise missing question.

Q: How do severity and priority differ?

Severity describes harm; priority describes when the team should act given exposure, timing, and a workaround. A rare data-loss path remains severe even if a feature flag currently contains it. A spelling error on a launch page may be low severity yet urgent before release. Supply evidence for both labels and leave scheduling ownership with the accountable team.

Q: How do you plan an exploratory session?

Set a charter, such as finding ways a returning user can lose an unfinished form. Bound the session and vary navigation, connectivity, session expiry, and duplicate tabs deliberately. Record build, data, observations, and unanswered questions while testing. Convert stable discoveries into regression checks afterward and distinguish confirmed defects from behavior whose expected result is still unclear.

Q: What if a developer says your defect is expected behavior?

Compare the result with the acceptance example, interface contract, and user impact. Ask which rule supports the behavior and involve the product owner if no rule resolves it. If the behavior is accepted, document the decision and update the test. If implementation contradicts the agreed example, provide a smaller reproduction tied to the affected journey.

Q: How do you test in an unstable environment?

Separate product failures from setup failures with health checks, dependency status, and a known-good smoke path. Record timestamps and build identity so another person can investigate. Continue independent tests while marking dependent coverage blocked. Do not call an inconclusive run a pass because one retry happened to work; explain which evidence remains missing.

4. Browser Automation With Selenium or Playwright

Interviewers often probe why an automated result is trustworthy. Use Selenium wait scenarios and Playwright interview questions for deeper tool practice.

Q: How do you choose a stable browser locator?

Prefer a semantic role and accessible name when the control has one, because that reflects a user-visible contract. Use a deliberate test ID if several controls share the same label or the name is dynamic. Scope a locator within a stable region rather than taking the first matching button on the page. Avoid generated classes and DOM position unless structure itself is under test.

Q: Why can an explicit Selenium wait still leave a flaky test?

The wait may observe the wrong state, such as element presence before it can receive a click or spinner disappearance before a save completes. A rerender can also make a previously found reference stale. Wait for the state required by the assertion, then reacquire an element after DOM replacement. Compare timestamps and traces before assuming every intermittent failure is synchronization.

Q: How would you test a save action without a fixed sleep?

Trigger the action and wait for a supported completion signal: response, changed status, or persisted value after reload. Assert the saved content instead of only the absence of a spinner. For asynchronous processing, poll a status endpoint to a justified deadline if the contract supports it. A fixed delay is slow in fast runs and unreliable under load.

Q: Why might a browser test fail only in parallel CI?

Shared accounts, mutable fixtures, rate limits, and cleanup that assumes execution order can cause collisions. Give workers distinct resource identifiers and avoid overwriting one shared cart or profile. Compare the first divergent event with a serial trace. If one external resource cannot be isolated, serialize only tests that use it rather than disabling parallelism for the suite.

Q: How should an end-to-end suite handle authentication?

Use dedicated test identities and create authenticated state through a supported login or setup route. Keep sessions isolated and refresh state when it expires. Test the visible login journey in a small focused set; unrelated scenarios should not all depend on that UI flow. Never commit reusable tokens or cookies as fixtures in the repository.

5. API Contract and Integration Questions

A response code alone rarely proves the business result. The API testing interview questions guide has more contract drills.

Q: What proves that a create API succeeded?

Check the documented status, response fields, and new identifier, then fetch the resource through a supported read endpoint. Verify defaults, ownership, and promised side effects such as an audit event. If creation is asynchronous, inspect final status rather than treating acceptance as completion. Send an invalid request to confirm it leaves no new record.

Q: How do you test idempotency on a POST endpoint?

Send the same payload twice with one idempotency key and inspect the authoritative business effect. The contract should define whether the second response repeats the original result or returns a duplicate status. Reuse the key with a different payload and check the specified conflict behavior. A client retry after timeout must not create a second charge when idempotency is promised.

Q: How do you test authorization between API resources?

Build a matrix of user, role, tenant, action, and resource owner. Call endpoints directly with valid credentials for each role, including a user requesting another tenant's record. Assert denial and no sensitive fields in the response. Test role revocation and token expiry at the point the service contract says access should change.

Q: Which negative API cases matter beyond malformed JSON?

Cover missing fields, wrong types, limits, unknown IDs, unsupported methods, and insufficient credentials. Assert the error contract and absence of unintended state changes. For bulk requests, clarify whether validation is atomic or partial before checking rollback. Exercise rate limiting if clients may retry aggressively; its headers and recovery behavior matter to callers.

Q: How do you verify an event-driven integration?

Capture the event's correlation ID and expected transition, then poll a supported status view to a bounded deadline. Deliver duplicate or delayed events in an environment that permits controlled injection. Assert one effective business side effect and the final state, not merely that the queue emptied. Inspect dead-letter handling when processing cannot succeed.

This in-memory API contract test uses Python's standard WSGI interface and no network service. Save it as api_contract.py; run python3 api_contract.py and expect API contract passed.

import io
import json
from wsgiref.util import setup_testing_defaults

def app(environ, start_response):
    raw = environ['wsgi.input'].read(int(environ['CONTENT_LENGTH']))
    data = json.loads(raw)
    valid = isinstance(data.get('name'), str) and bool(data['name'].strip())
    payload = {'id': 7, 'name': data['name']} if valid else {'error': 'name required'}
    status = '201 Created' if valid else '400 Bad Request'
    start_response(status, [('Content-Type', 'application/json')])
    return [json.dumps(payload).encode()]

def call(payload):
    raw = json.dumps(payload).encode()
    environ = {}
    setup_testing_defaults(environ)
    environ.update({'REQUEST_METHOD': 'POST', 'PATH_INFO': '/items',
                    'CONTENT_LENGTH': str(len(raw)), 'wsgi.input': io.BytesIO(raw)})
    result = {}
    def start_response(status, headers):
        result['status'] = status
        result['headers'] = headers
    response = b''.join(app(environ, start_response))
    return result['status'], json.loads(response)

assert call({'name': 'Ada'}) == ('201 Created', {'id': 7, 'name': 'Ada'})
assert call({'name': ''}) == ('400 Bad Request', {'error': 'name required'})
print('API contract passed')

6. SQL and Data Validation

Database answers should identify the authoritative record and the query's unit of measurement. Practice more with SQL interview questions for QA.

Q: How would you find orders with no matching customer?

Left join orders to customers and filter where the customer key is null. Confirm whether guest orders are permitted before treating every result as a defect. Return order IDs and timestamps to separate migration residue from a current write path. Use a read-only query during investigation and avoid correcting records without an owner-approved plan.

Q: How do you verify a displayed total against database rows?

Identify the source lines, currency, tax policy, rounding stage, and included statuses before summing. Compare the UI with the same order snapshot rather than a changing live table. Choose data with discounts and refunded lines because a single full-price item will not test the rule. Validate the API-to-UI conversion if the browser displays a formatted amount.

Q: Why can a join inflate an order count?

A one-to-many join produces a parent row for every matching child. Counting orders after joining line items therefore counts lines unless you aggregate or use a distinct order key. Define whether the metric is orders, items, or customers before writing the query. A fixture with one order and two lines reveals the error immediately.

Q: How do you test a data migration?

Compare source and target counts by meaningful partition, then validate keys, null rates, and transformed business fields. Reconcile rejected rows against documented rules rather than hiding them in a total. Check referential integrity and rerun behavior so a partial retry does not duplicate records. Make the rollback or correction path explicit before approving cutover.

Q: How do you investigate a race that creates duplicate records?

Capture requests with the same logical key and their commit times, then inspect the uniqueness constraint and transaction boundary. Reproduce with concurrent requests over independent connections. Assert one effective record and the documented response for the losing request. A separate application-side existence check can race, so the invariant often needs database enforcement.

Save this SQLite example as data_checks.py. Run python3 data_checks.py; it should print Data checks passed.

import sqlite3

connection = sqlite3.connect(':memory:')
connection.executescript('''
CREATE TABLE customers (id INTEGER PRIMARY KEY);
CREATE TABLE orders (id INTEGER PRIMARY KEY, customer_id INTEGER);
CREATE TABLE lines (id INTEGER PRIMARY KEY, order_id INTEGER);
INSERT INTO customers VALUES (1);
INSERT INTO orders VALUES (10, 1), (11, 99);
INSERT INTO lines VALUES (100, 10), (101, 10), (102, 11);
''')
orphans = connection.execute('''
SELECT o.id FROM orders AS o
LEFT JOIN customers AS c ON c.id = o.customer_id
WHERE c.id IS NULL
''').fetchall()
assert orphans == [(11,)]
joined = connection.execute('SELECT COUNT(*) FROM orders o JOIN lines l ON l.order_id = o.id').fetchone()[0]
orders = connection.execute('SELECT COUNT(DISTINCT o.id) FROM orders o JOIN lines l ON l.order_id = o.id').fetchone()[0]
assert (joined, orders) == (3, 2)
connection.close()
print('Data checks passed')

7. Coding and Framework Design

For coding prompts, define the input and edge cases before giving complexity. Show where a utility fits in a real suite instead of describing only its syntax.

Q: How would you find the first repeated request ID?

Walk the list once and store previously seen IDs in a set. Return the first value encountered for a second time, so A, B, B, A returns B. An empty list returns no value. State that the input contains hashable IDs; the method uses linear time and space proportional to the number of distinct values.

Q: What belongs in a page object?

Put meaningful page interactions and stable locators behind small methods such as filling a form or reading a result. Keep business assertions visible in the test unless a reusable component has its own explicit contract. Avoid one giant class that hides navigation, setup, and cleanup in a single call. The design should reduce selector duplication without concealing intent.

Q: How do you design fixtures for parallel test runs?

Create data per test or worker with a unique namespace and clear ownership. Keep setup small enough that a failed prerequisite is identifiable, and clean only resources the fixture created. Do not let workers mutate one account balance or feature flag. Reuse immutable reference data if setup is costly, while isolating every write.

Q: When should a test mock a dependency?

Mock when the purpose is the caller's response to a controlled condition, such as timeout or malformed data. Keep separate contract tests against the real service so an inaccurate stub cannot become the sole oracle. Model status, payload, and timing intentionally. A stub that always returns success cannot tell you whether retries or recovery work.

Q: How do you review AI-generated test code?

Check imported APIs against the installed library and run the test in a clean environment. Confirm that setup creates the state the assertion claims to verify. Inspect failure paths for weak selectors, swallowed errors, and missing cleanup. Remove secrets and personal data from prompts and fixtures. Generated cases remain suggestions until someone validates the business rule and oracle.

Save this duplicate-ID exercise as duplicates.py. Run python3 duplicates.py; it should print Duplicate checks passed.

def first_duplicate(values):
    seen = set()
    for value in values:
        if value in seen:
            return value
        seen.add(value)
    return None

assert first_duplicate(['A', 'B', 'B', 'A']) == 'B'
assert first_duplicate(['A', 'B', 'A']) == 'A'
assert first_duplicate([]) is None
print('Duplicate checks passed')

8. CI, Reliability, and Release Decisions

A framework is valuable when its results improve decisions. Explain the gate's feedback time and what happens when evidence is missing.

Q: Which checks belong on every pull request?

Choose fast, deterministic checks for changed rules, service contracts, and critical integration paths. Keep expensive browser matrices and long performance runs separate unless their risk warrants blocking every change. Measure execution time and fault detection before expanding the gate. A red check must identify an actionable failure, or the team will learn to ignore it.

Q: How do you investigate a flaky test?

Compare passing and failing runs at the first divergent event, including timestamps, resource IDs, requests, and artifacts. Classify the cause as synchronization, shared state, dependency instability, or a product race. Reproduce the mechanism with a targeted run before changing assertions. A temporary retry should remain visible while the root cause is fixed.

Q: What should a failed CI job retain?

Keep the failing assertion, test and build identity, environment, relevant logs, and trace or correlation ID. Sanitize credentials and personal data before publishing artifacts. Link them from the job summary and define retention so investigators know whether evidence will still exist tomorrow. A final screenshot alone cannot explain an earlier API failure.

Q: How would you speed up a slow regression suite?

Profile queue time, setup, and test execution separately. Move repeated business-rule permutations to lower layers, remove redundant end-to-end paths, and parallelize after isolating data. Keep a short route through each high-impact journey. Compare feedback latency and escaped defects afterward so a faster suite does not conceal lost coverage.

Q: What do you tell a release manager when testing is incomplete?

List passed, failed, blocked, and untested journeys with customer impact. Explain why evidence is missing and offer options such as targeted smoke testing, limited rollout, or delay. Recommend one path with residual risk and a named decision owner. A single green status would hide uncertainty that the release manager needs to see.

9. Domain, Security, and Nonfunctional Scenarios

UST's published quality work covers several sectors and test layers. Let the role description determine which scenarios deserve the most practice.

Q: How would you test a payment retry after a timeout?

Capture the original idempotency key and determine whether the server committed before the client lost its response. Retry with the same logical identifier and inspect the authoritative ledger for one effect. Check a conflicting payload under the same key against the contract. A success toast is weaker evidence than settled transaction state and reconciliation.

Q: How do you test role-based access?

Create an allow-and-deny matrix for role, action, resource ownership, and tenant. Exercise the API directly because hiding a menu item does not block a crafted request. Check that denials reveal no protected fields and role changes take effect at the documented point. Include audit events for privileged actions if the product requires them.

Q: What would you measure in a performance test?

Define a business transaction, expected load shape, representative data, and service objective before running traffic. Measure latency percentiles, error rate, throughput, and resource saturation as load rises. Record environment and downstream constraints for reproducibility. Report the load where the objective breaks and the likely bottleneck, not just average response time.

Q: How would you test an accessible form?

Complete the journey with a keyboard, checking order, focus visibility, labels, and error recovery. Confirm that errors are associated with fields and announced by supported assistive technology. Automated checks can catch some missing names and contrast failures, but cannot prove the whole task is usable. File defects with the exact control and navigation sequence.

Q: How do you test a mobile app with intermittent connectivity?

Move between online, offline, and restored states during a write. Inspect queued actions and eventual server state, while checking that the UI distinguishes unsent data from confirmed saves. Repeat with backgrounding and duplicate taps because reconnect logic may replay work. First clarify whether the product should retry, reject, or ask the user.

10. Behavioral and Stakeholder Questions

Use a brief story with context, your action, evidence, and result. Rehearse aloud in the interview practice tool.

Q: Tell me about a defect you missed.

Describe the escaped behavior and customer impact without shifting blame. Identify the assumption, data gap, or missing contract that allowed it through. Explain containment and a lasting change such as a regression check at the right layer. State how you verified the improvement rather than claiming that no similar issue can occur again.

Q: How do you resolve disagreement with a developer?

Bring the smallest reproduction and user-facing rule to the discussion. Ask which assumption differs, then involve the product owner if expected behavior is genuinely undecided. Record the agreed example and update the test or implementation. Keep the conversation on observable outcomes rather than who owns the defect label.

Q: How do you prioritize tests under a deadline?

Rank journeys by impact, exposure, recent change, and reversibility. Test the most expensive failure modes first, including a negative path where an irreversible effect can occur. Tell stakeholders exactly which coverage is deferred and what might escape. After release, use incidents and usage evidence to revise priorities for the next cycle.

Q: How would you mentor a junior tester?

Give them a real feature and request a risk map before supplying a template. Review one case for oracle quality, data setup, and diagnostic value, then pair on the hardest boundary. Let them own a bounded improvement and present its evidence. Growth appears in independent reasoning and clearer defects, not just a larger test count.

Q: Why do you want this UST QA role?

Connect a specific requirement in the current opening to work you have done and a skill you want to deepen. Explain a quality problem you enjoy solving, such as integration failures that break a customer journey. Ground any claim about UST in published material or a recruiter discussion. A concrete contribution is more credible than generic praise.

How Interviewers Grade Your Answers

A strong answer identifies the rule or risk, chooses a test layer, states the oracle, and explains how evidence changes a decision. Follow-ups may probe retries, concurrent requests, missing data, and dependency failures. Behavioral questions also test whether the outcome was yours to claim. Use bug severity and priority examples if your stories blur harm with urgency.

This is a preparation rubric, not a claim about UST's internal scoring. Answer a definition directly before expanding. For a scenario, clarify assumptions and show a few high-value checks instead of listing every testing type. Keep your resume nearby during practice so every example survives a follow-up.

Common Mistakes

• Treating a candidate's interview report as a guaranteed current process.
• Naming tools from a posting without explaining a test you ran with them.
• Listing cases before defining expected behavior.
• Calling an accepted API response proof of a completed transaction.
• Hiding flaky tests behind unlimited retries or arbitrary sleeps.
• Querying joined tables without checking what is being counted.
• Reporting green when a critical path was blocked.
• Sharing former client data to make an example sound specific.
• Repeating one memorized answer for different scenarios.

Conclusion

Prepare UST QA interview questions by connecting each answer to a business rule, failure mode, observable result, and decision. Match practice to the current opening, run the code exercises, and rehearse project stories with follow-up questions. Compare your resume with the role in the resume analysis dashboard.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• 500+ QA and Manual Testing Interview Questions and Answers (2026)
• Accenture QA Engineer Interview Questions and Process (2026)
• Accessibility Automation Interview Questions for Senior QA (2026)
• Adobe QA Engineer Interview Questions and Process (2026)
• Adyen QA and SDET Interview Questions (2026)
• Agile and Scrum Interview Questions for QA Engineers (2026)