Standard Chartered Software Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Standard Chartered hiring for Software Testing roles
Standard Chartered is a British international bank with most of its business in Asia, Africa and the Middle East. Its India global business services centres in Chennai and Bengaluru support technology, operations, analytics and risk. It hires for software engineers, testers, data analysts, data engineers and financial crime analysts.
For Software Testing roles, this Standard Chartered practice set focuses most on Agile, SQL and API Testing (7), Test Case Design (7), Bug Life Cycle and Jira (6), STLC and Test Planning (4). It has 9 easy, 28 medium, 3 hard questions, so you can start easy and work up to the harder ones.
Company type
Banking & finance
Headquarters
London, United Kingdom
Main India offices
Chennai, Bengaluru, Mumbai
Standard Chartered Software Testing interview process
Online assessment (aptitude + technical)
Technical round
Managerial round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Standard CharteredStart 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
Write a Postman test script that checks the status is 201 and the response contains an id.
pm.test('Status is 201', function () {
pm.response.to.have.status(201);
});
pm.test('Response has id', function () {
const body = pm.response.json();
pm.expect(body).to.have.property('id');
pm.expect(body.id).to.be.a('number');
});
The test basis is the set of documents and knowledge from which test cases are derived. It includes requirement specifications, user stories with acceptance criteria, design documents, wireframes, API contracts, business rules and even existing system behaviour. A good test basis lets you trace each test case back to a requirement. If the test basis is weak or missing, testers must clarify it before or while testing.
03
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.
04
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.
1. Correct current password and valid new password: success, old password stops working. 2. Wrong current password: error, no change. 3. New password same as current: rejected if policy says so. 4. New and confirm fields do not match: error. 5. New password below minimum or above maximum length: error. 6. Missing digit or special character: policy message. 7. Other active sessions are logged out. 8. Confirmation email or alert is sent. 9. Password fields are masked.
PUT replaces the whole resource with the data sent, so fields you leave out may be cleared or reset. PATCH applies a partial update and changes only the fields sent. For example, to change only a user's phone number, PATCH with just the phone field is enough, while PUT expects the complete user object. Testers check that PUT and PATCH behave as documented and that missing fields are handled correctly.
Verify notifications arrive when the app is in foreground, background and closed. Check title, text, icon and that tapping opens the right screen with the correct data. Test with notifications disabled at OS level and inside app settings. Check behaviour after logout, reinstall and on multiple devices with the same account. Test grouping of many notifications, time-sensitive ones, and that no notification shows private data on the lock screen.
08
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.
Re-check environment, data, browser and steps; check the logs; try the reporter's setup; add video and console logs; mark it 'cannot reproduce' only after discussing with the developer, and keep monitoring.
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).
Recovery testing checks how well the system recovers from crashes, hardware failures, network loss or other failures. For example, kill the server during a file upload, or disconnect the network during payment, and verify the system restores a consistent state, does not lose or duplicate data and resumes or shows a clear message. It also measures recovery time against agreed targets, which matters for banking and healthcare systems.
12
Why do performance reports use percentiles like p90 and p95 instead of averages?
An average hides slow requests. If 90 requests take 1 second and 10 take 10 seconds, the average is 1.9 seconds, which looks fine, but one user in ten waits 10 seconds. The p95 value means 95 percent of requests were faster than it, so it shows what most users actually experience, including the slow tail. Service level targets are usually written as percentiles, such as p95 under 2 seconds.
13
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.
Components are fixed sub-parts of a project, such as Payments or Login, often with a default owner. Labels are free-text tags, such as regression or ui, that anyone can add for grouping. Fix version is the release in which the issue is planned to be fixed, while affects version is where the bug was found. Testers use these fields to filter bugs and to build release-wise reports.
Yes, very likely. An index lets the database find rows quickly, like the index of a book. With a small QA table, a full table scan is still fast, but with millions of production rows it becomes slow. Compare indexes on the searched columns in both environments and ask a developer to check the query plan. Test key queries on production-size data in staging, and include data volume in future performance checks.
19
During a load test, some booking requests fail with a 'deadlock detected' error. What is happening and how do you report it?
A deadlock happens when two transactions each hold a lock the other needs, so neither can continue. The database detects it and kills one transaction with an error. During testing it usually appears under concurrent load, for example two users booking the last seats at once, as random failures or 'deadlock detected' entries in logs. Testers report the exact actions and timing, and developers fix it with consistent lock order or shorter transactions.
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.
Save filters for common views such as my open bugs, bugs ready for retest, blockers in the current sprint and bugs by fix version. Add them to a dashboard with gadgets like pie charts by priority, created versus resolved trend and a sprint bug list. Share the dashboard with the team so status is visible without manual reports. Testers start their day from the ready-for-retest filter.
25
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
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.
28
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.
29
What is the role of a manual tester in a software team?
A manual tester understands requirements, writes test scenarios and test cases, prepares test data, executes tests on each build, logs clear bug reports and retests fixes. They also do exploratory testing, join stand-ups and reviews, and give a quality status before release. Beyond finding bugs, a good manual tester represents the end user and raises usability or requirement gaps early, when they are cheap to fix.
In sprint planning, review each story's acceptance criteria and estimate test effort, including test data and regression. Write test cases in the first days while development starts. Ask for early builds so testing is spread across the sprint, not crowded at the end. Keep time for regression and bug retesting in the last two or three days. Track progress on the board and raise risks in stand-up.
31
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
32
How do you run a moderated usability test session?
Define goals and three to five realistic tasks, such as 'Book a train ticket for next Friday'. Recruit participants who match real users. In the session, explain that you are testing the product, not them, ask them to think aloud, and avoid hinting even when they struggle. Record the screen with consent, note where they hesitate or fail, and finish with a short questionnaire. Then group findings by severity and frequency.
Situation: a small tax rounding change was made late on a Friday. Task: no manual regression was planned for pricing. Action: our nightly API suite failed one data-driven case where a 3-item cart was off by one rupee; I checked the trace, reproduced it manually and logged it with the failing input. Result: it was fixed before release, and the team agreed to keep pricing tests in the pull request suite.
35
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.
36
What is a sprint planning meeting and what does QA contribute?
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.
38
What should a tester verify about HTTPS on a website?
Check every page and API uses HTTPS, and plain HTTP redirects to HTTPS. Verify the certificate is valid, not expired, and matches the domain, with no browser warnings. Look for mixed content, where an HTTPS page loads scripts or images over HTTP. Check login and payment forms submit only over HTTPS and that cookies holding session data have the Secure flag.
Cause-effect graphing is a black box technique that models input conditions (causes) and output actions (effects) with logical relations like AND, OR and NOT. The graph is converted into a decision table, and each column becomes a test case. It is useful when outputs depend on combinations of inputs, such as loan approval based on income, age and credit score. It helps find missing or contradictory rules in the requirement.
40
Tell me about a time you used a test design technique to reduce the number of test cases.
Model answer: Situation: in my training project, a registration form had age, state and course fields, and my first draft had over 60 test cases. Task: cut effort without losing coverage. Action: I applied equivalence partitioning and boundary values to age and pairwise combinations for state and course. Result: I covered the same rules with 18 cases, my mentor approved them, and execution finished in half the time.
Tips to crack the Standard Chartered Software Testing interview
Learn trade finance, cash management and financial crime compliance basics, which are strong areas for the bank.
Revise SQL, Python and testing concepts for technology and analytics roles, using banking transaction examples where possible.
Read about Standard Chartered's valued behaviours, such as Do the right thing and Never settle.
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; Standard Chartered interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Standard Chartered Software Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + technical); Technical round; 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 Standard Chartered Software Testing interview?
This practice set leans on Agile, SQL and API Testing (7), Test Case Design (7), Bug Life Cycle and Jira (6), STLC and Test Planning (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Standard Chartered interviewers ask you to walk through real work.
Are these the exact questions asked at Standard Chartered?
No. These are curated practice questions that match the skills and difficulty usually tested in banking & finance interviews like Standard Chartered's. They are not a leaked or verified list of past questions.
Where does Standard Chartered hire Software Testing professionals in India?
Standard Chartered has large teams in Chennai, Bengaluru, Mumbai. Openings and locations change often, so check the Standard Chartered careers page and filter by city and experience.