QA Engineer interview questions and answers

I would first check requirements: login with email or phone, password rules, lockout policy, and whether there is OTP or social login. Positive tests: valid credentials log in and land on the right page. Negative tests: wrong password, unregistered email, empty fields, spaces around the email, very long input, and special characters, including SQL injection and script strings to see they are handled safely. Security checks: the password is masked, the site uses HTTPS, the error message does not reveal whether the email exists, and the account locks or slows down after repeated failures. Session tests: remember me, logout clears the session, the back button after logout does not show private pages, and forgot password works end to end. I also test on mobile and different browsers, with keyboard only, and with a screen reader to check labels and error announcements.

The STLC is the set of steps QA follows to test a product. It starts with requirement analysis, where we study what should be built and raise questions early. Then test planning: scope, approach, resources, schedule and risks. Next comes test case design, where we write test cases and prepare test data. Then environment setup, making sure the test environment and data are ready. Then execution, where we run tests, log bugs and retest fixes. Finally test closure, with a summary report, metrics and lessons learned. Each phase has entry and exit criteria, for example execution starts only when the build passes smoke tests. The STLC runs alongside the SDLC: while developers design and code, QA plans and designs tests. In Agile teams the same steps happen in small cycles inside every sprint, not once per project.

A regression suite should protect what matters most, not every test ever written. I include the core business flows first, like signup, login, search, add to cart and payment, because a break there hurts every user. I add tests for features that change often or have a history of bugs, and a test for each important bug we fixed so it does not come back. I include integration points, like payment gateways and third-party APIs, since changes elsewhere often break them. I tag tests by priority so we can run a quick smoke set on every build and the full set before a release. Stable, repeated regression tests are good candidates for automation. Finally, I review the suite regularly and remove or update tests for features that changed or were removed, so the suite stays fast and trusted.

In Scrum, QA is part of the team from the start, not a separate phase at the end. In backlog refinement I ask questions and help write clear acceptance criteria, including edge cases, so developers know what done looks like. During the sprint I prepare test cases and data while developers code, then test each story as soon as it is ready instead of waiting for the last two days. I pair with developers to test early builds and review unit test coverage. I keep the regression suite and automation updated so we can release often with confidence. In the daily standup I raise blockers like a broken test environment. I also help define the definition of done, for example that a story is not done until it is tested, its bugs are fixed and automated checks pass.

Positive testing checks that the system works with valid input and normal user behaviour. Negative testing checks that it handles invalid input or unexpected actions without crashing and with a clear message. Take a mobile number field for India that should accept 10 digits starting with 6 to 9. A positive test is entering 9876543210 and seeing it accepted. Negative tests include entering 9 digits, 11 digits, letters, a number starting with 1, spaces, an empty value, or pasting +91 with the number, depending on the rules. For each, the expected result is a friendly error and no data saved. Negative testing is important because real users make mistakes and attackers send bad input on purpose. Many serious bugs, like a 500 error or a crash, are found through negative tests rather than the happy path.

When I find a defect I first reproduce it and log it as New in Jira, with environment, build, exact steps, expected and actual results, and a screenshot, recording or logs. In triage the team sets severity and priority and assigns it, or marks it as a duplicate, rejected because it works as designed, or deferred to a later release. The developer fixes it and moves it to Fixed or Ready for QA, noting the build that has the fix. I retest with the original steps and data. If it works I close it, and if not I reopen it with new evidence. I also run regression tests around the fix, because fixes can break nearby features. Keeping statuses accurate makes the defect dashboard trustworthy for release decisions.

A test scenario is a one-line idea of what to test, such as "Verify a user can reset their password." It helps plan coverage quickly and discuss it with the team. A test case is the detailed, repeatable version: an ID, preconditions like "user exists with a verified email", steps such as opening the reset page, entering the email and clicking the link, the test data, and the expected result, for example "the new password works and the old one is rejected". One scenario turns into several cases: valid reset, expired link, reused link, unknown email and weak new password. I use scenarios early in a sprint and turn high-risk ones into full test cases in TestRail, especially those we run in every regression cycle.

I start with positive cases: a normal PDF, and one exactly 10 MB, checking the progress bar, success message and that the file downloads and opens unchanged. Then boundaries and negatives: a file just over 10 MB, a zero-byte file, a JPG, a DOCX and a file renamed from .exe to .pdf, which the server should reject by checking content, not just the extension. I also test a password-protected or corrupted PDF and check the error messages are clear. For edge cases I try long file names, spaces, Arabic characters and duplicates, plus a slow or dropped network, cancelling mid-upload and uploading several files at once. Finally I check limits are enforced on the server through the API, not only in the browser, and that one user cannot open another user's files.

