Genpact QA Interview Questions (2026)

TL;DR

Prepare for Genpact QA interviews by matching your examples to the posted role, then rehearse test design, defects, APIs, SQL, automation, coding, privacy, and stakeholder decisions. The exact hiring steps and stack vary by opening, so verify them with the recruiter.

Key Takeaways

• Use the posted Genpact role and recruiter instructions to determine the relevant tools, domain, and interview format.
• Answer scenarios with risk, test layers, data, observable evidence, and a release decision.
• Prepare clear examples of API contracts, SQL reconciliation, automation isolation, and defect investigation.
• Explain your own contribution and measured results without inventing metrics or client details.
• Practice coding with runnable edge-case tests and explain assumptions before implementation.
• Treat recalled question lists as practice prompts, not guaranteed interview content.

Genpact QA interview questions usually probe whether you can find important failures, explain your evidence, and help a delivery team make a sound decision. Prepare from the specific job description: a manual QA role may emphasize scenarios and defect communication, while an automation or SDET role may add code, APIs, data, and CI. These are practice questions with model answers, not a list of guaranteed questions or a fixed hiring sequence.

Genpact describes opportunities across data, technology, AI, and digital operations on its careers page. The project, client, location, and seniority can change the interview format and domain. Ask your recruiter what the role actually covers, then replace the sample systems below with honest examples from your own work.

TL;DR

Use the questions as speaking prompts. Give a direct answer first, then one example, one trade-off, and the evidence you would inspect.

1. Genpact QA Interview Questions: Process and Role Fit

Q: What should you expect in a Genpact QA interview?

Expect the format to depend on the opening rather than on a universal round count. A recruiter conversation may establish availability and experience, while technical discussions can examine the actual testing stack, scenarios, or coding described in the posting. Request the assessment format, allowed language, and role level from your recruiter. Prepare to explain your own projects in enough detail to distinguish personal work from team output.

Q: How would you introduce yourself for a QA role?

Lead with the systems you test, your strongest testing method, and a contribution relevant to this vacancy. For example, a payments tester could mention reconciliation checks, API contract coverage, and a release defect caught through ledger comparison. State the result in verifiable terms, such as a shorter investigation time, only if you measured it. End with the part of the Genpact role that fits your next step.

Q: How do you prepare when the job description lists tools you have not used?

Separate required capabilities from product names. If you know Playwright but the role lists Selenium, explain transferable browser concepts such as locators, waits, state isolation, and screenshots, then identify driver lifecycle as a gap to study. Build a small exercise in the requested tool before the interview. Never describe that exercise as production experience.

Q: Why do you want to work at Genpact as a QA engineer?

Connect a real part of your experience to the posted team's domain and delivery problem. Genpact's public careers page spans data, technology, AI, and digital operations, so speak to the specific opening rather than assuming every QA engineer works on the same platform. Explain the kind of quality decision you want to own, such as validating data movement or protecting a transaction journey. Avoid claims about an undisclosed client project.

Q: What should you ask the interviewer about the QA role?

Ask which failures have caused the most customer or operational pain recently. Follow with how the team divides unit, API, UI, exploratory, and data checks, and who owns release risk decisions. If automation is central, ask what currently makes the suite untrustworthy: data, environment, locators, or slow feedback. The answers help you understand the job and let you discuss relevant experience.

2. Genpact QA Interview Questions: Test Design Fundamentals

Q: What is the difference between a test strategy and a test plan?

A strategy explains the risk model, coverage layers, techniques, environments, and quality signals for a product or program. A plan applies those choices to a particular release, with scope, people, schedule, dependencies, and exit evidence. A regulated data migration might keep the same reconciliation strategy across releases but change the plan for each dataset. Clarify local terminology because teams sometimes use the labels interchangeably.

Q: How do you apply boundary value analysis to an amount field?

