Swiggy QA Interview Questions (2026)

TL;DR

Prepare for Swiggy QA interviews by practicing food delivery and quick-commerce scenarios across users, merchants, delivery partners, payments, inventory, APIs, events, and mobile clients. Strong answers clarify assumptions, identify invariants, rank risks, choose the right test layer, and explain how failures will be detected and recovered.

Key Takeaways

• Treat Swiggy as a multi-sided, real-time commerce system whose customer, merchant, delivery, payment, and support states must agree.
• Prioritize order integrity, payment safety, inventory accuracy, location behavior, privacy, and recovery before cosmetic checks.
• Model food delivery and Instamart as related but distinct domains with different catalog, fulfillment, substitution, and freshness risks.
• Show technical depth through API contracts, idempotency, events, SQL evidence, mobile lifecycle testing, and targeted automation.
• Use runnable examples to demonstrate engineering judgment, then state clearly what each example does not prove.
• Confirm the role-specific interview format with the recruiter because no single public Swiggy QA loop applies to every team and level.
• Support release recommendations with customer impact, test evidence, observability, rollout controls, and residual risk.

The most useful way to prepare for swiggy qa interview questions is to practice decisions inside a real-time, multi-sided commerce system. Interviewers can evaluate whether you protect order, payment, inventory, location, and customer-support outcomes, not just whether you remember testing definitions.

Swiggy's official business overview describes food delivery, Instamart, and Dineout experiences involving consumers, restaurants or merchants, dark stores, and delivery partners. Those public product flows create realistic preparation domains, but they do not reveal a universal interview sequence or Swiggy's private architecture.

Confirm the exact rounds, allowed language, coding environment, and role scope with your recruiter. Use this guide to build transferable reasoning for QA Engineer, Quality Engineer, and SDET conversations without claiming that every candidate receives the same questions.

TL;DR

Use one answer structure when the prompt is broad: clarify the actor and business goal, draw the state transitions, state the highest-risk invariants, distribute checks across layers, define controlled data, and finish with observability plus residual risk.

1. Swiggy QA Interview Questions: Role and Platform Context

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

Expect the content to vary by team, seniority, and whether the role emphasizes exploratory testing, automation, mobile, services, or quality leadership. Prepare for some combination of product test design, debugging, coding, API or database reasoning, and behavioral evidence, but verify the actual format with the recruiter. A credible candidate separates confirmed logistics from preparation assumptions and adapts examples to the posted role.

Q: How would you analyze the job description before the interview?

Convert every requirement into a proof table with columns for the skill, a project where you used it, the risk you addressed, and an outcome you can defend. If Java and API testing appear together, bring a service-level example rather than a Selenium-only story. Highlight missing exposure honestly, then explain the adjacent experience and focused practice you completed.

Q: How would you describe Swiggy as a test system?

Model it as several coordinated products whose actors observe different projections of a transaction. A food order connects a consumer, restaurant, delivery partner, payment path, support workflow, and notification channel, while Instamart adds dark-store inventory and picking. Quality means those views converge on a legal business outcome even when a dependency is slow or a user retries.

Q: Which risks would you test first?

Start with duplicate or missing orders, incorrect charges, stale item availability, unsafe authorization, wrong delivery location, privacy exposure, and states that cannot recover automatically. Rank them by impact, likelihood, detectability, and reversibility instead of assigning every case the same priority. The risk-based testing guide provides a useful framework for explaining why one scenario must precede another.

2. Test Restaurant Discovery, Menus, and Carts

Q: How would you test restaurant search and filters?

Create controlled restaurants with unique names, cuisines, service areas, ratings, cost bands, and open states, then test exact terms, spelling variants, filters, sorting, pagination, and zero results. Assert properties such as an active cuisine filter never returning an ineligible restaurant, while allowing documented indexing delay. Include sponsored labeling, unavailable outlets, location changes, and experiment assignment so relevance checks do not become brittle position assertions.

Q: A restaurant appears open but cannot accept an order. What would you investigate?

