Persistent Systems QA Interview Questions (2026)

TL;DR

Prepare for Persistent Systems QA interviews by practicing test design, API and database validation, UI automation, coding, CI debugging, and project communication. The exact round sequence and stack depend on the role, so use the posted job description and recruiter instructions as your guide.

Key Takeaways

• Use the current job description and recruiter instructions to choose the language, tools, and likely assessment areas.
• Prepare examples that connect a concrete product risk to a test, an oracle, and release evidence.
• Practice API authorization, idempotency, pagination, SQL reconciliation, and data isolation.
• Show UI automation through stable locators, observable waits, and assertions on business outcomes.
• Explain framework design with CI execution, secrets, parallel data ownership, and failure artifacts.
• Bring truthful project stories with a baseline, your contribution, a tradeoff, and a defensible result.

Persistent Systems QA interview questions are best prepared as exercises in test design, automation, API and data validation, debugging, and clear delivery judgment. This guide gives you 50 practice questions with model answers and runnable examples, while separating verified company context from interview topics that vary by role.

Persistent describes its software product engineering work in terms of microservices, API-led connectivity, automation, and modernization. A Senior SDET posting calls out web and API automation, Selenium, CI, test data, stability, and collaboration. That posting describes one role, not a universal interview syllabus. Read your own job description and recruiter instructions before choosing a language or tool for practice.

TL;DR

These are representative prompts, not a list of questions used by Persistent. For a broader drill set, use manual testing interview questions, API testing interview questions, and SQL interview questions for QA.

1. Persistent Systems QA Interview Questions About the Role

Q: What do you know about Persistent Systems, and why does its QA work interest you?

Persistent describes product engineering, modernization, cloud, and API-led delivery among its services. I would connect that work to a specific quality problem I have solved, such as protecting an API contract during migration or reducing unreliable release feedback. I would then tie my example to the exact team and stack in the posting. I would avoid claiming knowledge of an internal project I have not seen.

Q: How would you prepare if the interview format is not specified?

I would ask the recruiter about the role level, preferred coding language, assessment format, and whether the position is manual QA, automation QA, or SDET. Meanwhile, I would prepare an evidence map covering test design, API, SQL, UI automation, coding, CI, and a project story. This keeps preparation useful if stages are combined or reordered. I would treat third-party interview reports as anecdotes rather than a schedule.

Q: What changes between a QA analyst and an SDET answer?

For a QA analyst, I would emphasize requirements analysis, exploratory work, defect evidence, and risk communication. For an SDET, I would also show code quality, test architecture, service boundaries, CI execution, and maintainability. Both roles need strong test reasoning, and the posted responsibilities determine the balance. Calling every automated script an SDET framework would overstate the engineering involved.

Q: How would you introduce yourself in ninety seconds?

I would name my current product area and the kind of risk I own, then give one outcome with a defensible baseline. Next I would explain the technical approach I personally contributed, such as API contract checks or reliable data setup. I would close by linking that experience to the advertised role. The answer should invite follow-up rather than recite every line of my resume.

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

I would ask which failures have escaped recently and where feedback arrives too late. I would ask who owns test data, how service and UI coverage are divided, and what the first project needs from this hire. Those questions reveal whether the immediate job is framework construction, exploratory testing, release support, or modernization. I would listen for the team's constraints before offering a solution.

2. Manual Testing and Test Design

Q: How would you test a login page?

I would first define supported identities, authentication methods, lockout rules, session duration, and recovery flows. Then I would cover valid access, wrong credentials, blank and malformed inputs, expired sessions, navigation, and accessibility of errors. I would test authorization after login through a protected endpoint, since a hidden button is not a security boundary. I would avoid using real customer accounts in shared test environments.

Q: What is the difference between severity and priority?

Severity describes the product or customer impact of a defect; priority describes when the team should address it. A rare data-loss defect can be severe even if exposure is limited, while a minor issue on a launch-critical page may receive urgent priority. I would give reproduction steps, affected users, frequency, and workaround so the labels are evidence-based. Product and engineering owners can then make a time-sensitive decision.

