Kotak Mahindra 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 Kotak Mahindra Bank hiring for Software Testing roles
Kotak Mahindra Bank is a major Indian private sector bank offering retail banking, corporate banking, wealth management, credit cards and digital banking through products like Kotak 811. The wider Kotak group also includes securities, asset management and insurance businesses. It hires for relationship management, operations, risk, analytics and technology roles across its offices and branches.
For Software Testing roles, this Kotak Mahindra Bank practice set focuses most on Bug Life Cycle and Jira (6), Agile, SQL and API Testing (6), Database Testing (5), STLC and Test Planning (4). It has 4 easy, 32 medium, 4 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, Bengaluru
Kotak Mahindra Bank 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 Kotak Mahindra 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
When should you reopen a bug and when should you log a new one?
Reopen the bug when the same issue, with the same steps and expected result, still fails after the fix. Log a new bug when the fix works but a different problem appears, even in the same screen, or when the original bug has already been closed in a past release. Link the new bug to the old one. Mixing different problems in one reopened ticket confuses tracking and metrics.
02
What is the difference between a story, epic, task and bug in JIRA?
A test readiness review is a checkpoint before formal test execution starts, where the team confirms everything needed is in place. It checks that the build is deployed and smoke tested, the environment and test data are ready, test cases are reviewed and approved, access and tools work, and entry criteria are met. It prevents wasted days when execution starts and testers discover a missing service or empty database.
XSS is a vulnerability where an attacker's script is injected into a page and runs in other users' browsers, which can steal session data or change the page. It occurs when user input is shown without proper encoding. Testers enter a harmless script tag or an image tag with an onerror alert in comments, profile names and search boxes, then check if it executes when the page is displayed. Output encoding prevents it.
06
What is regression testing, and when do you automate it?
Manual testing is better for exploratory testing, usability and look-and-feel checks, features that change often, one-time tests and early testing of new functionality. Automation pays off for stable, repetitive tests such as regression suites, data-driven checks and smoke tests run on every build. Most teams combine both: manual for discovery and judgement, automation for speed and repeatability.
08
You notice full card numbers printed in the application logs. What do you do?
Treat it as a high-severity security defect, because storing full card numbers in logs breaks payment card security rules and creates a data leak risk. Do not copy the card numbers into the bug; use masked examples and the log location instead. Log the bug with restricted visibility and inform your lead and the security contact right away. After the fix, verify new logs are masked and confirm old logs are cleaned.
09
How do you decide testing is complete when some bugs are still open?
Testing is complete when agreed exit criteria are met, not when the bug count is zero. Check that planned tests ran, critical and high bugs are fixed or formally accepted, and remaining open bugs have workarounds and low user impact. Present the list with risk to the product owner, who decides on release. Record accepted bugs as known issues, so nothing is hidden and they are planned for a later release.
10
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
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.
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.
15
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.
16
A screen reader announces 'button, button, button' on a toolbar. What is the bug and how do you report it?
The toolbar uses icon-only buttons without accessible names, so users hear the role but not the purpose. Report it with the page, the screen reader and browser versions, the exact announcement and the expected one, such as 'Bold, toggle button, not pressed'. Reference WCAG 4.1.2 Name, Role, Value. The fix is an aria-label or visually hidden text on each button, plus a tooltip that also helps sighted users.
17
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
Defect age is how long a defect stays open, measured either in time, from the date it was logged to the date it was closed, or in phases, from the phase where it was introduced to the phase where it was found. High defect age signals slow fixing or triage. Phase-based age shows how late defects are caught; a requirement defect found in UAT has a high age and is costly.
20
A developer asks you to test a feature that has no acceptance criteria. How do you proceed?
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.
Appium is an open-source tool for automating native, hybrid and mobile web apps on Android and iOS using the WebDriver protocol. Tests can be written in Java, Python, JavaScript and other languages, and it uses platform drivers such as UiAutomator2 for Android and XCUITest for iOS. It can run on emulators, simulators, real devices and cloud device farms. Stable accessibility IDs make the best locators for it.
22
What is the difference between path parameters, query parameters and the request body?
Path parameters identify a specific resource and are part of the URL, as in /users/42. Query parameters filter, sort or paginate and come after a question mark, as in /users?city=Pune&page=2. The request body carries data for creating or updating, usually JSON, in POST, PUT or PATCH. Testers check invalid values in each: a wrong ID in the path, unknown query parameters and missing body fields.
1. Open and close by click and keyboard. 2. Select one, then several options; all show as chips or a count. 3. Deselect an option. 4. Select all and clear all, if available. 5. Search inside the list filters options. 6. Maximum selection limit is enforced with a message. 7. Required field shows an error if none selected. 8. Saved selection persists after refresh. 9. Long option names do not break layout. 10. Screen reader announces selected state.
Entry criteria are conditions that must be met to start testing (build ready, environment set); exit criteria define when testing can stop (pass rate, no critical defects).
25
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.
26
How do you set up and clean test data for database tests without affecting other testers?
Create your own data with a clear prefix or tag, such as emails starting with qa_ravi_, or IDs in a reserved range. Insert data through the app or API where possible so it follows real rules, and keep SQL setup scripts in version control. After testing, delete only your tagged rows, or run inside a transaction and roll back. Never edit shared master data without telling the team.
27
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.
28
The build arrived three days late but the release date has not moved. How do you prioritise execution?
Rank test cases by business risk and usage: critical flows like login, payment and data saving first, then new features, then high-risk regression from past defects, and cosmetic checks last. Run smoke testing immediately to avoid wasting time on a broken build. Share the reduced plan with the lead and product owner so they know what will not be covered, and get agreement on the remaining risk.
Fill the device storage close to the limit, then install or update the app and confirm a clear message if it cannot proceed. Inside the app, try downloads, photo capture, caching and saving drafts. The app should show a helpful error, not crash or corrupt data. Also check what happens to the local database when a write fails, and whether the app recovers after space is freed.
31
What is the difference between statement coverage and branch coverage?
Statement coverage measures the percentage of code statements executed by tests. Branch coverage measures whether every decision outcome, true and false, has been executed. Branch coverage is stronger: for 'if (amount > 1000) applyDiscount()', one test with 1500 gives 100 percent statement coverage, but you need a second test with 500 to cover the false branch. 100 percent branch coverage implies 100 percent statement coverage, not the other way round.
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.
36
Leadership asks whether test automation is worth the investment for your project. How do you estimate the ROI?
Compare cost and savings over time. Cost includes building scripts, framework setup, tools, CI infrastructure and ongoing maintenance, often a large share of total effort. Savings include manual execution hours saved per run multiplied by runs per year, earlier bug detection and faster releases. For example, a 40-hour manual regression run every two weeks saves about 1000 hours a year. Tests that run rarely or break often may never pay back.
37
How do you test an application with no documentation?
Talk to developers and users, explore the product, review similar systems, create notes and mind maps, confirm assumptions and write test cases as you learn.
Valid keyword, partial match, no results, special characters, very long text, empty search, case sensitivity, spelling errors, suggestions and speed of results.
39
SQL: how do you test a foreign key defined with ON DELETE CASCADE?
-- Create a parent and child, delete the parent, child rows must disappear
INSERT INTO customers (id, name) VALUES (501, 'Cascade Test');
INSERT INTO orders (id, customer_id, total) VALUES (7001, 501, 250);
DELETE FROM customers WHERE id = 501;
SELECT COUNT(*) FROM orders WHERE customer_id = 501;
-- Expected: 0
-- Also test inserting an order for a non-existent customer: it must fail
Check access with valid, expired and missing tokens, role-based permissions, error codes and that sensitive data is never exposed.
Tips to crack the Kotak Mahindra Bank Software Testing interview
Revise banking basics such as types of accounts, loans, interest rates, KYC and the role of the RBI.
For technology and analytics roles, prepare SQL, Excel and one programming language, with examples from your projects.
Read about Kotak's digital banking efforts like Kotak 811 and recent banking news to discuss them in interviews.
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; Kotak Mahindra Bank interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Kotak Mahindra Bank 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 Kotak Mahindra Bank Software Testing interview?
This practice set leans on Bug Life Cycle and Jira (6), Agile, SQL and API Testing (6), Database Testing (5), STLC and Test Planning (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Kotak Mahindra Bank interviewers ask you to walk through real work.
Are these the exact questions asked at Kotak Mahindra Bank?
No. These are curated practice questions that match the skills and difficulty usually tested in banking & finance interviews like Kotak Mahindra Bank's. They are not a leaked or verified list of past questions.
Where does Kotak Mahindra Bank hire Software Testing professionals in India?
Kotak Mahindra Bank has large teams in Mumbai, Bengaluru. Openings and locations change often, so check the Kotak Mahindra Bank careers page and filter by city and experience.