First ask whether the amount is integer or decimal, what currency precision applies, and whether the allowed limits are inclusive. For an illustrative integer rule of 1 through 100, test 0, 1, 2, 99, 100, and 101, then add missing, malformed, and overflow inputs. Check the stored value and downstream calculation, not just the form message. The exact thresholds must come from the product contract.

Run this standalone Python example with python3 - and paste the block into standard input; it exercises the illustrative integer rule:

import unittest

def valid_amount(value):
    return type(value) is int and 1 <= value <= 100

class AmountTests(unittest.TestCase):
    def test_boundaries(self):
        cases = {0: False, 1: True, 2: True, 99: True, 100: True, 101: False}
        for value, expected in cases.items():
            with self.subTest(value=value):
                self.assertEqual(valid_amount(value), expected)
        self.assertFalse(valid_amount(True))

unittest.main()

Q: When is a decision table better than a list of test cases?

Use a decision table when several conditions combine to change the outcome, such as account status, approval threshold, and reviewer role. Record each condition as a column and the expected decision as the action, then eliminate impossible combinations with product input. This exposes contradictory rules and missing cases before execution. A flat list often hides why a particular combination matters.

Q: How do state transition tests differ from boundary tests?

Boundary tests vary values near a numeric or categorical edge. State transition tests vary the order of events, for example draft -> submitted -> approved, and reject approval before submission. Include repeat events, cancellation after submission, and actions from terminal states. A workflow may accept every individual input yet still allow an invalid transition, so both techniques are useful.

Q: How do you decide what to test first under a deadline?

Rank flows by customer impact, frequency, change size, failure likelihood, and ability to recover. For a payment change, authorization, duplicate charge prevention, and reconciliation outrank cosmetic receipt spacing. Select fast service checks before the smallest necessary browser smoke set, and state what remains untested. Share that residual risk with the person who owns the release decision.

For more practice, use the boundary value analysis examples and manual testing interview questions.

3. Scenario Questions for Customer Workflows

Q: How would you test a login flow with multifactor authentication?

Map password, second factor, recovery, session creation, and logout as separate transitions. Test expired and reused codes, rate limits, lockout recovery, role changes, and redirect safety, while checking that errors do not reveal account existence. Exercise keyboard access and time-sensitive behavior with a controllable clock where the design allows it. Verify server-side session invalidation rather than trusting a hidden UI button.

Q: How would you test a file upload used for document processing?

Confirm accepted types, size limits, encryption, retention, and who may read the result. Try zero-byte files, misleading extensions, corrupt files, duplicate names, interrupted transfers, and scanner or storage outages. Trace the job from upload acknowledgement through processing to a visible terminal state. Ensure another tenant cannot fetch the file or its extracted text.

Q: How would you test a batch data import?

Establish expected row counts, schema, duplicate policy, null handling, and the rollback or partial-success rule. Compare source and destination totals plus control sums for fields where aggregation is meaningful, then inspect a sample of transformed rows. Re-run the same batch to assess idempotency and deliberately inject one bad record. Confirm that the rejection report names the row and reason without exposing sensitive values.

Q: How would you test a notification sent after approval?

Separate approval persistence from message delivery because the two may complete at different times. Check recipient, template variables, locale, channel preference, and duplicate prevention for retries. Simulate provider rejection and delayed delivery, then inspect retry state and dead-letter handling if available. A sent event alone does not prove the recipient received or could read the notification.

Q: What would you test in a multi-tenant reporting dashboard?

Use two tenants with overlapping record identifiers and distinct users to expose cross-tenant leakage. Verify filters, pagination, aggregation, exports, and cached results against an authorized source query. Test empty datasets and late-arriving records so the timestamp on the report has clear meaning. Include direct URL and API access because hiding a control in the UI is not authorization.

4. Defects, Debugging, and Release Decisions

Q: What belongs in a useful defect report?