Equivalence partitioning groups inputs that the system should treat the same way, so I test one value from each group instead of every value. Boundary value analysis adds tests at the edges of those groups, because developers often make off-by-one mistakes, like writing less than instead of less than or equal. Take a quantity field that allows 1 to 10 items. The partitions are below 1 (invalid), 1 to 10 (valid) and above 10 (invalid), so I might pick 0, 5 and 11. With two-value BVA I add the edges: 0, 1, 10 and 11. I also think about the input type, such as decimals, empty input, negative numbers and letters, which form extra invalid partitions. Together the two techniques give strong coverage with only a handful of tests.

I plan exploratory testing with a short charter, such as "Explore the checkout with saved cards to discover problems with expired cards and currency," and a time box of 60 to 90 minutes. During the session I learn the feature, design tests and run them at the same time, using heuristics like boundaries, interruptions, wrong order of steps and different user personas. I keep notes as I go: what I covered, bugs found, questions for the product owner and ideas for later sessions, plus screenshots and timestamps. Bugs go into Jira straight away with clear steps. At the end I debrief with the team on what was covered, what was not and how risky the area feels. Good findings often become new regression test cases.

First I read the stories and meet the product owner and developers to clarify rules: how many people can split, can amounts be unequal, what happens if one person does not pay, and refund behaviour. Then I write the plan. Scope includes creating a split, inviting users, partial payment, reminders, cancel and refund; out of scope might be international currencies. I list risks, with money accuracy and rounding at the top, then concurrent payments and notification failures. Test types: functional, negative cases like amounts that do not add up, integration with the payment gateway and bank callbacks, security such as one user changing another's share, basic load on busy days, and accessibility. I plan test data, sandbox accounts and devices. Entry criteria: build passes smoke tests. Exit criteria: no open critical bugs and all high-risk tests passed. I share daily progress.

I start from the API contract, such as an OpenAPI spec. For each endpoint, I check the status code, but also the response body: required fields exist, types are correct, and values match the request and the database. I validate against the schema, check headers like Content-Type, caching and CORS if needed. For auth, I test missing, expired and wrong-role tokens, and make sure one user cannot read another user's data by changing an ID. Negative tests include missing fields, wrong types, very long strings, and unsupported methods. I check side effects: after POST, the record really exists; after DELETE, it is gone. I test pagination, sorting and filters, idempotency for PUT and retries, and that error responses are consistent and do not leak stack traces. Finally I check response time. I use Postman or code-based tests so they run in CI.

I first check whether the developer is right about the spec. If the requirement really describes this behaviour, then the issue is not a code bug but a possible design or requirement problem. I explain my concern in terms of user impact, for example "users who enter a promo code after selecting COD lose the discount without any message, which may cause complaints". I bring evidence: steps, a screen recording, and if possible support tickets or analytics showing similar confusion. Then I involve the product owner, because deciding expected behaviour is their call, not mine or the developer's. If they agree, the ticket becomes an improvement story. If they decide to keep it, I accept that, close the bug with the decision noted, and maybe suggest a small help text. The goal is a good product and a good working relationship, not winning an argument.

I would automate tests with the best return for the effort. First, a smoke suite for critical flows like login, search and checkout, running on every build. Then regression tests that we repeat every release and that rarely change, such as tax calculations or account settings. Where possible I would automate at the API level, because API tests are faster and more stable than UI tests, and keep only a small number of end-to-end UI journeys. Data-heavy checks, like testing a calculation with 50 input combinations, are also great for automation. I would keep manual work for exploratory testing, usability and visual judgement, and for features still changing every sprint, because automating them now means constant rework. I would also plan maintenance time, since a flaky or outdated suite quickly loses the team's trust.

I try to make test data repeatable and safe. Instead of relying on records someone created by hand months ago, I create data with API calls, SQL scripts or seed files, so any tester or automated test can set up the same state in any environment. I avoid real customer data; if production-like data is needed, it should be masked or synthetic to protect privacy and follow laws like the DPDP Act. To avoid conflicts, each test or tester uses unique data, for example a new user with a timestamp in the email, so one test does not change another's data. Tests clean up after themselves, or the environment resets regularly. I keep important data sets documented and in version control, like special accounts for edge cases. This reduces "works on my machine" problems and false failures.

First I would rebuild trust in the pipeline. Using CI history I would list tests that fail and then pass on the same code, and how often. Those go into a quarantine group that still runs but does not block merges, each with a ticket and owner. Then I look for root causes using traces, videos and logs. The usual causes are fixed sleeps or missing waits, shared accounts or data between parallel tests, dependence on test order, unstable environments and brittle locators. Fixes are web-first assertions, unique data per test created through the API, role or test-id locators and mocking unreliable third parties. I would also agree a rule that a test leaves quarantine only after many clean runs, review new tests for these patterns and report the flaky rate each sprint. Retries are fine as a buffer, but not as a hiding place.

