Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Nykaa hiring for Software Testing roles
Nykaa, operated by FSN E-Commerce Ventures, is an Indian beauty, personal care and fashion e-commerce company with both online and offline stores. Its technology and analytics teams work on search, recommendations, marketing, inventory and customer analytics. It hires for software engineers, SDETs, business analysts and data analysts.
For Software Testing roles, this Nykaa practice set focuses most on Agile, SQL and API Testing (10), Test Case Design (6), Bug Life Cycle and Jira (4), STLC and Test Planning (4). It has 2 easy, 27 medium, 11 hard questions, so you can start easy and work up to the harder ones.
Company type
E-commerce & consumer tech
Headquarters
Mumbai, India
Main India offices
Mumbai, Gurugram, Bengaluru
Nykaa Software Testing interview process
Online assessment or assignment
Technical or case round
Hiring manager round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for NykaaStart 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.
Not necessarily. Automated tools catch only a part of WCAG issues, such as missing labels and contrast. A clean scan still needs manual checks: keyboard-only navigation, focus order, a screen reader pass, meaningful alt text and link names, error handling, zoom and reflow and dynamic content. Report the result as 'no automated violations found' and add the manual checklist outcome before claiming conformance.
05
How would you set up a testing approach for a new Agile team with no QA process?
Start small. Agree on a definition of ready and definition of done that include acceptance criteria and testing. Join refinement and run Three Amigos for every story. Set up a simple bug workflow and severity guide in the tracker, a shared test case repository and a smoke checklist for each build. Then add API checks and automated regression for stable flows. Review what works in each retrospective and adjust.
06
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.
Test enabling biometrics in app settings after a password login. Verify login with a registered fingerprint or face, and failure with an unregistered one, falling back to PIN or password after the allowed attempts. Remove or add a fingerprint in device settings and check the app asks for re-authentication. Test devices without biometric hardware, disabled biometrics and app behaviour after an OS update or reinstall.
09
How do you decide which automated tests run on every pull request and which run nightly?
Pull request checks must be fast, usually under ten to fifteen minutes, and highly reliable, so they include unit tests, API tests for changed services and a small UI smoke set of critical flows. The full UI regression, cross-browser runs, long data-driven suites and performance checks run nightly or before release. Tag tests by suite, measure run times and flakiness, and move tests between suites based on value and speed.
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.
11
Tell me about a time you had to push back on a release date.
Model answer: Situation: a loan app release was planned on Friday, but the EMI schedule showed wrong values for some tenures. Task: give an honest recommendation. Action: I presented the failing cases, the number of affected customers and the compliance risk in the go or no-go meeting, and proposed a three-day delay with a fix plan. Result: management agreed, the fix shipped on Monday, and no complaints came in.
12
A security reviewer asks you to confirm that passwords and personal data are stored safely. What do you check in the database?
Query the users table after signup and confirm the password is not stored in plain text or reversible encoding, but as a salted hash from a slow algorithm such as bcrypt or Argon2. Two users with the same password should have different hashes. Check that card numbers are not stored at all or are tokenised, that personal data like Aadhaar numbers is masked or encrypted, and that logs and audit tables do not copy the raw values.
-- 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;
15
Tell me about a time you found an important bug that others missed.
Model answer: Situation: before a release of an insurance app, all regression tests had passed. Task: I was doing a final exploratory round. Action: I renewed a policy on the last day of the month and saw that the premium was calculated for 31 days in a 30-day month. I logged it with exact data and the formula difference. Result: the date logic was fixed before release, and I added month-end cases to the suite.
16
Your team says nightly database backups are working. How do you prove that a restore actually works?
Take a backup of a test database with known data, record row counts and a few checksums, then restore it to a separate server. Compare counts, sample records, constraints and users. Measure how long restore takes against the recovery time objective, and check that point-in-time restore loses no more data than the recovery point objective allows. A backup that has never been restored is not proven, so this test should run regularly.
17
An API returns 200 OK but the body contains an error message. Is that a bug?
Usually yes. Status codes should reflect the result so clients and monitoring can react correctly; an error with 200 can hide failures and break retries. A validation error should return 400 or 422, a missing resource 404 and a server failure 500. Check the API contract first: some legacy APIs document this pattern. If it is not documented, log it as a defect with the request and response attached.
18
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.
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.
21
A manager says the app has 50,000 daily users, so the load test must run 50,000 virtual users at once. How do you respond?
Explain that daily users are not concurrent users. Of 50,000 users a day, only a fraction are active at the same moment, and even they pause between actions because of think time. Use analytics to find the real peak concurrency and request rate, for example 1,500 concurrent users at peak hour, and model that with a safety margin. Running 50,000 users clicking at once tests a load that never happens and wastes effort.
ARIA, Accessible Rich Internet Applications, is a set of HTML attributes such as role, aria-label, aria-expanded and aria-live that tell assistive technology what a custom component is and what state it is in. The first rule is to prefer native HTML elements, such as a real button, because they are accessible by default. Wrong ARIA is worse than none, so testers verify announced roles and states match real behaviour.
23
Write a JQL query for open high or highest priority bugs in the current sprint of project PAY.
project = PAY
AND issuetype = Bug
AND statusCategory != Done
AND priority in (Highest, High)
AND sprint in openSprints()
ORDER BY priority DESC, created ASC
24
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.
25
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
26
SQL: find customers who placed more than three orders in the last 30 days.
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;
27
What sensitive data checks do you do in API responses and logs?
Check that responses return only needed fields, with no passwords, password hashes, full card numbers, full ID numbers or internal keys. Verify personal data is masked where required, for example only the last four digits of a phone number. Look at application and browser console logs for tokens or personal data. Check error responses do not expose stack traces, SQL or server versions. Raise any leak as a high-severity bug.
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.
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.
31
What is the difference between a defect and a production incident?
A defect is a flaw in the software that makes it behave differently from the requirement, whether found in testing or production. A production incident is an event that disrupts or degrades service for users, such as an outage or a failed payment flow. An incident may be caused by a defect, but also by infrastructure, configuration or third-party failures. Incidents are handled by an incident process first, then linked to defects for the fix.
32
What is a sprint planning meeting and what does QA contribute?
A user story describes a feature from the user's view, usually as: As a role, I want a goal, so that a benefit. Acceptance criteria are the specific conditions the story must meet to be accepted, often written as Given, When, Then. For example, given a registered user, when they enter a wrong password three times, then the account is locked for 15 minutes. Testers use acceptance criteria as the base for test cases.
34
What is the difference between product risks and project risks in a test plan?
Product risks are about the quality of the software itself: features that may fail and harm users, such as wrong interest calculation or a data leak. They decide what to test more deeply. Project risks are about running the test project: late builds, unstable environments, missing skills, unclear requirements or tight deadlines. They decide how to plan, with mitigations like buffers, backup environments or training.
35
A CAPTCHA on the signup page blocks screen reader users. What do you recommend?
Log it as a high-severity accessibility bug because it fully blocks a group of users from signing up. An image-only CAPTCHA fails WCAG unless an alternative is offered. Recommend options such as invisible or risk-based bot checks, an email or OTP verification step, an audio alternative plus another modality, and rate limiting on the server. Retest the full signup with NVDA and TalkBack after the change.
The result is a failure, not a pass. Failed requests often return quickly, so they make response times look better than they are. Check which requests fail and with which errors, such as 500, 503 or timeouts, and when errors started relative to the load level. Look at server logs, connection pool and thread limits. Also confirm the script is not wrong, for example expired tokens or bad test data.
Check alignment, spacing, fonts, colours and images against the design. Verify text is not cut off or overlapping, buttons and links look clickable and show hover and disabled states, and error messages appear in the right place. Check responsive behaviour on different screen widths and zoom levels. Confirm icons and images load and have alt text. Compare with the design file and take screenshots for any differences.
Re-check the requirement, reproduce with clear steps and evidence (screenshots, logs), discuss with the BA/PO and record the final decision.
Tips to crack the Nykaa Software Testing interview
Prepare cases on beauty e-commerce like repeat purchases, private label growth or offline store performance.
Practise SQL and Excel analysis on customer and order data, focusing on retention and basket size.
Use the Nykaa and Nykaa Fashion apps and suggest measurable improvements to discovery or checkout.
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; Nykaa interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Nykaa Software Testing interview?
Candidates usually go through 4 stages: Online assessment or assignment; Technical or case round; Hiring manager 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 Nykaa Software Testing interview?
This practice set leans on Agile, SQL and API Testing (10), Test Case Design (6), Bug Life Cycle and Jira (4), STLC and Test Planning (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Nykaa interviewers ask you to walk through real work.
Are these the exact questions asked at Nykaa?
No. These are curated practice questions that match the skills and difficulty usually tested in e-commerce & consumer tech interviews like Nykaa's. They are not a leaked or verified list of past questions.
Where does Nykaa hire Software Testing professionals in India?
Nykaa has large teams in Mumbai, Gurugram, Bengaluru. Openings and locations change often, so check the Nykaa careers page and filter by city and experience.