Include the expected behavior, actual behavior, smallest reproduction path, build, environment, data setup, and frequency. Attach a focused screenshot, trace, or correlation ID that narrows the failure without leaking customer data. Record impact separately from a proposed fix so engineering can investigate without being anchored to a guess. A good report lets another person reproduce or falsify the issue.

Q: How do severity and priority differ?

Severity describes the effect of a failure, such as lost transactions or a minor display fault. Priority is the order of work after exposure, workaround, release timing, and dependencies are considered. A serious issue in a disabled feature may have high severity but lower immediate priority than a medium-impact failure on the main checkout path. QA should provide evidence; the accountable product owner decides scheduling.

Q: A developer cannot reproduce your bug. What do you do?

Compare build hash, feature flags, account role, browser, dataset, time, and network conditions. Reduce the steps and share a trace or request ID that identifies the first divergent response. Pair on one controlled experiment instead of repeating the same instructions. If reproduction remains intermittent, record frequency and observed conditions while investigating the race.

Q: How would you isolate a flaky test?

First determine whether the application, test, environment, or shared data varies. Run the case alone and in parallel, capture timing and network artifacts, and look for order dependence. Replace fixed sleeps with an assertion on a meaningful state, or isolate accounts and records if collisions appear. Keep the original failure visible when a temporary retry is used.

Q: Would you block a release for a known defect?

Present affected users, data integrity impact, probability, workaround, blast radius, and confidence in the evidence. Propose controls such as a limited rollout, flag, monitoring query, or rollback if they actually reduce the risk. Recommend a hold when the potential harm or uncertainty is unacceptable, but identify who has authority to accept the risk. Document the decision and the post-release check.

5. API Testing and Service Contracts

Q: How would you test an order creation API?

Start with one valid request and assert status, response shape, persisted order, and any published event. Add missing fields, wrong types, numeric boundaries, duplicate client keys, invalid identity, and attempts to write another user's account. Distinguish a duplicate request that should return the original result from a conflicting payload that should fail. Check that errors are stable enough for clients to act on.

Q: What is the difference between authentication and authorization testing?

Authentication proves who the caller is; authorization determines what that caller may do. Test missing, expired, and invalid credentials for the first concern. For the second, use valid users with different roles and tenant ownership, then attempt reads and writes on each other's resources. A successful sign-in says nothing about resource isolation.

Q: How do you test idempotency?

Send the same operation twice with the same idempotency key and verify one durable business effect. Then change the payload under that key and check the documented conflict behavior. Repeat through a timeout where the first response is lost, since clients often retry after uncertainty. Inspect the ledger or event count, because identical HTTP responses alone cannot prove duplicate work did not happen.

Q: How would you validate an asynchronous API?

Capture the returned operation ID and poll its documented status endpoint until a deadline. Assert allowed intermediate states and final effects, including failure details, instead of sleeping a fixed number of seconds. Test a dependency outage to see whether the job retries, fails, or waits according to the contract. Record elapsed time as diagnostic evidence without treating one observed duration as a guaranteed SLA.

Q: What should a contract test assert?

Assert required fields, data types, status codes, headers, and compatibility rules that consumers actually rely on. Keep business invariants such as total equals line-item sum in a separate semantic assertion so a schema-only pass does not hide a wrong amount. Include optional fields and null behavior where clients branch on them. Avoid freezing irrelevant response order or volatile timestamps.

Here is a runnable HTTP client contract check with a mocked response. Run it with python3 - and paste the block; it needs no live service:

import json
from email.message import Message
from io import BytesIO
from unittest.mock import patch
from urllib.request import urlopen

class Response(BytesIO):
    status = 200

    def __init__(self, payload):
        super().__init__(json.dumps(payload).encode())
        self.headers = Message()
        self.headers.add_header("Content-Type", "application/json")

def read_order(url):
    with urlopen(url) as response:
        assert response.status == 200
        assert response.headers.get_content_type() == "application/json"
        order = json.load(response)
        assert isinstance(order["id"], str)
        assert isinstance(order["total"], int)
        return order

