Software Testing Interview Questions for Fintech Companies
40 questions weighted to the interview style of fintech companies — 2 easy, 32 medium, 6 hard.
How fintech companies interview for Software Testing
Fintech companies care about correctness, security and scale because they move money. Interviews add domain questions on payments, risk, reconciliation and compliance to the usual technical rounds, and often include practical tasks.
This set focuses on Bug Life Cycle and Jira (8), Testing Types (7), STLC and Test Planning (5), Agile, SQL and API Testing (5).
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
A developer changed a shared header component used on every page. What testing do you plan?
Retest the change itself, then run a focused regression on every page type that uses the header: home, listing, detail, checkout and account. Check navigation links, search, login and logout state, cart count and the mobile menu. Do cross-browser and responsive checks because layout changes affect all sizes. A quick visual comparison against the previous build helps spot alignment issues across many pages.
02
What is regression testing, and when do you automate it?
A test strategy is a high-level document, often at organisation or product level, that defines the general approach: test levels, types, tools, environments, automation approach and standards. It changes rarely. A test plan is project or release specific: scope, schedule, resources, entry and exit criteria, risks and deliverables. The plan follows the strategy and applies it to a particular release.
04
A bug happens only in production and not in the QA environment. How do you investigate?
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.
05
What are Postman environments and the Collection Runner?
An environment in Postman is a set of variables, such as base_url and token, that you switch to run the same requests against QA, staging or production-like setups without editing each request. The Collection Runner executes all requests in a collection in order, runs their test scripts and can repeat them with data from a CSV or JSON file. Together they give manual testers a first step into repeatable API automation.
06
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.
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.
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.
13
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.
14
How do you handle a product owner who keeps adding scope in the middle of a sprint?
Model answer: Situation: our product owner added two small changes to a story mid-sprint, which pushed testing to the last day. Task: protect quality without being rigid. Action: I showed the extra test effort in stand-up and asked the Scrum Master to help decide what to swap out. Result: one change moved to the next sprint, and the team agreed new requests go through the backlog.
A deep link opens a specific screen inside the app from a URL, email, SMS, QR code or notification. Test that each link opens the correct screen with the right data when the app is installed, closed or running in background. If the app is not installed, it should open the store page or a web fallback. Test links that need login, expired or invalid links, and that parameters cannot be tampered with to access other users' data.
16
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.
17
How do you do cross-browser testing and choose which browsers to cover?
Use analytics to pick browsers and versions that most real users have, plus the ones listed in the requirement, usually the latest two versions of major desktop and mobile browsers. Run the main flows on each and check layout, fonts, forms, date pickers, file upload and JavaScript errors in the console. Use responsive mode for screen sizes, and real devices or a cloud device lab for mobile browsers.
Give a clear title, such as 'Checkout: Place Order button not reachable by keyboard'. Include the page URL, browser, operating system and assistive technology with versions. Write exact steps, what was announced or happened, and what was expected. Add the WCAG success criterion, such as 2.1.1 Keyboard, and the user impact. Attach a screenshot or audio recording, and suggest a fix when obvious. Severity should reflect whether users are fully blocked.
19
What is the difference between a story, epic, task and bug in JIRA?
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.
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.
Sprint planning (estimate test effort), daily stand-up (status and blockers), sprint review (demo) and retrospective (improve). Testers clarify acceptance criteria early and test within the sprint.
23
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.
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.
26
What is the difference between a bug and an enhancement?
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.
28
What do you check in mobile accessibility testing?
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.
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.
34
The app crashes only on one older Android version. What are your steps?
Reproduce it on that exact OS version, using a real device or an emulator image, and note the device model and app build. Capture the crash log and stack trace. Check if the code uses an API or library not supported on that version, or a permission or storage behaviour that changed. Log the bug with logs and the minimum supported version from the requirement, so the team can decide to fix it or raise the minimum version.
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.
36
The same bug keeps reopening across three sprints. What do you do?
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.
Functional testing checks what the system does (login, checkout). Non-functional testing checks how well it does it (performance, security, usability, compatibility).
38
Managers say the automation test report is hard to understand. What should a useful report include?
A useful report shows total tests run, passed, failed and skipped, the run time, the environment, build number and browser. For each failure it should show the test name, the failing step, the error message, and a screenshot, video or trace, plus logs. Trends across runs help spot flaky tests. Linking failures to Jira bugs or manual case IDs helps managers see real product risk, not just numbers.
39
How do you link stories, test cases and bugs in Jira for traceability?
Create test cases as linked issues or in a test management add-on and link each one to its story with a tests relationship. When a test fails, create the bug from the test execution or link it to both the test and the story with is blocked by or relates to. Use the same fix version for all. A story then shows its tests and open bugs, which makes sign-off and the traceability report easy.
40
Explain three-point estimation for testing with an example.
Three-point estimation uses an optimistic (O), most likely (M) and pessimistic (P) estimate for each task. The weighted formula is (O + 4M + P) divided by 6. If testing a module would take 4 days at best, 6 days most likely and 14 days at worst, the estimate is (4 + 24 + 14) / 6 = 7 days. It includes uncertainty in a single number and is often combined with a work breakdown of test activities.
How are Software Testing interviews at fintech companies different?
Fintech companies care about correctness, security and scale because they move money. Interviews add domain questions on payments, risk, reconciliation and compliance to the usual technical rounds, and often include practical tasks.
Which fintech companies are covered?
This page links to 19 fintech companies, including Intuit, CRED, Paytm, PhonePe, Razorpay, PayPal, Stripe, Visa. Each has its own page with rounds and a separate practice set.
What rounds should I expect?
Common rounds at these companies include: HR round; Hiring manager round; Online coding assessment; Technical round 1 (DSA); Online assessment or assignment. The exact process varies by company and role.