Q: How do you turn an ambiguous requirement into test cases?

I would write down the user action, preconditions, expected result, and open decisions before enumerating cases. For example, "upload a file" leaves size, type, duplicate, malware, partial transfer, and retry behavior undefined. I would ask the product owner for examples at each disputed boundary and turn agreed examples into acceptance criteria. The resulting tests should verify behavior rather than my private interpretation.

Q: Explain boundary value analysis with a concrete example.

If an upload accepts files up to 10 MB, I would test just below, exactly at, and just above the limit using the system's stated unit and measurement method. I would also check zero-byte files and whether client and server reject the same inputs. The important oracle is not merely an error toast: it is that no disallowed object is stored. I would document whether the limit applies before or after encoding.

Q: How do you test a stateful order workflow?

I would draw the allowed states, such as draft, submitted, paid, fulfilled, canceled, and refunded, plus each legal transition. Tests would exercise valid paths, forbidden jumps, repeated commands, and failures between state updates and external calls. I would verify the order record, payment effect, customer notification, and audit trail through supported interfaces. State coverage is more informative than counting UI screens.

3. API Testing and Service Contracts

Q: What do you verify beyond an HTTP 200 response?

I verify the response schema, meaningful field values, headers, error semantics, and state changes promised by the endpoint. A create request might return success while failing to persist the record, so I would read it back through a supported API. I would also test authentication, authorization, malformed input, timeouts, and duplicate requests. Contract expectations should be explicit about optional and nullable fields.

Q: How do you test an idempotent create endpoint?

I would send the same valid payload twice with the same idempotency key and verify one business effect, one durable resource, and the documented repeat response. Then I would send a different payload with that key to see whether the service rejects the conflict as specified. A new key should permit a new operation. I would inspect downstream effects as well as the status code because duplicate billing or messages can hide behind correct-looking responses.

Q: How would you test API authorization?

I would build a matrix of subject, resource owner, action, and expected decision. Besides anonymous and expired-token cases, I would try one valid user's identifier against another user's resource and compare read, update, and delete routes. Responses should not expose private data through body text or overbroad list results. The server must enforce the boundary even if the UI omits the action.

Q: What is contract testing, and when does it help?

A contract test checks assumptions between a consumer and provider, such as paths, required fields, value types, and error cases. It is useful when teams deploy independently and a provider change could break a consumer without an end-to-end test noticing quickly. I would keep business semantics and authorization tests alongside the contract checks because a schema alone cannot prove correct behavior. I would version breaking changes deliberately.

Q: How do you test pagination?

I would verify page size, first and last pages, empty results, ordering, and continuation tokens or offsets. The subtle case is data inserted or deleted between requests, which can duplicate or skip items under offset pagination. I would ask whether the API promises a stable snapshot or only best-effort traversal. Tests should assert that the chosen guarantee holds, not assume all pagination schemes behave alike.

For deeper request design, see API idempotency testing. This standalone Python example models the core invariant without a server. Save it as idempotency_demo.py and run python3 idempotency_demo.py; the expected output is "2 requests, 1 created order".

class OrderStore:
    def __init__(self):
        self.by_key = {}
        self.orders = []

    def create(self, key, amount):
        if key in self.by_key:
            previous_amount, order = self.by_key[key]
            if previous_amount != amount:
                raise ValueError("idempotency key reused with different amount")
            return order
        order = {"id": len(self.orders) + 1, "amount": amount}
        self.orders.append(order)
        self.by_key[key] = (amount, order)
        return order

store = OrderStore()
first = store.create("request-17", 250)
second = store.create("request-17", 250)
assert first is second
assert len(store.orders) == 1
print("2 requests, 1 created order")

This local demonstration does not replace tests for transaction boundaries and concurrency in a real service.

4. SQL, Test Data, and Persistence

Q: How would you find duplicate customer email addresses in SQL?

I would group by the normalized address used by the product and filter groups with a count greater than one. I would clarify whether case and surrounding spaces are meaningful before writing the query. Then I would inspect the matching rows to distinguish real duplicates from legitimate shared addresses. If uniqueness is required, a database constraint should prevent recurrence after cleanup.