Record the consumer location, restaurant identifier, displayed hours, serviceability result, menu availability, and time source. Trace whether the discrepancy comes from cached discovery data, merchant status, capacity throttling, delivery radius, or a client that did not refresh. The fix may require stronger cache invalidation or clearer messaging, and the regression should cover the boundary that produced the disagreement.

Q: How would you validate a menu with variants and add-ons?

Build a constraint matrix for required choices, minimum and maximum selections, incompatible options, quantity, dietary labels, and price deltas. Verify that the cart stores the selected variant identifiers rather than only visible text, because two choices may share a label. Reopen the cart after a menu update and confirm the user must review any unavailable selection or changed amount before payment.

Q: What should happen if an item price changes while it is in the cart?

Treat the server-side checkout quote as authoritative and display the change before the user commits. Test higher and lower prices, fees, taxes, packaging charges, stale coupons, concurrent menu edits, and a retry using an expired quote. The final order, payment authorization, invoice, and merchant view must agree on the accepted amount.

Q: How would you test cart isolation across restaurants?

Clarify whether the product permits one restaurant per food cart and how switching outlets should behave. Verify the warning, explicit user choice, item removal, coupon recalculation, saved preferences, and return navigation without silently mixing merchant identifiers. Also test two tabs and two devices so an old cart update cannot overwrite a newer confirmed cart without conflict handling.

3. Test the Food Order and Restaurant Lifecycle

Q: How would you model a food order state machine?

List states such as draft, submitted, payment pending, placed, accepted, preparing, picked up, delivered, canceled, and refunded only as a starting hypothesis. Ask which service owns each transition, which actors may trigger it, and which terminal outcomes permit compensation. Tests should reject illegal moves, preserve transition history, and tolerate duplicate delivery of the same event.

Q: The restaurant rejects an order after payment authorization. What should you verify?

Check that fulfillment stops, inventory or capacity reservations release, the customer sees an accurate reason, and the financial path voids or refunds according to the payment state. Validate notification timing and support visibility rather than trusting a single client message. Reconciliation should detect any authorization that lacks either a valid order or a completed compensation outcome.

Q: How would you test cancellation racing with restaurant acceptance?

Coordinate two clients or service calls so cancellation and acceptance reach the authoritative order service almost together. Verify one legal result based on the documented precedence rule, with no combination such as canceled to the customer but preparing to the restaurant. Repeat around cutoffs, delayed responses, and retries, then inspect the event history for a deterministic resolution.

Q: How do you prevent duplicate orders after a network timeout?

Send a stable idempotency key with retries and bind it to the customer, request payload, and permitted time window. The same key and same payload should return the original outcome, while the same key with different contents should produce a clear conflict instead of creating another order. Test the timeout both before and after persistence because those paths exercise different recovery behavior.

The following fixture is an interview-safe demonstration, not a Swiggy endpoint. Save it as order-idempotency.test.mjs and run it with Node 22 or later.

import test from 'node:test';
import assert from 'node:assert/strict';
import http from 'node:http';

const ordersByKey = new Map();

const server = http.createServer(async (request, response) => {
  if (request.method !== 'POST' || request.url !== '/orders') {
    response.writeHead(404).end();
    return;
  }

  const key = request.headers['idempotency-key'];
  let body = '';
  for await (const chunk of request) body += chunk;

  if (!key) {
    response.writeHead(400, { 'content-type': 'application/json' });
    response.end(JSON.stringify({ error: 'missing idempotency key' }));
    return;
  }

  const previous = ordersByKey.get(key);
  if (previous && previous.body !== body) {
    response.writeHead(409, { 'content-type': 'application/json' });
    response.end(JSON.stringify({ error: 'key reused with different payload' }));
    return;
  }

  const order = previous?.order ?? { id: 'order-101', status: 'PLACED' };
  ordersByKey.set(key, { body, order });
  response.writeHead(previous ? 200 : 201, { 'content-type': 'application/json' });
  response.end(JSON.stringify(order));
});