I would use the gateway's sandbox and its test cards. Happy paths cover Visa and Mastercard, saved cards and 3-D Secure challenges. Negative paths cover declined, insufficient funds, expired cards, a failed 3-D Secure step and gateway timeouts, checking that clear messages appear and the order is not marked paid. Next I test the risky edge cases: double-clicking Pay, refreshing during redirect, pressing back and slow networks, making sure the customer is charged only once. I check totals, 5% VAT, discounts, rounding to fils and refunds, both partial and full. I also verify webhooks, since the gateway may confirm a payment after the browser closes, and that order status, payment records and receipts all agree. Finally I confirm card numbers never appear in logs or our database and that everything runs over HTTPS.

I start by agreeing measurable goals with product and engineering, for example 1,500 requests per second at peak with p95 under 400 ms and errors under 0.5%. Then I build a workload model from analytics or business forecasts: which endpoints are called, in what mix, with what data and pauses. I script it in k6 or JMeter and run it against a production-like environment with realistic data volumes, while watching CPU, memory, database and queue metrics. I run a baseline first, then a load test at expected peak, a stress test to find the breaking point, a spike test for launch bursts and a soak test for leaks. I report percentiles rather than averages, and where it fails I work with developers to find the bottleneck and rerun. Thresholds in CI catch regressions later.

First the layout: in RTL the whole screen should mirror, including menus, back arrows, progress steps, carousels and swipe gestures, while icons without direction, like a tick, stay the same. Then bidirectional text: phone numbers, prices, emails and English brand names must keep their left-to-right order inside Arabic sentences. I check translations with a native speaker for meaning and tone, and look for truncated or overlapping text, missing glyphs and wrong fonts. For formats I test dates, currency such as AED and SAR, number separators, and Eastern Arabic digits if the product supports them, plus the Hijri calendar where used. I enter and search Arabic text, including letter variants, and check that emails, SMS, PDFs and push notifications also come out correctly. Finally I switch languages mid-session and confirm nothing breaks.

I treat WCAG 2.2 AA as the target and build checks into each story rather than leaving them to the end. Automated scans with axe, in DevTools and in our Playwright suite, catch issues like missing labels, low contrast and bad ARIA quickly. But automation finds only part of the problems, so I also test manually. I complete key journeys using only the keyboard, checking focus order, visible focus and that dialogs trap and return focus properly. I use a screen reader such as NVDA or VoiceOver to confirm buttons, images and errors are announced clearly. I zoom to 200% and 400% to check reflow, and confirm errors are not shown by colour alone. I also ask for accessibility notes in acceptance criteria and design reviews, because fixing them early is much cheaper.

First the priority is users. I help reproduce the bug, measure who is affected, and test the hotfix quickly but carefully, including a short regression around the fix. Once it is stable, we run a blameless root cause analysis. The question is not "who missed it" but "why did our system miss it". Typical causes are a missing test scenario, a difference between staging and production such as configuration, data volume or a third-party sandbox, a late change that skipped full testing, or unclear requirements. Then we act on each cause: add the scenario to the regression suite and automation, make staging closer to production, require a smoke test for late changes, or add acceptance criteria. I also suggest production monitoring and alerts for that flow, so similar problems are detected in minutes. Finally I share the lessons with the team openly.

I prefer metrics that reflect real customer impact and help the team improve. Escaped defects, meaning bugs found in production, broken down by severity, show how well we catch issues before release. Change failure rate and mean time to recovery, from DORA metrics, show release health. I track time to fix critical bugs, and in automation the flaky test rate and pipeline duration, because slow or unreliable feedback hurts everyone. Customer-facing signals like crash-free sessions and support tickets per release are also valuable. I avoid vanity metrics such as number of test cases written, bugs logged per tester or raw coverage percentage, because they are easy to game and can push people to log trivial bugs or write useless tests. I look at trends over time rather than single numbers, and use them in retrospectives to find improvements, never to blame individuals.

I start with the provider's sandbox and documented test cards or UPI test handles to cover success, decline, insufficient funds and 3-D Secure or OTP flows. The tricky part is everything around the happy path. Payments can be pending, time out or succeed after our app gave up, so I test timeouts and what the user sees. Webhooks may arrive late, twice or out of order, so I replay them and check that order status is still correct and no double fulfilment happens. Since the sandbox cannot produce every error, I use a mock server, like WireMock, to simulate 500 errors, slow responses and malformed data. I check idempotency keys on retries, refunds and partial refunds, and that our records reconcile with the gateway's settlement report. Finally, I make sure there is monitoring in production for failure rates, because sandbox and live behaviour can differ.