Q: What does a LEFT JOIN reveal in a QA investigation?

A LEFT JOIN keeps every row from the left table even when no matching row exists on the right. If I join orders to payments, a null payment side can reveal submitted orders with no recorded payment. I would constrain the left set to states that should have a payment, because draft or canceled orders could otherwise look like defects. Duplicated right-side records also deserve an explicit count check.

Q: How would you validate a database migration?

I would run the migration against representative starting states, including nulls, duplicates, and large tables, then check constraints and transformed values. I would verify application behavior while old and new instances may coexist during a rolling deployment. Lock duration, index build behavior, and rollback or forward-fix plans matter for a production-sized table. Read-only reconciliation queries give clearer evidence than a successful migration command alone.

Q: How do you keep parallel tests from corrupting one another's data?

Each test should generate unique identifiers and own the records it creates. Cleanup should target only those identifiers, and tests must not share a mutable default customer whose state depends on execution order. Where possible, I would use an isolated schema or account per worker and a deterministic factory for domain-valid records. Parallel failures often expose hidden data coupling rather than a runner problem.

Q: What would you check after an API says a record was deleted?

I would clarify whether deletion is hard, soft, or delayed and what the retention policy allows. Then I would verify the record is inaccessible through ordinary reads, lists, and search, while checking any authorized audit or recovery view separately. Related records should follow the documented cascade or retention rule. A 204 response alone does not establish that downstream indexes or caches stopped exposing the data.

The following uses Python's built-in SQLite driver and works without external packages. Save it as reconcile.py and run python3 reconcile.py; it should print "unpaid submitted orders: [2]".

import sqlite3

db = sqlite3.connect(":memory:")
db.executescript("""
CREATE TABLE orders (id INTEGER PRIMARY KEY, state TEXT NOT NULL);
CREATE TABLE payments (order_id INTEGER PRIMARY KEY, state TEXT NOT NULL);
INSERT INTO orders VALUES (1, 'submitted'), (2, 'submitted'), (3, 'draft');
INSERT INTO payments VALUES (1, 'captured');
""")
rows = db.execute("""
SELECT o.id
FROM orders AS o
LEFT JOIN payments AS p ON p.order_id = o.id
WHERE o.state = 'submitted' AND p.order_id IS NULL
ORDER BY o.id
""").fetchall()
unpaid = [row[0] for row in rows]
assert unpaid == [2]
print(f"unpaid submitted orders: {unpaid}")

5. UI Automation With Selenium or Playwright

Q: How do you choose a stable locator?

I prefer an accessible role and name when they reflect the user action, such as the "Save" button in a named dialog. A test ID can be useful for an element without a stable accessible label, but it should express a durable contract. I avoid long CSS chains and positional selectors because layout edits can change them without changing behavior. I also confirm the locator is unique before clicking.

Q: Why are fixed sleeps a poor synchronization strategy?

A fixed sleep waits the same duration whether the application is ready early or late. It makes fast runs slower and still fails when a dependency exceeds the chosen delay. I would wait for a meaningful condition, such as a status response, a visible confirmation, or a disabled button becoming enabled. The timeout should reflect the system's expected behavior and produce evidence when exceeded.

Q: How would you debug an intermittent click failure?

I would compare trace, screenshot, console, and network evidence from a passing and failing run. Then I would determine whether the element was missing, covered, disabled, rerendered, or associated with a request that never completed. A locator problem calls for a different fix from a product race or environment outage. I would keep the failing artifact and avoid increasing the timeout until the first divergence is known.

Q: What belongs in a page object?

A page object should provide stable operations and meaningful element access for one page or component. It can hide repetitive locator details, but it should not conceal every assertion or embed unrelated business setup. I would keep a checkout flow readable at the test level while reusing reliable controls such as address entry and payment submission. The abstraction earns its place only if changes become easier to make.

Q: How do you decide whether to automate a UI test?

I would automate a journey when it is important, repeated, stable enough to assert, and difficult to cover fully at lower layers. New or poorly understood behavior may benefit from exploration before it becomes a regression check. A calculation with many combinations usually belongs in unit or API tests, with a small UI sample proving wiring. Runtime and maintenance cost are part of the decision.

