Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Blinkit hiring for Software Testing roles
Blinkit is an Indian quick commerce company, owned by Eternal (formerly Zomato), that delivers groceries and everyday essentials within minutes. It was earlier known as Grofers and runs a network of dark stores in many cities. It hires software engineers, data analysts, product managers, supply chain and operations professionals to run its fast delivery platform.
For Software Testing roles, this Blinkit practice set focuses most on Bug Life Cycle and Jira (6), Database Testing (5), Testing Types (5), Test Case Design (5). It has 1 easy, 31 medium, 8 hard questions, so you can start easy and work up to the harder ones.
Company type
E-commerce & consumer tech
Headquarters
Gurugram, India
Main India offices
Gurugram
Blinkit Software Testing interview process
Online coding or analytics assessment
Technical round 1
Technical round 2 (design or case)
Hiring manager round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for BlinkitStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
How do you test an application when requirements change frequently?
/* CSS selector using the test id */
button[data-testid='login-btn']
// XPath using the test id
//button[@data-testid='login-btn']
// XPath using the visible text
//button[normalize-space()='Login']
04
What is idempotency in APIs and how do you test it?
An operation is idempotent if repeating the same request gives the same result as doing it once. GET, PUT and DELETE should be idempotent; POST usually is not. To test, send the same request several times and check the server state does not change after the first call. For payments, check that retrying with the same idempotency key does not create a second charge, which protects users during network retries.
JSON schema validation checks that a response has the expected structure: required fields are present, data types are correct, formats like email or date are valid and no unexpected fields appear. Instead of checking only one value, it protects against contract changes that break the app. In Postman you can validate a response against a schema in the test script, and run it on every request in a collection.
06
Write a simple Playwright test in TypeScript that logs in and checks the dashboard heading.
Run a backlog grooming session with the product owner. Close bugs that are obsolete, no longer reproducible or for retired features. Merge duplicates. Group the rest by module and user impact, and ask whether a few related bugs can be fixed together as one story. Agree to reserve a small share of each sprint for bug fixes. Set an ageing rule, for example review any bug older than 90 days.
08
A report shows duplicate rows after a new release. How do you investigate in the database?
Run the report query with GROUP BY on the business key and HAVING COUNT(*) > 1 to find which records repeat. Then check whether the duplicates exist in the base table or are created by the query, usually a new join to a one-to-many table such as addresses. Compare the query before and after the release. Include the duplicate keys, the count and the suspected join in the bug report.
09
Search works fine in QA but is very slow in production. Could a missing database index be the reason, and how do you check?
Yes, very likely. An index lets the database find rows quickly, like the index of a book. With a small QA table, a full table scan is still fast, but with millions of production rows it becomes slow. Compare indexes on the searched columns in both environments and ask a developer to check the query plan. Test key queries on production-size data in staging, and include data volume in future performance checks.
Check that the app asks for permission only when the feature is used, with a clear reason. Test allow, deny, and deny with do not ask again. When denied, the app must not crash and should explain how to enable it in settings. Revoke permission from settings while the app is in background and return. Test allow only once or only while using the app options on newer OS versions.
12
Tell me about a time you designed tests for a feature with unclear requirements.
Model answer: Situation: I got a story for 'flexible EMI options' with only one line of description. Task: test it within the sprint. Action: I listed my assumptions on tenure, interest and rounding, reviewed them with the product owner in a 15-minute call, and wrote test cases only after we agreed. Result: three rules were changed before coding finished, and the feature passed UAT without rework.
First read what the trigger should do and when it fires, such as AFTER UPDATE on the salary column writing a row to an audit table. Then perform the event that should fire it and query the target table to confirm the expected row and values. Also perform events that should not fire it and confirm nothing happens. Check multi-row updates, NULL values and rollback: if the main statement fails, the trigger's changes must not remain.
14
SQL: check that no user has more than one active subscription.
-- Business rule: at most one ACTIVE subscription per user
SELECT user_id, COUNT(*) AS active_count
FROM subscriptions
WHERE status = 'ACTIVE'
GROUP BY user_id
HAVING COUNT(*) > 1;
-- Expected result: no rows
In sprint planning, review each story's acceptance criteria and estimate test effort, including test data and regression. Write test cases in the first days while development starts. Ask for early builds so testing is spread across the sprint, not crowded at the end. Keep time for regression and bug retesting in the last two or three days. Track progress on the board and raise risks in stand-up.
Data mapping testing checks that each field on a screen, file or API goes to the correct table and column with the correct format. For example, the Date of Birth field on the signup form must land in users.dob as a date, and the State dropdown must store the state code, not the label. Testers use a mapping document, enter known values in the UI or API and query the database to compare field by field.
Open the same record in two sessions, change different fields and save both, then change the same field and save both. Check the database to see which value won and whether data was silently lost. A good design uses optimistic locking, where the second save fails with a 'record changed, please reload' message because a version column changed. Also repeat with API calls fired together to catch timing issues the UI hides.
A bug bash is a short, time-boxed session where people from across the team, including developers, product and support, test the product together to find as many issues as possible before a release. To run one, share a build, scope and test accounts, assign focus areas, give a simple bug template and a shared board, then triage findings at the end. It brings fresh eyes and finds usability issues formal tests miss.
20
A developer asks you to test a feature that has no acceptance criteria. How do you proceed?
First ask the product owner or business analyst for the expected behaviour and write down the answers as draft acceptance criteria. Meanwhile, explore the feature, compare it with similar existing features and list assumptions. Share the assumptions in the story so everyone agrees before you sign off. Raise the missing criteria in the next refinement so future stories are not picked up without them.
21
Tell me about a disagreement with a developer about a bug's severity.
Model answer: Situation: I logged a bug where the invoice PDF showed the wrong GST number, and the developer marked it minor because the screen value was correct. Task: get the right priority. Action: I explained that customers use the PDF for tax filing and showed the requirement. Result: the product owner agreed it was major, it was fixed before release, and we added PDF checks to regression.
A development model where each development phase has a matching testing phase, such as requirements with acceptance tests and design with integration tests.
23
A web app gets slower the longer a user keeps it open. How do you check for a memory leak as a manual tester?
A memory leak happens when an application keeps holding memory it no longer needs, so usage grows the longer it runs. A manual tester may notice the app getting slower over a long session, a browser tab using more and more memory in Task Manager or the browser's memory panel, or a mobile app crashing after repeatedly opening and closing a screen. Report the steps, duration and memory readings over time.
Valid keyword, partial match, no results, special characters, very long text, empty search, case sensitivity, spelling errors, suggestions and speed of results.
26
How do specification-based techniques differ from experience-based techniques?
Specification-based (black box) techniques derive tests systematically from requirements: equivalence partitioning, boundary values, decision tables, state transitions and use cases. They give measurable coverage. Experience-based techniques rely on the tester's knowledge and intuition: error guessing, exploratory testing and checklist-based testing. They are good at finding defects the specification never mentioned. Strong testers use specification techniques for coverage and experience techniques to fill the gaps.
27
What is the difference between smoke testing in CI and full regression?
Ad hoc testing is informal testing without test cases, done by a tester who understands the application and tries likely weak areas based on experience. Monkey testing gives random inputs and actions, often without knowing the application, to see if it crashes. Ad hoc testing is targeted and good at finding logical bugs, while monkey testing is good at finding stability issues and is often automated.
29
A screen reader announces 'button, button, button' on a toolbar. What is the bug and how do you report it?
The toolbar uses icon-only buttons without accessible names, so users hear the role but not the purpose. Report it with the page, the screen reader and browser versions, the exact announcement and the expected one, such as 'Bold, toggle button, not pressed'. Reference WCAG 4.1.2 Name, Role, Value. The fix is an aria-label or visually hidden text on each button, plus a tooltip that also helps sighted users.
30
How do you test session management in a web application?
Check that a new session ID is created after login, and that the session expires after the defined idle time. Verify logout invalidates the session on the server, so pressing back or reusing the old cookie does not work. Check that cookies use Secure, HttpOnly and SameSite flags. Test concurrent logins if they are limited, and that changing the password ends other sessions. Session IDs must not appear in URLs.
31
Analytics show many users drop off at step three of a five-step checkout. How do you investigate the usability problem?
First look at what step three asks: maybe address entry, a surprise delivery charge or forced signup. Check analytics for errors, rage clicks and time spent, and watch session recordings if available. Test it yourself on mobile and slow networks. Then run a quick usability test with five users on that step. Present evidence with likely causes and options, such as guest checkout or showing charges earlier, and measure after the change.
32
How do you capture logs from an Android device for a bug report?
Enable developer options and USB debugging, connect the phone and confirm it is visible with adb devices. Clear old logs with adb logcat -c, reproduce the bug, then save logs with adb logcat -d > crash_log.txt, filtering by the app package or error level if needed. For a crash, search for FATAL EXCEPTION. Attach the log, device model, OS version, app version and a screen recording to the bug.
33
How do you design test cases for role-based access with admin, editor and viewer roles?
Build a permission matrix with roles as rows and actions as columns, such as create, edit, delete, publish and view, marking allowed or denied from the requirement. Write a positive test for each allowed cell and a negative test for each denied one. Test through the UI and also call the APIs directly, because hidden buttons are not security. Check role changes take effect immediately and that users cannot access other users' data by changing IDs.
34
A bug fix was made in the payment module. How do you decide the regression scope?
Ask the developer which code, services and database tables changed. Map them to impacted flows: all payment methods, refunds, partial payments, failed payment retries, invoices and order status updates. Add high-risk areas from past defects and anything that calls the same service. Run full payment regression because the business risk is high, plus a smoke test of the rest of the application before release.
Set browser zoom to 200 percent and check that all text is readable and no content or buttons are cut off. Then zoom to 400 percent, or use a 1280 pixel wide window, which gives a 320 CSS pixel viewport; content should reflow into one column without horizontal scrolling, except for things like data tables and maps. Also increase text spacing and the operating system font size to check that labels do not overlap.
39
A feature passed all your test cases, but users say it is confusing. What went wrong?
The tests verified the specification but did not validate the user experience. The test cases probably checked only functional outcomes and missed usability: unclear labels, too many steps or poor error messages. Next time, add usability heuristics to reviews, do exploratory sessions as a real user persona and involve users in UAT or demos. Log the current feedback as improvement items with clear examples.
40
Your automated tests pass one by one but fail randomly when run in parallel. How do you fix the test data so tests are independent?
Each test should create the data it needs, usually through an API or database helper, use unique values such as an email with a timestamp, and clean up afterwards. Avoid tests that depend on data made by another test or on a shared account other tests change. For fixed reference data, seed it before the suite runs. Independent data allows tests to run in parallel and in any order without random failures.
Tips to crack the Blinkit Software Testing interview
Think about quick commerce challenges such as dark store inventory, demand forecasting and delivery time before case discussions.
Practise SQL with time-based analysis and metrics like order volume, delivery time and fill rate for analyst roles.
For engineering roles, revise DSA and design of real-time systems like order tracking and rider assignment.
Keep a one-minute story ready for every project on your CV: problem, your part, tools, result.
Practise the hard questions on this page aloud; Blinkit interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Blinkit Software Testing interview?
Candidates usually go through 4 stages: Online coding or analytics assessment; Technical round 1; Technical round 2 (design or case); Hiring manager round. The exact rounds change with the role, team, location and your experience, so confirm the process with the recruiter.
Which topics should I prepare for the Blinkit Software Testing interview?
This practice set leans on Bug Life Cycle and Jira (6), Database Testing (5), Testing Types (5), Test Case Design (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Blinkit interviewers ask you to walk through real work.
Are these the exact questions asked at Blinkit?
No. These are curated practice questions that match the skills and difficulty usually tested in e-commerce & consumer tech interviews like Blinkit's. They are not a leaked or verified list of past questions.
Where does Blinkit hire Software Testing professionals in India?
Blinkit has large teams in Gurugram. Openings and locations change often, so check the Blinkit careers page and filter by city and experience.