with patch("__main__.urlopen", return_value=Response({"id": "ord-1", "total": 12})) as request:
    assert read_order("https://example.test/orders/ord-1") == {"id": "ord-1", "total": 12}
    request.assert_called_once_with("https://example.test/orders/ord-1")

Review the API testing interview questions for more contract and negative-case drills.

6. SQL and Data Quality Questions

Q: How do you verify that a migration preserved records?

Compare counts by partition, business key uniqueness, null rates, and selected aggregates before and after the move. Investigate any expected filters or transformations so a matching grand total does not conceal rows moved to the wrong category. Sample records at high-risk boundaries, including oldest dates and unusual encodings. Keep a reconciliation report that identifies unresolved differences and the approved tolerance.

Q: How would you find duplicate business keys in SQL?

Group by the business key and retain groups with a count above one. For an order table, include tenant ID if order numbers are only unique within a tenant. Inspect the duplicates before deleting anything, because a repeated key may represent valid history or a retry defect. Add a database constraint only after the intended uniqueness rule is confirmed.

Run this self-contained SQLite example with python3 - to see the duplicate group:

import sqlite3

con = sqlite3.connect(":memory:")
con.execute("CREATE TABLE orders (tenant TEXT, order_no TEXT, amount INTEGER)")
con.executemany(
    "INSERT INTO orders VALUES (?, ?, ?)",
    [("A", "100", 7), ("A", "100", 7), ("B", "100", 9)],
)
rows = con.execute("""
    SELECT tenant, order_no, COUNT(*) AS copies
    FROM orders
    GROUP BY tenant, order_no
    HAVING COUNT(*) > 1
""").fetchall()
assert rows == [("A", "100", 2)]
print(rows)
con.close()

Q: What is the difference between INNER JOIN and LEFT JOIN in a QA query?

An inner join returns only matching rows; a left join retains every row from the left table and fills missing right-side columns with null. Use a left join to find orders without a payment record after the expected processing window. Filter for the missing right key, not for a nullable business field that could be null in a valid match. Check key cardinality so one-to-many joins do not inflate counts.

Q: How would you test a data transformation with nulls?

Define whether null means unknown, not applicable, or invalid for each source field. Build rows for null, empty string, whitespace, and an ordinary value because ingestion systems may distinguish them. Compare transformed output and reject records against the mapping contract. A blanket COALESCE can hide missing data, so use it only when the business rule explicitly supplies a default.

Q: How do you validate a report total?

Trace the metric from raw records through filters, joins, currency conversion, rounding, and aggregation. Calculate an independent expected total on a small controlled dataset with cases across date and tenant boundaries. Compare both value and included record set; equal sums can result from offsetting omissions and duplicates. Verify the report's refresh timestamp before treating a mismatch as a calculation defect.

Practice the query patterns in SQL interview questions for QA.

7. Browser Automation and Framework Design

Q: How do you choose a browser locator?

Prefer a user-facing role and accessible name when they identify the control reliably. A label works well for form fields, while a documented test ID may be necessary for a repeated element without stable semantics. Avoid positional selectors that break when a list changes. If an accessible control cannot be located by its name, raise the accessibility issue rather than immediately hiding it with a brittle CSS path.

Q: Why do fixed sleeps cause unreliable UI tests?

A fixed sleep waits too long when the application is fast and still fails when it is slower than expected. Wait for a specific condition such as a visible result, completed request, or durable status. Diagnose whether the condition is actually observable, because extending a timeout cannot repair a missing state transition. Keep a firm deadline so a failed test ends with useful evidence.

Q: What would you include in an automation framework explanation?

Describe the runner, application layers, environment configuration, data creation, assertions, logs, and CI reporting. Walk one test from setup to cleanup and show how parallel workers avoid sharing users or records. Explain a failure artifact that helped identify a real defect. Finally, name one trade-off, such as accepting a small browser smoke suite to keep the main feedback loop fast.