This self-contained Playwright test uses supported getByRole and web assertions. After npm install -D @playwright/test and npx playwright install chromium, save it as save.spec.ts and run npx playwright test save.spec.ts. Match the package version to your project rather than inventing a pin. Playwright's assertion documentation describes the retrying assertion used here.

import { test, expect } from '@playwright/test';

test('save announces the new state', async ({ page }) => {
  await page.setContent(
    '<button type="button" onclick="document.querySelector(&quot;[role=status]&quot;).textContent=&quot;Saved&quot;">Save</button><p role="status">Unsaved</p>'
  );
  await page.getByRole('button', { name: 'Save' }).click();
  await expect(page.getByRole('status')).toHaveText('Saved');
});

For related drills, read Selenium interview questions and Playwright interview questions.

6. Coding and Debugging Questions

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

I would scan from left to right, storing each ID in a set. The first ID already present in the set is the answer, so the method preserves encounter order without sorting. Average time and extra space are both O(n), assuming expected constant-time set operations. I would ask whether blanks, nulls, and case differences are valid inputs before finalizing the function.

Q: How do you test a utility that parses timestamps?

I would start with a declared input format and timezone rule, then test valid examples near midnight and year boundaries. Invalid dates, missing offsets, daylight-saving transitions, and extra whitespace need explicit decisions. I would compare parsed instants rather than formatted strings when two offsets represent the same moment. A test suite that only covers a normal noon value misses the expensive failures.

Q: What is the difference between an exception and an assertion failure in test code?

An assertion failure means the system produced an observed result that disagrees with the expected result. An unexpected exception can mean the test could not complete, the environment failed, or the product raised an error before the oracle was reached. I would preserve stack traces and categorize them rather than labeling both as a product defect. The distinction changes who investigates first and what evidence is needed.

Q: How do you review a coding answer under time pressure?

I would walk the happy path, smallest input, largest relevant boundary, duplicate values, and invalid input through the code by hand. Then I would check whether loops terminate, whether state leaks between calls, and whether the complexity claim matches the implementation. If time remains, I would add one executable assertion for a boundary case. A readable correct solution is stronger than an untested optimization.

Q: How would you investigate a regression that appears only in CI?

I would compare runtime environment, browser build, feature flags, test data, clock, locale, and parallelism between CI and local runs. The earliest differing log or trace event guides the next experiment. I would rerun the failing test with the same configuration before changing product code. If the failure depends on a shared service, I would isolate that dependency and record its state.

Save this standard-library Python example as first_repeat.py and run python3 first_repeat.py. It should print "request-7".

def first_repeat(ids):
    seen = set()
    for request_id in ids:
        if not isinstance(request_id, str) or not request_id:
            raise ValueError("request IDs must be nonempty strings")
        if request_id in seen:
            return request_id
        seen.add(request_id)
    return None

assert first_repeat(["request-7", "request-2", "request-7"]) == "request-7"
assert first_repeat([]) is None
print(first_repeat(["request-7", "request-2", "request-7"]))

7. Automation Framework and CI

Q: What would your automation framework contain?

I would separate tests, domain actions, API clients, data factories, configuration, and evidence capture. One test should make the business intent visible while shared code handles stable transport and setup details. I would also explain how secrets enter the run, how parallel tests avoid collisions, and how failures retain traces or logs. A directory diagram alone does not prove the framework works.

Q: How do you select tests for pull requests versus nightly runs?

Pull requests need fast checks that protect changed contracts and critical journeys; longer cross-browser, load, or broad regression work can run on a schedule or before release. I would use failure history and risk to adjust the split rather than treat it as permanent. Any test deferred from the pull-request gate needs a clear owner and escalation path when it fails. The total duration should be measured from developer feedback, not only runner time.

Q: What would you do with a flaky test in a release gate?