I would first measure where bugs are introduced and found, to show the team the cost of late discovery. Then I would push quality upstream. QA joins refinement and design reviews to ask about edge cases and write acceptance criteria with concrete examples before coding starts, sometimes in a given-when-then format. Developers own unit and integration tests, and code reviews include a short testing checklist. Every pull request runs fast automated checks in CI: linting, unit tests and a small API suite, so problems show up in minutes. Features are tested on a preview environment as soon as each story is done, instead of a big testing phase at the end of the sprint. Feature flags let us merge small changes safely. I would review progress in retrospectives using metrics like bugs found per stage. The goal is fewer bugs created, not just more bugs found.

Because the output changes, I test properties and quality levels rather than exact strings. First, with the product team, I define what good means: for a support chatbot, answers must be accurate, on-topic, polite, in the right language, and never reveal private data or make up refund policies. I build an evaluation set of a few hundred real and edge-case questions, including tricky and adversarial ones like prompt injection or abusive language. Each response is checked with automated rules, such as format and banned content, plus scoring by human reviewers or a judge model against a rubric, and we track the pass rate. Every new model or prompt version runs this set, so we catch regressions. I also test the fixed parts normally: APIs, fallbacks when the model times out, and handover to a human. In production, we monitor feedback and run A/B tests for impact.

I would start with the risks and the pyramid, not the tool. Developers own unit tests, QA and developers share API tests, and only critical user journeys get end-to-end UI tests. I would pick a tool in the team's language, likely Playwright with TypeScript, because it covers UI and API testing, auto-waits and runs in parallel. The structure would use page or component objects, fixtures for login and setup, data builders that create unique data through APIs, and environment config kept out of the code. Tests must be independent, use role or test-id locators and avoid fixed sleeps. In CI a fast smoke set runs on every pull request and the full suite nightly, with HTML reports, traces and named owners. To keep it healthy over years I would treat test code like product code, with reviews, linting, a flaky-test policy and regular pruning of low-value tests.

I would stop relying on the shared environment as the main safety net. Each team tests its service in isolation with unit, component and API tests, using containers for its own database and mocks for other services. Consumer-driven contract tests with a tool like Pact then protect the boundaries: consumers publish what they need, providers verify it in CI and a can-i-deploy check blocks breaking releases. On top of that I keep a small set of critical end-to-end journeys, such as sign-up and checkout, run in short-lived environments created per change where possible. Because services talk through events, tests poll for eventual outcomes instead of using fixed waits. Finally I add safety after deployment: canary releases, feature flags, synthetic monitoring and good tracing, so we detect issues quickly when something slips through.

I use the OWASP Top 10 and API Security Top 10 as a checklist for each feature. The most valuable habit is testing access control with two accounts and different roles: changing IDs in URLs and request bodies, calling admin endpoints as a normal user and adding fields like role to requests. I check input handling with safe probes for SQL injection and XSS, and confirm validation happens on the server, not only in the browser. For authentication I test token expiry, logout, password reset links, brute-force limits and that error messages do not reveal whether an account exists. I run OWASP ZAP baseline scans and dependency checks in CI, and make sure secrets and real personal data never appear in logs. I only test environments I have permission for, and I report serious findings privately and bring in security specialists when needed.

I would start with data: how long each test takes, how often it finds real bugs and what it covers. Usually a few slow UI tests dominate, and many duplicate each other. I would move checks down the pyramid, verifying business rules through APIs and keeping UI tests for true user journeys. Setup is often the hidden cost, so tests should create data through APIs and reuse a saved login state instead of clicking through forms. Next comes parallel execution and sharding across CI machines, which needs isolated test data. For pull requests I would run a risk-based subset chosen by the code that changed, plus a critical smoke set, and run the full suite nightly and before releases. Finally I would delete or merge low-value and flaky tests and watch escaped defects to make sure confidence did not drop.

I would pick devices and OS versions from analytics, covering most users plus low-end and oldest supported devices, and test on real devices through a device cloud like BrowserStack. Automation would be layered: unit and API tests carry most checks, and a focused UI suite in Appium, or XCUITest and Espresso, covers login, transfers and payments on every build. Manual and exploratory time goes to mobile risks: calls and notifications mid-transfer, the app killed in the background, permission changes, switching between Wi-Fi and mobile data, and upgrading from older versions with saved data. Security checks cover secure storage, session timeout, biometrics and certificate pinning. Because users stay on old versions, backend APIs must remain backward compatible. Releases go out in stages, with crash monitoring, feature flags to switch off problems and a forced-update path for critical issues.