test('a retried submission returns one order', async (t) => {
  await new Promise((resolve) => server.listen(0, '127.0.0.1', resolve));
  t.after(() => server.close());

  const address = server.address();
  const url = 'http://127.0.0.1:' + address.port + '/orders';
  const options = {
    method: 'POST',
    headers: { 'content-type': 'application/json', 'idempotency-key': 'attempt-7' },
    body: JSON.stringify({ restaurantId: 'r-9', itemIds: ['i-2'] })
  };

  const first = await fetch(url, options);
  const retry = await fetch(url, options);

  assert.equal(first.status, 201);
  assert.equal(retry.status, 200);
  assert.deepEqual(await retry.json(), await first.json());
  assert.equal(ordersByKey.size, 1);
});

Verify it with node --test order-idempotency.test.mjs. The output should report one passing test and no failed tests.

Q: How would you test a late delivery complaint?

Build a timeline from promised ETA revisions, restaurant preparation, assignment, pickup, route progress, arrival, and customer contact rather than judging only the final timestamp. Check whether the promise changed transparently and whether any automated remedy follows the correct eligibility rule. Compare similar successful orders to distinguish a restaurant delay, dispatch shortage, map error, client lag, or notification failure.

4. Test Dispatch, GPS, ETA, and Handoff

Q: How would you test delivery-partner assignment?

Vary partner availability, distance, vehicle constraints, current workload, service zone, and merchant readiness in a controlled simulator. Assert safety properties, such as one active assignment owner and no dispatch to an ineligible partner, instead of asserting an undisclosed ranking algorithm. Include rejection, timeout, reassignment, order cancellation, and a partner going offline after the offer.

Q: Two delivery partners accept the same order. What is the expected result?

The assignment service needs one authoritative winner, and the losing acceptance should receive an unambiguous stale-offer response. Confirm that only the winner can progress pickup, compensation is not duplicated, and consumer tracking shows a single active partner. Capture request IDs and assignment versions to prove whether concurrency control failed or the client merely displayed old data.

Q: How would you test noisy or jumping GPS coordinates?

Replay traces containing normal movement, stationary drift, impossible jumps, tunnels, denied permission, and stale timestamps. Verify that ETA and arrival logic use validated server inputs and do not mark delivery complete from one anomalous point. The partner app should communicate degraded accuracy without exposing raw location history beyond the intended audience and retention policy.

Q: How would you validate ETA accuracy without hard-coding an exact minute?

Define error bands and service-level expectations by journey phase, geography, traffic condition, and forecast horizon with product and data stakeholders. Use historical replay or synthetic routes to compare promised and actual milestones, then inspect bias as well as average error because systematic optimism harms trust. UI tests should focus on consistent display and update behavior, while model evaluation belongs in a controlled data pipeline.

Q: What would you test at pickup and delivery handoff?

Cover merchant confirmation, package count, pickup authorization, wrong-order prevention, customer instructions, proof or PIN flow where applicable, failed contact, and safe completion rules. Never place real phone numbers, addresses, or reusable codes in shared test artifacts. Interrupted handoff must resume from the server's current state so repeated taps cannot create conflicting completion records.

5. Test Payments, Offers, Membership, and Refunds

Q: How would you test a payment timeout?

Separate a client timeout from provider authorization, capture, and internal order persistence. Simulate no authorization, successful authorization with a lost response, delayed callback, duplicate callback, and a user retry, then verify one payable order and one financial outcome. Customer messaging, support tools, reconciliation jobs, and alerts for stuck transactions are part of the acceptance criteria.

Q: How would you test offer and coupon stacking?

Turn eligibility into a decision table covering customer segment, restaurant, items, minimum basket, time, geography, payment method, membership, usage count, and combinability. Check exact boundaries and the reason shown when an offer becomes invalid after a cart change. The discount displayed before payment must match the order ledger and refund allocation, including capped and item-level benefits.

Q: What is your refund test strategy?

Partition full, partial, item-level, fee-only, duplicate-request, rejected, and delayed refunds across supported payment instruments. Confirm the refundable amount never exceeds the captured amount after previous adjustments, and preserve links among complaint, order, payment, and refund identifiers. Validate customer communication separately from settlement because a successful API response may still precede external completion.

Q: What is special about testing cash on delivery?

Cash on delivery changes collection, cancellation, fraud, handoff, settlement, and reconciliation behavior without a pre-order digital authorization. Test exact cash, change expectations, partial fulfillment policy, failed delivery, collected-amount entry, and correction permissions. Ensure that a payment callback from another method cannot accidentally mark the same order paid twice.