Q: How do you make tests safe for parallel execution?

Give each worker isolated credentials and uniquely named test data, or provision a fresh tenant when the environment supports it. Never assume cleanup will always run after a crash; use expirations or a cleanup job for abandoned resources. Make output filenames include a worker or test identifier. Re-run a suspect test both alone and under load to reveal shared-state collisions.

Q: What belongs in CI and what stays exploratory?

Put deterministic, high-value regressions in CI, with fast checks before expensive browser journeys. Preserve artifacts for failures and define an owner for flaky or quarantined tests. Use exploratory sessions for new behavior, unclear requirements, and surprising combinations that scripts do not yet encode. Promote a discovered risk into automation when its repeat value justifies maintenance.

The Playwright role locator guide shows a practical locator choice when that tool is in the posted stack.

8. Coding, Observability, and Nonfunctional Quality

Q: How would you approach a QA coding exercise?

Restate inputs, outputs, constraints, and edge cases before writing code. Implement the simplest readable solution, then demonstrate normal, empty, boundary, and invalid cases. Explain time and space cost only when it affects the task. A correct function with a small test set is more persuasive than an elaborate abstraction with no assertions.

Q: What would you log for a failed transaction test?

Capture a correlation ID, request method and path, sanitized response, environment, and timestamps. Link those artifacts to the test assertion that failed so the next engineer can follow the transaction across services. Redact credentials, personal data, and payment details before attaching logs. Excess output can obscure the first bad state, so choose diagnostic fields deliberately.

Q: How do you test performance without inventing a target?

Ask product and operations for an agreed workload, latency objective, concurrency pattern, and representative data volume. Measure response percentiles, errors, resource saturation, and dependency behavior during a baseline and a changed build. Separate warm-up from measured traffic and control the environment enough to compare runs. Report observations against the agreed threshold rather than declaring a system fast from one local request.

Q: How would you test accessibility in a form?

Navigate using a keyboard and verify focus order, visible focus, labels, error association, and recovery after validation. Inspect the accessibility tree or use a screen reader for critical flows, because an automated scan catches only part of the problem. Test the form at zoom and narrow widths so instructions do not disappear. Report the blocked user task and element, not just a generic rule violation.

Q: How do you test a feature flag rollout?

Cover off, on, and missing-configuration states for the targeted audiences. Verify that a disabled UI does not leave an exposed API path and that stored data remains compatible during rollback. Test flag evaluation at session boundaries if caching can delay a change. Record which cohort and configuration produced each result so a rollout issue can be reproduced.

9. Data Privacy, Domain Risk, and AI-Assisted Features

Q: How would you test access to sensitive customer data?

Create users with distinct roles and tenants, then attempt direct API reads, exports, and search queries across their boundaries. Verify field masking where a role may see a record but not its sensitive attributes. Inspect audit events for access and denial without recording the secrets themselves. Include revoked access and old links because cached or signed resources can outlive UI permissions.

Q: How do you test a financial reconciliation workflow?

Define the authoritative source, matching keys, currency and rounding policy, cutoff time, and acceptable exceptions. Seed settled, pending, reversed, and duplicate transactions, then confirm each lands in the correct reconciliation bucket. Compare counts and amounts at both transaction and aggregate levels. Investigate an unmatched item through source identifiers instead of assuming every difference is a software bug.

Q: How would you test an AI-assisted classification feature?

Build a reviewed dataset with representative labels, ambiguous cases, and slices for different document types or customer groups. Measure agreed quality metrics on a held-out set and inspect costly error classes separately. Test input validation, human override, audit trail, and fallback when the model is unavailable. Avoid claiming deterministic correctness for probabilistic output; the product must define acceptable behavior and monitoring.

Q: What should you verify in a data pipeline after a schema change?

