HDFC Bank Software Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About HDFC Bank hiring for Software Testing roles
HDFC Bank is one of India's largest private sector banks, offering retail banking, loans, cards, wholesale banking and digital banking. Its analytics, risk and technology teams work on credit decisions, customer analytics, fraud detection and digital channels. It hires for data analysts, credit and risk analysts, testers and technology roles.
For Software Testing roles, this HDFC Bank practice set focuses most on Agile, SQL and API Testing (8), Test Case Design (6), Automation Basics for Manual Testers (4), Accessibility & Usability Testing (4). It has 8 easy, 25 medium, 7 hard questions, so you can start easy and work up to the harder ones.
Company type
Banking & finance
Headquarters
Mumbai, India
Main India offices
Mumbai, Chennai, Bengaluru
HDFC Bank Software Testing interview process
Online assessment (aptitude + domain)
Technical or functional interview
Managerial round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for HDFC BankStart 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 the waterfall model and where does testing fit in it?
Waterfall is a sequential model: requirements, design, development, testing and deployment happen one after another. Testing starts only after development is complete, so defects in requirements or design are found late and are costly to fix. It suits small projects with stable, well-defined requirements. Its weakness for testers is the late feedback, which is why most teams now use Agile or the V-model.
Valid keyword, partial match, no results, special characters, very long text, empty search, case sensitivity, spelling errors, suggestions and speed of results.
03
Why are stable locators like data-testid or roles preferred over position-based XPath?
A position-based XPath such as /html/body/div[3]/div[2]/button breaks whenever a developer adds a wrapper div or reorders the layout, even though the feature still works. That creates false failures and maintenance work. Locators based on a dedicated data-testid attribute or the accessible role and name, like a button named Submit, stay valid through design changes and describe intent clearly. Testers should ask developers to add test IDs.
-- 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;
06
Write a simple Playwright test in TypeScript that logs in and checks the dashboard heading.
Scalability testing checks how well the system handles growing load by adding resources, such as more servers or bigger machines, and whether performance improves in proportion. For example, if two servers handle 1,000 users, do four servers handle about 2,000 at the same response time? It finds limits that resources cannot fix, such as a single database bottleneck, and helps plan capacity for future growth.
08
How do you write test cases when only wireframes are available and the UI is not ready?
Use the wireframes and the user story as the test basis. Write test scenarios and high-level cases for the flows, field validations, navigation and error states shown in the design. Note open questions, such as missing empty states or error messages, and clarify them with the designer. Keep exact UI text and steps light so they are easy to update. Once the build arrives, refine the cases and add any missing details.
09
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.
Spend the first day learning the scope: read the release notes, user stories and test plan, and ask the lead what is at risk. Get access to the environment, tracker and test repository. Pick up a clearly defined module, run its existing test cases to learn the application and note gaps. Ask questions early in stand-up. Within a few days, take ownership of retesting and regression for that module.
12
What is a user story and what are acceptance criteria?
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.
Alt text gives a text alternative for images so screen reader users get the same information. Check that informative images have short, meaningful alt text, such as 'Bar chart showing sales doubled in 2025', that decorative images have empty alt so they are skipped, and that image buttons describe the action, such as 'Search', not the picture. Inspect the alt attribute in developer tools and listen with a screen reader.
14
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.
15
Why should we hire you as a manual tester over someone with more automation experience?
Answer with strengths and honesty. For example: I am strong at understanding requirements, designing test cases with techniques like boundary values and finding bugs through exploratory testing, which automation depends on to be useful. I also write SQL and test APIs in Postman. I am learning Playwright and have automated a few smoke tests, so I can grow into automation while adding value from the first week.
16
Leadership asks for a one-page quality update before a release. Which bug metrics do you report?
Keep it short and decision-oriented. Show open bugs by severity, the created versus resolved trend, blockers with owners and dates, defect leakage from the last release and modules with the most defects. Give a clear recommendation, such as ready, ready with known issues or not ready, with reasons. Use a shared dashboard for detail, and one slide or email summary for leaders who need only the risk picture.
17
How do you test in-app purchases or subscriptions on mobile?
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.
18
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.
19
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.
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.
Verify a valid date is accepted and saved in the right format. Check the minimum age rule, such as 18 years, using boundary dates of exactly 18 today and one day short. Reject future dates and impossible dates like 30 February. Test leap year dates like 29 February 2004. Check manual typing and the picker give the same result, the field is mandatory if required, and the date displays correctly after saving.
Normalization organises tables to reduce duplicate data, for example storing the customer address once in a customers table instead of repeating it in every order. Testers should understand it because it explains where data lives and which joins are needed to verify a screen. It also shows risk: in a denormalized report table, the same value is copied in many places, so updates must be tested to confirm every copy changes.
24
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.
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.
26
How do you test password policy and account lockout?
Try passwords that break each rule: too short, no digit, no special character and common passwords, and check clear messages. Verify the password is masked and not shown in the URL or logs. Enter the wrong password up to the limit and confirm the account locks for the defined time or until reset. Check that the error message does not reveal whether the username exists and that the lockout counter resets after a successful login.
Contract testing checks that a service provider and its consumers agree on the API format, such as request fields, response fields and status codes, without running a full end-to-end environment. The consumer defines what it expects, and the provider's build verifies it still meets that contract. It catches breaking changes early in microservice systems, where full integration environments are slow and fragile.
Backward compatibility testing checks that a new version still works with older versions of things it depends on or that depend on it. Examples: a new app version opens files and data created by the old one, a new API version still serves older mobile app versions that users have not updated, and an upgraded database keeps old records readable. It prevents breaking existing users when only some parts of the system are upgraded.
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.
32
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.
33
How do you chain requests in Postman by passing a token from login to the next call?
// Tests tab of the Login request
const body = pm.response.json();
pm.environment.set('authToken', body.token);
// Next request header:
// Authorization: Bearer {{authToken}}
// Postman replaces {{authToken}} with the saved value
34
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.
35
SQL: find the second highest salary from an employees table.
SELECT MAX(salary) AS second_highest
FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);
-- alternative using DENSE_RANK
SELECT DISTINCT salary FROM (
SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
FROM employees
) t WHERE rnk = 2;
36
How do you make test cases reusable and easy to maintain?
Write one clear objective per case, keep steps short and avoid hard-coding data that changes. Put shared steps such as login into a common precondition instead of repeating them. Use consistent naming, link each case to a requirement and group them by module. Keep expected results specific but not tied to exact pixel layouts. Review and update cases whenever a story changes, so the suite stays trustworthy for regression.
37
Write a pytest test using requests that checks a GET call returns 200 and a non-empty list.
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.
39
How do you test a mobile app's offline mode and data sync?
Turn off the network and perform supported actions, such as creating, editing and deleting records, and check they are saved locally with a pending status. Reconnect and verify everything syncs once, in order, with no duplicates. Test conflicts, where the same record is changed on two devices, and confirm the agreed rule applies. Test sync after app restart, on a slow network and when the server rejects a change.
First ask what type of pen and who the users are. Functional: it writes smoothly, ink flows without leaking, the cap or click mechanism works and the ink colour matches the label. Non-functional: comfort of grip, writing length before ink runs out, performance at different temperatures and on different paper. Negative: dropping it, pressing hard, leaving it uncapped. Safety: the cap is non-toxic and has an air hole. This shows structured thinking, not just a list.
Tips to crack the HDFC Bank Software Testing interview
Learn Indian banking basics like CASA, NPAs, credit scores, KYC and RBI regulations for domain questions.
Revise SQL, Excel and basic statistics for analytics and risk roles with banking examples.
Understand UPI, net banking and mobile banking flows if applying for digital channel testing roles.
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; HDFC Bank interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the HDFC Bank Software Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + domain); Technical or functional 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 HDFC Bank Software Testing interview?
This practice set leans on Agile, SQL and API Testing (8), Test Case Design (6), Automation Basics for Manual Testers (4), Accessibility & Usability Testing (4). Revise those first, then practise explaining one or two of your own projects end to end, because most HDFC Bank interviewers ask you to walk through real work.
Are these the exact questions asked at HDFC Bank?
No. These are curated practice questions that match the skills and difficulty usually tested in banking & finance interviews like HDFC Bank's. They are not a leaked or verified list of past questions.
Where does HDFC Bank hire Software Testing professionals in India?
HDFC Bank has large teams in Mumbai, Chennai, Bengaluru. Openings and locations change often, so check the HDFC Bank careers page and filter by city and experience.