Q: How would you validate Swiggy One benefits?

Treat membership status, geography, service, merchant eligibility, basket threshold, benefit cap, renewal, and cancellation as independent dimensions. Test a membership change while the cart is open and explain which quote is honored at checkout. The customer receipt and internal benefit ledger should expose the same applied value without leaking another account's entitlement.

6. Test Instamart Inventory and Fulfillment

Q: How would you test overselling in Instamart?

Create a low-stock SKU and submit concurrent carts against the same dark-store inventory pool. Verify that reservations are atomic at the documented boundary, failed buyers receive a clear outcome, and abandoned reservations expire safely. Inventory, picking, customer, and refund states must reconcile even if an event or payment response arrives late.

Q: How would you test substitutions for an unavailable item?

Clarify whether the user may allow alternatives, approve a specific replacement, set a price limit, or require a refund. Cover cheaper and costlier substitutes, allergy-sensitive categories, quantity differences, timeout waiting for consent, and an original item found after substitution. The final charge and invoice must reflect what was actually fulfilled, not the original basket snapshot.

Q: What freshness and expiry cases matter?

Use controlled products around minimum remaining shelf-life rules, date boundaries, damaged packaging, temperature-sensitive handling, and lot recalls. Verify picker guidance, rejection or replacement, customer-visible information, complaint evidence, and traceability to a batch where the domain requires it. Do not rely on OCR alone for critical dates without testing confidence thresholds and human fallback.

Q: How would you test picking and packing accuracy?

Generate baskets with visually similar SKUs, multiple quantities, fragile goods, weighted items, and separate bags. Compare scan events and packed identifiers with the accepted order, then challenge duplicate scans, missed scans, device offline mode, and label reassignment. A packing-complete status is valid only when mandatory discrepancies have a recorded resolution.

Q: How do partial fulfillment and partial refund interact?

Calculate the fulfilled item subtotal, item-level discounts, order-level discount allocation, fees, taxes, and the payment adjustment under explicit business rules. Test one missing unit from a multi-quantity line, several unavailable lines, a substitute, and a later quality refund. The customer total, merchant or dark-store record, payment ledger, and support view should converge without allowing the same unit to be refunded twice.

7. Test APIs, Events, and Data Consistency

Q: How would you test an order-creation API?

Validate authentication, authorization, schema, item ownership, quote freshness, idempotency, rate limits, and documented status codes before checking the happy response. Assert business invariants in persistent state or observable downstream contracts rather than accepting any 2xx response as success. Practice deeper service reasoning with these scenario-based API testing questions.

Q: What does eventual consistency change in your tests?

Replace fixed sleeps with polling bounded by the documented convergence window and fail with the last observed state. Distinguish an authoritative write model from search, tracking, notification, or support projections so assertions target the correct source. Also test the failure path where convergence never occurs, because unlimited retries hide production defects.

Q: How would you test event consumers safely?

Publish versioned fixture events to an isolated topic or invoke the consumer through a local harness, then assert idempotent side effects, ordering assumptions, dead-letter behavior, and retry limits. Include duplicate, late, missing-field, unknown-version, and poison-message cases. Correlation identifiers should connect the input event to logs and the resulting domain record without exposing sensitive payloads.

Q: An API returns 200 but the order does not progress. What do you inspect?

First determine what the 200 contract promises, since it may mean accepted for processing rather than completed. Follow the request ID through validation, persistence, outbox or event publication, consumer processing, and state projection, comparing a good request with the failing one. Report the broken contract precisely, such as a missing event after acknowledged persistence, instead of labeling the entire backend down.

Q: How would you use SQL during an investigation?

Write read-only, narrowly scoped queries against approved non-production data or authorized diagnostic views. Join order state, transition history, and payment records to test one hypothesis at a time, while preserving timestamps and correlation IDs. The SQL interview questions for testers can help you practice joins, grouping, and safe evidence gathering.

This PostgreSQL example uses only in-memory values and reports duplicate captures. Save it as payment-audit.sql and run psql -f payment-audit.sql.

