Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Bajaj Finserv hiring for Software Testing roles
Bajaj Finserv is a Pune-based financial services group, part of the Bajaj Group, with businesses in lending, insurance and investments. Its subsidiary Bajaj Finance is a large non-banking finance company known for consumer durable loans, personal loans and EMI cards. It hires for credit, risk, analytics, sales and technology roles, including data and digital product teams.
For Software Testing roles, this Bajaj Finserv practice set focuses most on Agile, SQL and API Testing (8), Accessibility & Usability Testing (6), STLC and Test Planning (5), Automation Basics for Manual Testers (5). It has 1 easy, 31 medium, 8 hard questions, so you can start easy and work up to the harder ones.
Company type
Fintech
Headquarters
Pune, India
Main India offices
Pune
Bajaj Finserv Software Testing interview process
Online assessment or resume screening
Functional or technical interview
Managerial round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Bajaj FinservStart 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 are suspension and resumption criteria in a test plan?
Suspension criteria define when testing should be paused because continuing would waste effort, for example when a blocker bug stops the main flow, the build fails smoke testing or the environment is down. Resumption criteria define what must happen to restart, such as a new build that passes smoke testing or the environment restored. Writing these down avoids arguments and shows clearly why testing time was lost.
02
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.
03
The UI shows the correct order total, but the database has a different value. What do you check?
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.
Most frameworks support this through configuration. In Playwright, set screenshot to only-on-failure, video to retain-on-failure and trace to on-first-retry in the config, then open the trace viewer to step through actions, network calls and the page state. In Selenium, call save_screenshot in a teardown hook when a test fails. Store these artefacts in CI so anyone can debug the failure without rerunning it.
Data masking replaces real sensitive values with realistic but fake ones, for example changing real phone numbers to valid-looking dummy numbers and real names to generated names. It lets teams test with production-like data volume and patterns without exposing customer information. It also supports compliance with India's Digital Personal Data Protection Act. Testers should check that masked data still passes validation rules and keeps relationships between tables intact.
08
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.
09
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.
Turn on the screen reader, for example NVDA with a browser, and listen rather than look. Navigate by headings to check the structure is logical, by landmarks to find main regions and by Tab through controls. Each control should announce a clear name, role and state, such as 'Subscribe, checkbox, not checked'. Check images, form errors, dynamic updates like cart counts and dialogs. Note exactly what was announced in bug reports.
11
Release is tomorrow and you can't test everything. What now?
Risk-based testing: cover critical user flows, recent changes and high-defect areas first. Clearly communicate the untested risks and get stakeholder sign-off.
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.
Open the dialog with the keyboard. Focus should move into it, usually to the first field or heading, and the screen reader should announce it as a dialog with its title. Tab must stay inside the dialog while it is open and the page behind must not be reachable. Escape and the close button should close it, and focus must return to the button that opened it. Also check it reads correctly when zoomed.
14
A page loads slowly only for some users. How do you investigate as a manual tester?
Collect details from affected users: location, device, browser, network and time. Try to reproduce with similar conditions using browser network throttling. Use the browser developer tools network tab to find slow requests, large files or failing calls, and compare with a fast user. Check whether those users have more data, like a long order history. Share the slow request, timing and conditions in the bug for the developers.
15
How do you test an application when requirements change frequently?
Start with preconditions: environment, build number, user role and the exact data state, such as an account with two pending orders and zero wallet balance. Mention how to create the data or give the test account ID. Then list numbered steps with exact inputs and finish with expected and actual results. If the data is hard to set up, attach the SQL used or a database screenshot so the developer can recreate it quickly.
18
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.
The Page Object Model is a design pattern where each page or major component gets a class that holds its locators and actions, such as LoginPage with a login method. Tests call these methods instead of using locators directly. When the login button changes, you update one place instead of fifty tests. Tests become readable, like steps a manual tester would write, and duplication drops. Keep assertions mostly in tests, not page objects.
20
What is localisation and internationalisation testing?
Internationalisation tests that the product can support many languages and formats; localisation tests that a specific locale is correct for text, currency, date and layout.
21
Write a simple Playwright test in TypeScript that logs in and checks the dashboard heading.
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.
A cold start launches the app from scratch when it is not in memory, loading the process and the first screen; it is the slowest. A warm start happens when the app process exists but the screen must be recreated, and a hot start just brings it to the foreground. Users abandon slow apps, so teams set targets, such as cold start under two seconds on a mid-range device, and measure each release for regressions.
25
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.
26
What new success criteria in WCAG 2.2 should testers know?
WCAG 2.2, published in 2023, added criteria including Focus Not Obscured, so sticky headers must not hide the focused element; Dragging Movements, which needs a non-drag alternative; Target Size Minimum of 24 by 24 CSS pixels; Consistent Help placement; Redundant Entry, so users are not asked for the same information twice; and Accessible Authentication, which avoids memory puzzles at login. It also removed the old Parsing criterion.
Testing services directly without the UI, checking status codes, responses, security and performance. It finds issues early and is faster than UI tests.
29
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.
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.
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.
33
Tell me about a time you found a bug by checking the database directly.
Situation: a wallet refund screen showed success for every test. Task: I wanted to confirm the balance logic. Action: I queried the wallet_transactions table and saw two refund rows when I double-clicked the submit button, though the UI showed one. I logged it with both query outputs and the steps. Result: developers added an idempotency key, and the team added a database check to our regression checklist.
34
How do you test battery and memory usage of a mobile app?
Run typical user sessions on a real device and measure battery drain, CPU and memory with platform profiling tools or the device's battery statistics. Compare with the previous version. Look for background work continuing after the app is closed, GPS left on, frequent network polling and memory that keeps growing, which signals a leak. Test on low-RAM devices too, where the OS kills heavy apps quickly.
35
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.
36
Tell me about a time you worked with developers to make an application easier to automate.
Situation: our UI scripts broke almost every sprint because of generated IDs and CSS class changes. Task: as the QA lead I needed stable tests. Action: I showed developers the failure history, proposed adding data-testid attributes and accessible labels to key components and added a short checklist to the pull request template. Result: within two sprints locator-related failures dropped by most of the previous level and maintenance time fell sharply.
It means that finding and fixing many defects does not guarantee success if the system itself does not meet user needs. A bug-free product built on wrong or misunderstood requirements is still a failure. For example, a perfectly working report that shows the wrong business metric is useless to the client. This is why testers validate against real user expectations, not just the written specification.
38
Your automated accessibility scan shows zero errors. Is the page accessible?
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.
39
Product is running an A/B test on the checkout button. What does QA need to verify?
QA does not decide which version wins, but makes sure the experiment is trustworthy. Verify both variants work end to end, users are split in the agreed ratio, each user sees the same variant consistently across sessions, and analytics events fire correctly for each group. Also check that turning the experiment off returns everyone to the default. A broken tracking event can make the whole experiment's result wrong.
Test monitoring compares actual testing progress with the plan, using metrics like test cases executed, pass rate, open defects and effort spent. Test control is the action taken when monitoring shows a gap, such as re-prioritising tests, adding testers, changing the schedule or tightening entry criteria. For example, if half the time has passed but only a quarter of cases are executed, the lead must act and inform stakeholders.
Tips to crack the Bajaj Finserv Software Testing interview
Learn lending basics such as credit scores, EMI calculation, interest rates and loan approval processes before the interview.
For analytics and risk roles, revise SQL, Excel and basic statistics, and discuss how data helps assess credit risk.
Understand the difference between a bank and an NBFC and know Bajaj Finserv's main product lines.
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; Bajaj Finserv interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Bajaj Finserv Software Testing interview?
Candidates usually go through 4 stages: Online assessment or resume screening; Functional or technical interview; 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 Bajaj Finserv Software Testing interview?
This practice set leans on Agile, SQL and API Testing (8), Accessibility & Usability Testing (6), STLC and Test Planning (5), Automation Basics for Manual Testers (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Bajaj Finserv interviewers ask you to walk through real work.
Are these the exact questions asked at Bajaj Finserv?
No. These are curated practice questions that match the skills and difficulty usually tested in fintech interviews like Bajaj Finserv's. They are not a leaked or verified list of past questions.
Where does Bajaj Finserv hire Software Testing professionals in India?
Bajaj Finserv has large teams in Pune. Openings and locations change often, so check the Bajaj Finserv careers page and filter by city and experience.