Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Groww hiring for Software Testing roles
Groww is an Indian investment platform offering stocks, mutual funds, futures and options, fixed deposits and other financial products. Its engineering and analytics teams work on trading systems, user experience, risk and growth. It hires for software engineers, SDETs, data analysts and data scientists. Many users are first-time retail investors.
For Software Testing roles, this Groww practice set focuses most on Test Case Design (8), Agile, SQL and API Testing (5), STLC and Test Planning (4), Testing Types (4). It has 5 easy, 25 medium, 10 hard questions, so you can start easy and work up to the harder ones.
Company type
Fintech
Headquarters
Bengaluru, India
Main India offices
Bengaluru
Groww Software Testing interview process
Online assessment or assignment
Technical round (coding or SQL)
Design or problem solving round
Hiring manager round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for GrowwStart 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
What is SQL injection and how can a tester check for it at a basic level?
SQL injection happens when user input is added directly into a database query, letting an attacker change the query to read or modify data. A tester can enter inputs like a single quote or ' OR '1'='1 in login, search and URL parameters and watch for database errors, unexpected results or a login bypass. Only test in approved environments. The real fix is parameterised queries, not input filtering alone.
Note the order ID and compare the UI value, the API response and the database value to find where they differ. Check if the UI calculates the total on the screen instead of using the saved value, whether taxes, discounts or rounding are applied at different layers and whether a later update job changed the record. Log the bug with all three values, because invoices and reports will use the database figure.
04
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.
05
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.
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.
07
Tell me about a time exploratory testing helped you find a critical bug.
Model answer: Situation: a new leave management module had passed all scripted cases. Task: I had a one-hour exploratory session. Action: I applied leave, then changed my manager in the profile while the request was pending. Result: the request disappeared for both managers and could never be approved. It was fixed before release, and the team added role-change scenarios to the regression suite.
Verify each status change appears in order: placed, accepted, preparing, picked up and delivered. Check the rider's location updates on the map at the expected interval. Test the estimated time updates when there is a delay. Verify notifications for each status. Check behaviour when the network drops and recovers, when the app is reopened, and when the order is cancelled midway. Confirm tracking stops after delivery and the rating screen appears.
10
How do you test touch target size and gestures for accessibility in a mobile app?
Check that buttons and icons are large enough to tap without hitting neighbours: Android guidance is 48 by 48 dp and iOS is 44 by 44 points. Test with large font settings and one-handed use. Any action using complex gestures, such as swipe to delete or pinch, must have a simple tap alternative. Then turn on TalkBack and VoiceOver and confirm each control can be focused, named and activated.
11
What automated accessibility tools exist and what are their limits?
Common tools are axe DevTools, Lighthouse in Chrome, WAVE and accessibility linters in CI. They quickly catch missing alt text, low contrast, missing labels and invalid ARIA. Their limit is that they find only roughly a third of WCAG issues. They cannot judge whether alt text is meaningful, focus order is logical, error messages make sense or a custom widget works with a screen reader, so manual testing is still required.
An urgent patch released outside the normal schedule to fix a critical production defect, followed by regression testing and merge back to the main branch.
13
What is the difference between an error, a defect and a failure?
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.
Success, failure and pending flows, timeouts, refunds, double-click payments, every method (UPI, cards, net banking), rounding, security (no card data stored) and reconciliation with bank reports.
16
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.
17
What is colour contrast ratio and what values does WCAG require?
Contrast ratio compares the brightness of text and its background, from 1:1 to 21:1. WCAG AA requires at least 4.5:1 for normal text and 3:1 for large text, which is about 18 point or 14 point bold. User interface parts such as input borders and icons need 3:1. AAA raises text to 7:1. Testers check this with a contrast checker or browser developer tools, including placeholder, disabled and hover states.
Stop the retest loop and call a short session with the developer, lead and product owner. Check whether the fix addresses the root cause or only the symptom, whether everyone agrees on the expected behaviour and whether different environments or data are involved. Run a root cause analysis and agree on clear acceptance tests before the next fix. Add an automated regression check so it cannot silently return.
20
What is the difference between ad hoc testing and monkey testing?
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.
21
Your test repository has many duplicate and outdated test cases. How do you clean it up?
Export the cases and group them by module and requirement. Mark duplicates, merge them into one well-written case, and retire cases for removed features. Check which cases have not been executed or failed in months and confirm whether they are still valid. Link the remaining cases to requirements so gaps are visible. Do it module by module with peer review, and set a rule that every story update also updates its test cases.
22
What are implicit waits, explicit waits and auto-waiting?
An implicit wait, in Selenium, sets a global time the driver keeps retrying to find any element before failing. An explicit wait waits for a specific condition, such as an element being clickable or a spinner disappearing, and is more precise. Auto-waiting, built into Playwright and Cypress, automatically waits for elements to be visible, enabled and stable before acting. Mixing implicit and explicit waits in Selenium can cause unpredictable delays.
23
An automated test passes on your laptop but fails in the CI pipeline. How do you troubleshoot?
Check the CI logs, screenshots, video or trace to see exactly where it failed. Then compare the environments: headless versus headed browser, screen size, browser version, time zone, environment URLs and secrets, test data and network speed. Run the test locally in headless mode with the CI settings. Common causes are timing, missing data in the CI environment and tests depending on run order. Fix the cause, not with a sleep.
Learning, test design and execution at the same time, without scripted cases — time-boxed sessions with a charter (e.g. 'explore checkout with coupons'), noting bugs and ideas. Great for finding edge cases.
25
A load test shows good response times but a 15 percent error rate. How do you interpret it?
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.
Risk-based testing: cover critical user flows, recent changes and high-defect areas first. Clearly communicate the untested risks and get stakeholder sign-off.
28
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.
29
Write a basic Selenium test in Python that opens a page and checks its title.
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.
32
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 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.
System testing tests the complete, integrated application against the requirements in an environment close to production. It is done by the testing team after integration testing and before UAT. It covers functional testing of all features plus non-functional aspects such as performance, security, usability and compatibility. It is black box testing, so the tester checks behaviour from the user's point of view without looking at the code.
37
The test environment is down for two days just before release. What do you do?
Escalate immediately with the impact on the schedule. While it is down, prepare test data, review and update test cases, and test what you can elsewhere: API tests against another environment, UI on a developer machine or a staging copy. Track the lost hours in the status report. When the environment returns, run smoke first, then the prioritised list, and ask whether the release date or scope needs to change.
38
What is the difference between a Deferred bug and a Rejected bug?
A deferred bug is valid, but the team decides to fix it in a later release because of low priority, time limits or low impact. It stays in the backlog with a target version. A rejected bug is one the developer or triage team considers invalid: working as designed, not reproducible, a duplicate or caused by wrong test data. Testers should check the reason for rejection and challenge it with evidence if they disagree.
Turn on the screen reader, TalkBack on Android or VoiceOver on iOS, and check every button, image and field has a meaningful label and the reading order is logical. Check text scales with system font size, colour contrast is sufficient and touch targets are large enough, about 48 by 48 density-independent pixels. Make sure information is not shown by colour alone and that the app works without complex gestures.
Tips to crack the Groww Software Testing interview
Learn stock market basics like orders, settlement, mutual fund NAV and SEBI regulations for domain discussion.
Practise test scenarios for order placement, market hours and payment failures for QA roles.
Prepare analytics cases on first-time investor activation and retention, which are central to Groww's growth.
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; Groww interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Groww Software Testing interview?
Candidates usually go through 4 stages: Online assessment or assignment; Technical round (coding or SQL); Design or problem solving round; 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 Groww Software Testing interview?
This practice set leans on Test Case Design (8), Agile, SQL and API Testing (5), STLC and Test Planning (4), Testing Types (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Groww interviewers ask you to walk through real work.
Are these the exact questions asked at Groww?
No. These are curated practice questions that match the skills and difficulty usually tested in fintech interviews like Groww's. They are not a leaked or verified list of past questions.
Where does Groww hire Software Testing professionals in India?
Groww has large teams in Bengaluru. Openings and locations change often, so check the Groww careers page and filter by city and experience.