WITH payments(order_id, payment_id, status, amount_paise) AS (
  VALUES
    ('o-101', 'p-1', 'CAPTURED', 45900),
    ('o-101', 'p-2', 'CAPTURED', 45900),
    ('o-102', 'p-3', 'FAILED', 29900)
)
SELECT
  order_id,
  COUNT(*) FILTER (WHERE status = 'CAPTURED') AS capture_count,
  SUM(amount_paise) FILTER (WHERE status = 'CAPTURED') AS captured_paise
FROM payments
GROUP BY order_id
HAVING COUNT(*) FILTER (WHERE status = 'CAPTURED') > 1;

Verification should return only o-101 with capture_count equal to 2. In a real system, table names, authorization, currency handling, and legitimate split-payment rules must come from the owned schema and contract.

8. Test Mobile, Accessibility, and Localization

Q: How would you test ordering on a weak mobile network?

Shape bandwidth, latency, packet loss, offline intervals, and connection changes around search, cart, payment, and tracking actions. Verify visible progress, bounded retries, preserved input, idempotent submission, and recovery after app restart. Never infer failure only from a spinner, because the server may have completed the order while the response was lost.

Q: How would you test push notifications and deep links?

Create a matrix of app foreground, background, terminated, logged out, expired session, and multiple-account states. Each notification should open the intended order only after authorization, handle an old or completed order gracefully, and avoid exposing sensitive details on a locked screen. Test duplicate and out-of-order notifications because transport delivery is not a reliable business sequence.

Q: What accessibility checks matter in checkout and tracking?

Complete the critical flow with keyboard or switch input, inspect accessible names and focus movement, and verify that validation errors and changing order status are announced meaningfully. Check zoom, reflow, contrast, touch-target usability, reduced motion, and supported screen readers on representative devices. Automated scanners provide coverage for detectable rules but cannot prove that a blind user understands a price change or delivery update.

Q: How do you choose a mobile device matrix?

Combine supported OS versions, actual usage distribution, device capability, screen size, vendor differences, and the feature's change risk. Keep a small per-change matrix for fast feedback and a broader scheduled matrix for compatibility, then add a device when telemetry or a defect justifies it. Use the mobile testing roadmap to strengthen lifecycle, permission, and network preparation.

Q: What localization cases are relevant in India?

Test supported languages, long text, mixed scripts, address formats, phone input, currency display, decimal handling, local time, and region-specific availability. Search should handle configured transliteration and synonyms without assuming every language uses the same tokenization. Verify that translated errors preserve the action a customer must take, especially during payment or delivery recovery.

9. Demonstrate Automation, Coding, and Performance Judgment

Q: What should be automated first for a Swiggy-style product?

Automate stable, repeated, decision-critical invariants at the lowest trustworthy layer. Price calculations, eligibility, permissions, and state transitions fit unit or service tests; a narrow set of browser and mobile journeys proves integration. Keep volatile visual exploration and new failure discovery with skilled humans until a repeated check has a clear oracle and maintenance value.

Q: Show a browser test for cart-total integrity.

Use controlled markup or an approved test environment, user-facing locators, and an independent calculation oracle. The example below proves that the displayed total equals item, delivery, and tax components, but it does not prove backend pricing, payment capture, or all currency rules. Save it as tests/cart-total.spec.ts in a Playwright project.

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

test('cart total equals its displayed components', async ({ page }) => {
  await page.setContent(`
    <main>
      <h1>Review cart</h1>
      <dl>
        <dt>Items</dt><dd data-amount="items">420.00</dd>
        <dt>Delivery</dt><dd data-amount="delivery">35.00</dd>
        <dt>Tax</dt><dd data-amount="tax">21.00</dd>
        <dt>Total</dt><dd data-amount="total">476.00</dd>
      </dl>
      <button>Place order</button>
    </main>
  `);

  const amount = async (name: string) =>
    Number(await page.locator('[data-amount="' + name + '"]').textContent());

  const expected =
    (await amount('items')) + (await amount('delivery')) + (await amount('tax'));

  await expect(page.getByRole('heading', { name: 'Review cart' })).toBeVisible();
  expect(await amount('total')).toBeCloseTo(expected, 2);
  await expect(page.getByRole('button', { name: 'Place order' })).toBeEnabled();
});