I would preserve the failure, measure repeatability, and determine whether the uncertainty comes from product behavior, test code, data, or infrastructure. A temporary quarantine can keep unrelated changes moving only if the lost coverage is visible and tracked. Retries may reveal intermittent behavior, but a green retry must not erase the original failure. The final fix should remove the underlying race or replace an unreliable oracle.

Q: How do you handle secrets in automation?

I would inject credentials through the CI secret store or a secure runtime mechanism, never through committed configuration. Test logs, screenshots, traces, and failure attachments must be checked for token leakage. Accounts should have only the permissions needed for the test and should rotate according to the organization's policy. A test should fail clearly when a required secret is unavailable without printing its value.

Q: How do you measure whether automation is useful?

I would track feedback time, failure diagnosis time, escaped defects by risk area, flaky-test rate, and maintenance effort. Raw test count says little if many cases exercise the same path or never fail meaningfully. I would compare trends against a baseline and note changes in product scope or infrastructure. The goal is better release decisions, not a larger number of scripts.

For a focused incident drill, use CI/CD troubleshooting interview questions for QA.

8. Reliability, Performance, and Security

Q: How would you test a retrying message consumer?

I would model first delivery, duplicate delivery, delayed delivery, and permanent failure separately. Tests should verify that a repeated event does not duplicate the business effect and that poison messages reach the documented dead-letter path. I would check what happens if the worker commits the database change but fails before acknowledging the message. Logs need a correlation ID so an operator can reconstruct the sequence.

Q: How do you distinguish load, stress, and soak testing?

Load testing checks behavior at an expected workload, stress testing pushes beyond expected capacity to reveal limits, and soak testing holds a workload long enough to expose leaks or degradation. For each, I would define the workload mix, data volume, environment, and pass criteria before running it. Response time percentiles, error rates, queue depth, and resource use should be interpreted together. A single average latency hides tail failures.

Q: What security checks belong in a QA interview answer?

I would cover access control, input validation, data exposure, session handling, and safe error responses for the feature under discussion. For an account API, horizontal access attempts and list filtering matter more than a generic claim that "security was tested." Automated checks can catch repeated classes of faults, but design review and specialist assessment still matter. I would never use live customer data or unauthorized scanning as an interview demonstration.

Q: How would you test a cache around an API?

I would verify that cached reads return the right tenant's data and that writes invalidate or update the relevant entries. I would test expiration, concurrent updates, stale reads, and behavior when the cache is unavailable. The acceptable staleness window must come from the product contract because instant consistency is not always required. I would compare response headers and backing state only through permitted interfaces.

Q: How do you test an asynchronous workflow without sleeps?

I would submit the command, capture its correlation ID, and poll a supported status endpoint until a documented deadline. Each poll checks an allowed intermediate state; the final assertion verifies both outcome and side effect. If the deadline expires, I would report the last state and trace context rather than only "timed out." The polling interval should avoid overwhelming the service under test.

9. Defects, Collaboration, and Behavioral Answers

Q: Tell me about a defect you found late in a release.

I would describe the user impact, exact trigger, evidence, and why earlier checks missed it. Then I would explain the containment decision, who owned it, and whether the release proceeded with a safeguard or was delayed. I would finish with the specific prevention change, such as a contract check or revised acceptance example. I would separate my contribution from the team's decision.

Q: What do you do when a developer rejects your bug?

I would reproduce it with a minimal data set and compare actual behavior with a written requirement or user outcome. If the expected behavior is unclear, I would bring the product owner into the discussion and record the agreed rule. I would avoid arguing over severity before the facts are aligned. A useful resolution leaves a shared test or acceptance example for the next change.

Q: How do you communicate incomplete testing?

I would name the untested journeys, why they were not exercised, and the plausible customer impact. Then I would summarize the evidence that does exist and offer options such as a limited rollout, targeted check, or delayed release. The release owner needs a recommendation and explicit residual risk, not a vague "QA blocked" label. I would record the gap for follow-up rather than let it disappear after launch.

Q: Describe a disagreement about automation coverage.

I would explain which risk the proposed test was meant to catch, the lower-layer alternatives, and the cost of a UI-only approach. If the team preferred a broad end-to-end test, I would offer a small representative UI flow plus API cases for permutations. I would use failure history or a spike to resolve uncertain assumptions. The story should show collaboration and a decision, not just that I won an argument.