Test old and new producers against consumers during the deployment overlap. Check field defaults, nullability, type conversion, dead-letter records, and downstream reports. Backfill a small controlled set and compare lineage to the source. A pipeline can stay green while silently dropping a new field, so inspect the delivered data as well as job status.

Q: How do you handle test data containing personal information?

Use synthetic or properly de-identified records where possible and keep access proportional to the test purpose. Confirm that screenshots, CI artifacts, exports, and defect reports do not reintroduce sensitive values. Set retention and deletion rules for temporary data. If a production-like dataset is required, follow the organization's approved controls rather than copying raw customer records into a local environment.

10. Collaboration and Behavioral Questions

Q: Tell me about a time you challenged a release decision.

Choose a real incident with a specific risk and evidence you found. Explain the options you presented, such as a fix, limited rollout, or documented acceptance, and identify who decided. Describe what happened after release or delay, including monitoring. Keep the story focused on your judgment and collaboration rather than portraying a colleague as careless.

Q: What do you do when requirements change late in a sprint?

Clarify the changed behavior and which interfaces, data, and tests it affects. Re-rank the highest-risk checks, identify tests that are now obsolete, and show the delivery owner the effort and residual risk. Update the acceptance examples so development and QA share one interpretation. Do not silently claim full regression if the schedule only permits a targeted run.

Q: How do you communicate a defect to a nontechnical stakeholder?

Describe the customer action, observed consequence, affected population, and available workaround in plain language. State what is known and what remains uncertain, then offer the next decision needed. Keep stack traces and request details available for engineers separately. A concise impact statement helps the stakeholder prioritize without having to decode logs.

Q: Describe a mistake you made in testing.

Use a genuine example, such as missing a timezone boundary because sample data covered only one region. Explain how you discovered the gap and what you did for affected users and the team. Show a proportional prevention change, such as a data matrix or review prompt, rather than promising no future mistakes. The interviewer is looking for ownership and learning, not a disguised success story.

Q: How do you help developers prevent defects earlier?

Join refinement with concrete examples of boundaries, failure modes, and observability needs. Ask for unit or component checks on business rules, while reserving end-to-end tests for cross-service journeys. Pair on a reproducible defect to identify the earliest layer that could have caught it. Measure the value by clearer requirements or faster feedback, not by counting QA-owned test cases.

How Interviewers Grade Your Answers

A convincing answer has five parts: a direct response, the context that changes the decision, a concrete method, the evidence you would inspect, and a trade-off. Interviewers may ask follow-ups to see whether you actually used the tools on your resume. If you say you designed a framework, explain one real failure path, ownership model, and maintenance cost. If you cite a metric, be ready to describe how it was measured.

For scenario questions, state assumptions aloud and ask for missing rules before enumerating tests. For behavioral questions, use a real situation, your action, the outcome, and what changed afterward. For coding questions, make the solution run and test edge cases. A candidate who says "I do not know this tool yet, but here is how I would verify the behavior" is more credible than one who invents an API.

Common Mistakes

• Treating recalled Genpact questions as a guaranteed exam script instead of reading the specific vacancy.
• Listing every test type without selecting the ones that reduce the scenario's main risk.
• Confusing a visible UI restriction with server-side authorization.
• Calling a flaky test fixed after adding a sleep or concealing failures with retries.
• Checking API status alone while ignoring durable state and side effects.
• Claiming a performance pass without an agreed workload and target.
• Sharing real customer data in screenshots, logs, or take-home exercises.
• Giving a behavioral answer with only team actions and no personal decision.
• Inventing a fixed interview round count, client project, tool version, or impact metric.

Conclusion

Use these Genpact QA interview questions to rehearse judgment, not memorized definitions. Build one truthful example each for test design, defect investigation, API or data verification, automation, and stakeholder communication. Then map your examples to the posted role and ask the recruiter about the actual interview format.

Practice aloud with a time limit, inspect where your answer lacks evidence, and repeat. You can also use QA interview practice to rehearse concise explanations and compare them with the model answers here.

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)