Run npx playwright test tests/cart-total.spec.ts and expect one passed test. For more coding practice, use Playwright interview questions for experienced testers.

Q: How do you diagnose a flaky end-to-end test?

Preserve the trace, network log, console, screenshot, test data, environment state, and timestamps from the first failure. Classify product race, test synchronization, shared data, dependency instability, and environment capacity before changing the assertion. A temporary quarantine needs an owner, linked defect, limited scope, and removal date so it does not become permanent silence.

Q: How would you performance-test a lunch-hour surge?

Derive the workload from approved traffic models across discovery, menu reads, cart writes, order placement, tracking, and partner updates instead of multiplying one endpoint. Define latency, error, saturation, and business-success thresholds, then use gradual load, spikes, soak, and recovery tests in an authorized environment. Protect downstream payment and notification providers with stubs or agreed limits, and correlate results with resource and queue telemetry.

Q: How would you answer a state-transition coding question?

State legal transitions first, keep the function deterministic, and test both accepted and rejected moves. The following Node 22 example is deliberately small enough to discuss during an interview while still being runnable. Save it as order-state.test.mjs.

import test from 'node:test';
import assert from 'node:assert/strict';

const allowed = new Map([
  ['PLACED', new Set(['ACCEPTED', 'CANCELED'])],
  ['ACCEPTED', new Set(['PREPARING', 'CANCELED'])],
  ['PREPARING', new Set(['PICKED_UP'])],
  ['PICKED_UP', new Set(['DELIVERED'])],
  ['DELIVERED', new Set()],
  ['CANCELED', new Set()]
]);

function transition(current, next) {
  if (!allowed.get(current)?.has(next)) {
    throw new Error('illegal transition: ' + current + ' -> ' + next);
  }
  return next;
}

test('a prepared order can be picked up', () => {
  assert.equal(transition('PREPARING', 'PICKED_UP'), 'PICKED_UP');
});

test('a delivered order cannot return to preparing', () => {
  assert.throws(
    () => transition('DELIVERED', 'PREPARING'),
    /illegal transition/
  );
});

Verify with node --test order-state.test.mjs and expect two passing tests. During discussion, note that production transitions also need actor authorization, version checks, persistence, audit history, and compensation rules.

10. Swiggy QA Interview Questions: Behavioral Preparation

Q: How should you describe an escaped defect?

Choose a real incident and explain the customer impact, containment, detection gap, and your personal decision without blaming another team. Identify the mistaken assumption and the smallest durable prevention, such as a contract test, canary signal, or acceptance-rule change. Report the measured follow-up honestly, including anything that remained uncertain.

Q: What if an engineer disagrees with your release concern?

Restate the disputed invariant, affected users, evidence quality, exposure, and recovery options rather than appealing to the QA title. Invite a competing explanation and run the fastest safe check that distinguishes the hypotheses. If material risk remains, document it and escalate through the agreed decision path while preserving a respectful working relationship.

Q: How would you present a quality improvement project?

Start with the feedback problem, such as slow order regression or unreliable payment tests, and show the baseline source. Explain the engineering change, adoption work, and guardrails you owned, then connect the result to faster or safer decisions instead of test-count growth. Be ready to discuss maintenance cost, a rejected alternative, and what you would redesign now.

Q: Why do you want to work on quality at Swiggy?

Connect your answer to the complexity you genuinely want to solve: coordinated marketplace state, mobile reliability, rapid fulfillment, or customer trust under time pressure. Tie that interest to one relevant accomplishment and one capability you want to deepen. Avoid generic praise or unsupported claims about internal culture, since thoughtful product reasoning is more credible than a rehearsed brand statement.

How Interviewers Grade Your Answers

A senior answer does not need the most test cases. It needs a precise model, an explicit priority, a feasible evidence plan, and a clear statement of what remains unknown. Practice aloud on the QAJobFit interview practice surface, then trim any part that does not change the testing or release decision.

Interview Questions and Answers

Q: How would you test a lunch-hour traffic spike that affects only checkout?