Q: How do you explain a technical failure to a client or product manager?

I would start with affected users and the action they cannot complete, then describe what is known, unknown, and being tested next. I would avoid stack traces unless the audience needs them to choose a response. An estimate should be labeled as an estimate and updated when evidence changes. The message should end with a decision point or next update time that I can actually honor.

10. Persistent Systems QA Interview Questions for Final Preparation

Q: How do you choose which skills to revise from a long job description?

I would rank requirements by whether they are essential to the role, present on my resume, and likely to be demonstrated live. If the posting names C# and Selenium, I would practice that combination before spending time on an unrelated framework. I would prepare one evidence story for each major requirement and identify honest gaps. Broad preparation is useful only after the highest-risk claims are defensible.

Q: What project walkthrough would you take into a technical round?

I would choose a project where I can explain the system boundary, the primary quality risk, my test strategy, one failure I debugged, and the resulting change. I would be ready to sketch the request path and show why checks sit at unit, API, or UI layers. I would bring sanitized examples rather than proprietary code or customer data. The strongest walkthrough includes an uncomfortable tradeoff and what I learned.

Q: How do you answer a question about a tool you have not used?

I would state my actual experience and identify the closest transferable concept, such as explicit waits in one browser tool or request assertions in another. Then I would outline how I would verify the tool's current API with official documentation and build a small spike. I would avoid claiming production experience based on a tutorial. Honesty lets the interviewer assess learning speed accurately.

Q: How should you prepare for a live coding exercise?

I would practice clarifying input and output, writing a simple solution, testing an edge case, and explaining complexity aloud. I would use the language specified for the role and rehearse without autocomplete if the assessment conditions are unknown. For QA-oriented code, I would pay attention to invalid input and diagnostic failure messages. A working small program with tests is better evidence than a half-finished clever algorithm.

Q: What is your final preparation checklist before the interview?

I would verify the interview link or location, role description, permitted tools, and chosen language. I would reread every resume metric and prepare the baseline, method, and my contribution behind it. I would run one coding example, review one API and SQL scenario, and rehearse two concise project stories. Finally, I would prepare questions about the team's current quality risks and the first assignment.

How Interviewers Grade Your Answers

Interviewers commonly look for a correct core answer, explicit assumptions, realistic edge cases, and evidence that you can act on the result. In a scenario answer, state the risk before listing test cases; in a coding answer, make the contract and verification visible; in a project story, distinguish your decision from the team's work. A good answer can acknowledge uncertainty while explaining how you would resolve it. The exact rubric varies by interviewer and role, so use this as a preparation lens rather than a promised scoring sheet.

A useful self-check is to score each practice answer from zero to two on four dimensions: correctness, specificity, verification, and communication. Zero means absent, one means implied, and two means demonstrated with a concrete example. An eight-point answer is not necessarily long; it gives enough detail for a follow-up question. Practice aloud in the interview practice area and use resume upload to identify claims that need proof.

Common Mistakes

• Treating a single online report as Persistent's guaranteed interview sequence.
• Giving a tool definition without showing the failure it helps diagnose.
• Saying "I tested everything" instead of naming scope, priority, and residual risk.
• Checking only HTTP status while ignoring authorization and durable side effects.
• Adding fixed sleeps to hide synchronization or environment faults.
• Showing a framework diagram without data isolation, CI execution, or evidence.
• Quoting coverage percentages with no denominator, baseline, or method.
• Reusing confidential client details to make an answer sound specific.
• Claiming team results as personal work or inventing a metric under pressure.
• Describing a bug fix without the test or process change that prevents recurrence.

Conclusion

These Persistent Systems QA interview questions cover the reasoning behind test design, API and SQL checks, UI automation, coding, framework health, reliability, and collaboration. The highest-value preparation is to connect each answer to a real project and a verifiable result. Use the job description to choose the relevant language and tools, run the code examples, and rehearse follow-up questions until you can explain both the decision and its limits.

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)