Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Lenskart hiring for Software Testing roles
Lenskart is an Indian eyewear company that sells spectacles, sunglasses and contact lenses through its website, app and a large chain of retail stores. It combines online shopping with home eye tests, virtual try-on technology and in-house manufacturing. It hires software engineers, data analysts, product managers and retail and operations roles across its technology and business teams.
For Software Testing roles, this Lenskart practice set focuses most on Test Case Design (6), Agile, SQL and API Testing (6), Manual Testing Basics (5), Bug Life Cycle and Jira (5). It has 2 easy, 31 medium, 7 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, Bengaluru
Lenskart Software Testing interview process
Online coding or analytics assessment
Technical round
Case or managerial round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for LenskartStart 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
The build arrived three days late but the release date has not moved. How do you prioritise execution?
Rank test cases by business risk and usage: critical flows like login, payment and data saving first, then new features, then high-risk regression from past defects, and cosmetic checks last. Run smoke testing immediately to avoid wasting time on a broken build. Share the reduced plan with the lead and product owner so they know what will not be covered, and get agreement on the remaining risk.
02
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.
03
A user updates their phone number in the app, but the old number still appears in reports. What do you check?
First query the main users table to see whether the update was saved. If it was, check where the report reads from: a view, a reporting copy, a cache or a nightly ETL table. The report may simply be stale until the next refresh, which may be by design. If the main table still has the old value, check the API request, the update query and any errors in logs, then log a bug with both query results.
Use the platform's sandbox or test accounts so no real money is charged. Test a successful purchase, cancellation, payment failure, pending payment, refund and restoring purchases on a new device. For subscriptions, test free trial, renewal, upgrade, downgrade, expiry and grace period, often with shortened test durations. Verify the server records the purchase and unlocks features, and that killing the app mid-purchase does not lose it.
06
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
07
What do testers look for during a requirement review?
Check that each requirement is clear, complete, consistent and testable. Look for vague words like fast or user-friendly, missing error handling, undefined limits, conflicting rules and missing roles or states. For each requirement ask how you would test it and what the expected result is. Record questions in a review log and get answers from the business analyst before writing test cases, so ambiguity does not turn into defects later.
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.
11
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.
12
How do you test API error handling for invalid input?
Send requests with missing required fields, wrong data types, values beyond limits, invalid formats such as a bad email, unknown fields and an empty or malformed JSON body. The API should return a 4xx code such as 400 or 422, a clear error message that names the field, and no stack trace or database details. Also check that nothing was partly saved in the database after the failed request.
13
What is the pesticide paradox and how do you counter it?
The pesticide paradox says that if you run the same tests again and again, they stop finding new defects, just as pests become resistant to the same pesticide. To counter it, regularly review and update test cases, add new scenarios from recent production bugs, vary test data, and mix scripted runs with exploratory sessions. Rotating testers across modules also brings fresh eyes and new ideas.
14
Your backlog has 200 low-priority bugs and it is becoming unmanageable. How do you handle it?
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.
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.
A flaky test passes and fails on the same code without any change. Common causes are timing problems such as fixed sleeps or missing waits, tests depending on each other or on shared data, unstable locators, animations, third-party services, test order in parallel runs and environment issues like slow servers. Flaky tests destroy trust in the suite, so teams quarantine them, find the root cause and fix it rather than adding retries forever.
SELECT c.id, c.name, COUNT(o.id) AS order_count
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.order_date >= CURRENT_DATE - INTERVAL '30' DAY
GROUP BY c.id, c.name
HAVING COUNT(o.id) > 3
ORDER BY order_count DESC;
A test oracle is the source you use to decide whether a test result is correct, that is, the expected result. It can be a requirement document, a user story, an older version of the system, a calculation in a spreadsheet, a domain expert or common sense. For example, when testing a tax calculator, the official tax slab table is the oracle. Without a reliable oracle, you cannot say a test passed or failed.
21
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.
22
Leadership asks whether test automation is worth the investment for your project. How do you estimate the ROI?
Compare cost and savings over time. Cost includes building scripts, framework setup, tools, CI infrastructure and ongoing maintenance, often a large share of total effort. Savings include manual execution hours saved per run multiplied by runs per year, earlier bug detection and faster releases. For example, a 40-hour manual regression run every two weeks saves about 1000 hours a year. Tests that run rarely or break often may never pay back.
23
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.
Shift-left means starting testing activities earlier in the life cycle: reviewing requirements, joining design discussions and writing tests before code is complete. A defect found in requirements may cost a short conversation to fix, while the same defect found in production may need a hotfix, data correction and customer support. Testers shift left by asking questions in grooming, defining acceptance criteria and reviewing designs.
25
SQL: verify that row counts and totals match between a source table and a target table after a data load.
-- Compare counts and sums side by side; both columns must match
SELECT
(SELECT COUNT(*) FROM staging_orders) AS src_count,
(SELECT COUNT(*) FROM dw_orders) AS tgt_count,
(SELECT SUM(amount) FROM staging_orders) AS src_amount,
(SELECT SUM(amount) FROM dw_orders) AS tgt_amount;
26
A requirement says the page should load fast. How do you turn it into a test case?
The word fast is not testable, so ask the product owner for a measurable target, for example the page loads within 3 seconds on a 4G network for 95 percent of requests. Agree on the conditions: device, network, data size and whether it is first load or cached. Then write the test with those conditions and expected time. Record the agreed number in the story so the expected result is not open to opinion.
27
A training portal is adding recorded video lessons and podcasts. What accessibility checks do you run?
Check that prerecorded videos have accurate, synchronised captions, not just auto-generated ones with errors, and that audio-only content like podcasts has a transcript. Important visual information that is not spoken should have audio description or be covered in the transcript. Media should not autoplay with sound, and player controls must work by keyboard and be announced by screen readers. Also check that nothing flashes more than three times per second.
28
What is a performance bottleneck and where do bottlenecks usually occur?
A bottleneck is the component that limits the whole system's performance, so adding load beyond it increases response times or errors. Common places are slow database queries or missing indexes, too few database connections or threads, CPU or memory limits on servers, slow third-party APIs, large uncompressed files and chatty code that makes many small calls. Monitoring each layer during a test shows which resource saturates first.
Find the documented limit, for example 100 requests per minute per key. Send requests just below and above the limit and check that extra requests get 429 Too Many Requests with a Retry-After header. Verify the counter resets after the window and that limits apply per key or per IP as designed. Check that one user hitting the limit does not block others, and that normal traffic is not throttled.
A keyboard trap is when focus moves into a component and the user cannot move out using the keyboard, for example an embedded video player or date picker that captures Tab forever. Mouse users never notice, but keyboard and screen reader users are stuck and must reload the page. It fails WCAG criterion 2.1.2. Test every widget by tabbing in and out, and check that Escape closes popups and returns focus.
List conditions and actions in a table and cover every combination of conditions (rules) — ideal for business rules like loan approval: salary > X AND credit score > Y → approve.
33
An automated test keeps failing because an element's ID is generated differently on every build. What do you do?
Stop using the dynamic ID. Look for a stable alternative: the element's role and visible name, its label, a stable attribute, or a relative locator based on a nearby fixed element. The best long-term fix is asking developers to add a data-testid attribute. Avoid partial matches on random strings, which can break again. Then update the locator in the page object so every test using it is fixed at once.
34
How do you handle a bug found late in a release cycle?
UI automation drives the browser or app like a user, so it checks the full experience but is slower and breaks more often with design changes. API automation sends requests directly to services and checks responses, which is much faster, more stable and can run before the UI exists. API tests give faster feedback, so teams place most business rule checks at the API level and keep a smaller set of UI journeys.
Collect exact details: user, time, device, browser and request IDs. Compare production with QA for configuration, feature flags, data volume, third-party integrations, versions and caching. Ask for production logs and error traces through the support or dev team. Try to reproduce in QA with production-like data or in a staging environment. Once found, add a test for the gap and fix the environment difference if one caused it.
38
When should you reopen a bug and when should you log a new one?
Reopen the bug when the same issue, with the same steps and expected result, still fails after the fix. Log a new bug when the fix works but a different problem appears, even in the same screen, or when the original bug has already been closed in a past release. Link the new bug to the old one. Mixing different problems in one reopened ticket confuses tracking and metrics.
Verify reset with a registered email sends a link. Verify an unregistered email shows a generic message without revealing whether the account exists. Check the link opens the reset page and expires after the defined time. Check the link works only once. Validate new password rules and that confirm password must match. Verify login works with the new password and fails with the old one. Check resend limits and that other sessions are logged out.
40
The product team wants to skip UAT to ship faster. What do you advise?
Explain the risk: system testing proves the software matches the specification, but only users confirm it fits real business work. Propose a lighter option instead of none: a short, focused UAT on critical flows with two or three key users, or a staged rollout to a small user group with monitoring and quick rollback. If they still skip it, record the decision and the accepted risks with the product owner.
Tips to crack the Lenskart Software Testing interview
For tech roles, practise DSA and backend basics, and be ready to discuss APIs, databases and scaling e-commerce systems.
For analyst roles, revise SQL, Excel and metrics like conversion rate, average order value and store performance.
Understand Lenskart's omnichannel model of online plus offline stores to answer business and product questions with context.
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; Lenskart interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Lenskart Software Testing interview?
Candidates usually go through 4 stages: Online coding or analytics assessment; Technical round; Case or managerial round; HR 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 Lenskart Software Testing interview?
This practice set leans on Test Case Design (6), Agile, SQL and API Testing (6), Manual Testing Basics (5), Bug Life Cycle and Jira (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Lenskart interviewers ask you to walk through real work.
Are these the exact questions asked at Lenskart?
No. These are curated practice questions that match the skills and difficulty usually tested in e-commerce & consumer tech interviews like Lenskart's. They are not a leaked or verified list of past questions.
Where does Lenskart hire Software Testing professionals in India?
Lenskart has large teams in Gurugram, Bengaluru. Openings and locations change often, so check the Lenskart careers page and filter by city and experience.