Compare discovery and cart health with checkout latency, errors, queue depth, dependency timing, and order-success rate over the same interval. Reproduce the traffic mix in an authorized environment while controlling payment integrations and preserving correlation IDs. The release response depends on whether admission control, graceful degradation, or rollback can protect order integrity.

Q: A menu update is visible to the restaurant but not the customer. What is your path?

Verify the merchant write and version first, then follow publication, cache invalidation, search or menu projection, CDN behavior, and client refresh. Measure the delay against the consistency contract before declaring failure. A regression should use a unique item and wait on version convergence rather than sleep for an arbitrary duration.

Q: Tracking says delivered but the customer has no order. How do you triage it?

Treat it as a high-impact handoff discrepancy and preserve the order, assignment, proof, contact, and location evidence under privacy controls. Establish whether completion came from an authorized actor and whether the consumer view reflects the authoritative state. Contain repeat exposure while support and operations follow the approved resolution process.

Q: How do you assign severity to a promotion calculation defect?

Assess financial loss, customer population, frequency, legal or advertising implications, workaround, and reversibility. A one-paise display rounding issue and a coupon that overcharges every eligible basket do not deserve the same severity. State both severity and release urgency because a contained defect can be serious without requiring the same immediate action.

Q: How would you test an experiment that changes restaurant ranking?

Validate deterministic assignment, mutual exclusivity, exposure logging, guardrail events, and fallback before judging relevance. Ensure filters and safety eligibility remain invariant in every variant, and prevent automated tests from depending on an uncontrolled cohort. Analysis should check sample integrity and operational metrics alongside the intended product outcome.

Q: What privacy checks belong in delivery tracking?

Verify least-privilege access to names, phone masking, addresses, live location, delivery instructions, and support history for each actor and order phase. Test direct-object reference attempts, expired links, account switching, screenshots or logs, notification previews, and post-delivery retention behavior. Use synthetic identities so security validation does not spread personal data through test systems.

Q: How would you test ordering through a conversational AI channel?

Treat the channel as another client of catalog, cart, authorization, payment, and tracking contracts. Test ambiguous intent, stale availability, tool-call retries, malicious product text, account boundaries, explicit purchase confirmation, and a handoff to the native experience. The assistant must never invent a successful order when the authoritative order service rejected or timed out.

Q: What would you do in your first month on a Swiggy QA team?

Learn the owned customer journeys, state models, release path, incident history, test environments, and operational dashboards before proposing a rewrite. Pair with engineering, product, support, and operations to identify one costly feedback gap backed by evidence. Deliver a small improvement that strengthens signal while building the context for broader changes.

Common Mistakes

• Memorizing an unofficial interview loop and presenting it as a company guarantee.
• Treating food delivery as a simple e-commerce checkout while ignoring restaurants, delivery partners, location, and time-sensitive state.
• Listing positive and negative cases without an oracle, priority, controlled data, or recovery expectation.
• Assuming a 2xx API response proves payment, event publication, fulfillment, and customer visibility.
• Using fixed sleeps for eventual consistency or rerunning flaky tests until they pass.
• Proposing tests against public production, real customer data, or live payment methods without authorization.
• Hard-coding exact ETA, ranking, or dispatch output when the public contract supports property-based assertions instead.
• Claiming one UI script covers accessibility, performance, localization, and service correctness.
• Inventing impact numbers, internal architecture, or Swiggy-specific hiring stages.
• Giving behavioral stories with no personal action, dissent, measurement, or lasting prevention.

Use manual testing scenario practice to improve prioritization when the prompt is ambiguous. If your resume does not yet show the same evidence, compare it with the role on the resume analysis dashboard and revise only claims you can substantiate.

Conclusion

Strong preparation for swiggy qa interview questions combines product understanding with disciplined engineering judgment. Practice one food-delivery flow and one Instamart flow end to end, including state, money, APIs, mobile behavior, failures, observability, and a release recommendation.

Do not memorize all 56 answers word for word. Rehearse the reasoning until you can adapt it to a new constraint, explain the evidence you would collect, and state clearly where the system contract or recruiter guidance is still needed.

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)