Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Fidelity Investments hiring for Software Testing roles
Fidelity Investments is a large American financial services company providing brokerage, retirement plans, mutual funds and wealth management. In India it operates technology and operations centres that build and support its trading, investment and customer platforms. These centres hire software engineers, quality engineers, data engineers, analysts and operations professionals.
For Software Testing roles, this Fidelity Investments practice set focuses most on Automation Basics for Manual Testers (6), Test Case Design (6), Bug Life Cycle and Jira (5), Manual Testing Basics (5). It has 3 easy, 31 medium, 6 hard questions, so you can start easy and work up to the harder ones.
Company type
Banking & finance
Headquarters
Boston, USA
Main India offices
Bengaluru, Chennai, Gurugram
Fidelity Investments Software Testing interview process
Online coding assessment
Technical round 1 (DSA + language)
Technical round 2 (design or domain)
Managerial and HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Fidelity InvestmentsStart 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
The developer says "it's not a bug". What do you do?
-- 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
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.
04
How do you convert existing manual test cases into automated scripts?
Pick a small set of stable, high-value regression cases first. Review each one: make steps precise, remove judgement-based checks and define clear expected results. Prepare test data that the script can create and clean up. Build reusable page objects and helpers for common steps like login. Automate, run several times to confirm stability, then link each script to its manual case ID and mark the manual case as automated.
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.
06
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.
07
What is SQL injection and how can a tester check for it at a basic level?
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.
08
How do you break a requirement into testable conditions?
Read the requirement and identify inputs, outputs, business rules, user roles and states. Turn each rule into a condition with an expected result, then add negative and boundary conditions. For example, 'users can withdraw up to 10,000 per day' becomes: withdraw below the limit, exactly at the limit, above the limit, multiple withdrawals adding up to the limit, and the limit resetting the next day. Each condition then becomes one or more 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.
Installation testing checks that software installs correctly on supported systems: fresh install, custom paths, low disk space, missing prerequisites and clean uninstall. Upgrade testing checks moving from an older version to the new one: user data and settings must be kept, database migrations must run, and the app must work after the upgrade. Also test skipping versions, such as 1.2 to 1.5, and what happens if the upgrade is interrupted.
14
What is a performance bottleneck and where do bottlenecks usually occur?
A bottleneck is the component that limits the whole system's performance, so adding load beyond it increases response times or errors. Common places are slow database queries or missing indexes, too few database connections or threads, CPU or memory limits on servers, slow third-party APIs, large uncompressed files and chatty code that makes many small calls. Monitoring each layer during a test shows which resource saturates first.
Verify a correct OTP within validity logs the user in. Verify a wrong OTP shows an error and an expired OTP is rejected. Check the OTP length and that only digits are allowed. Test resend: it is disabled during the countdown, and the old OTP stops working after resend. Check the maximum number of wrong attempts locks verification. Verify auto-read on mobile, paste support, and behaviour when the network drops during submission.
17
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.
18
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');
});
Defect removal efficiency shows how many defects the team found before release. DRE = defects found before release divided by (defects found before release plus defects found after release), multiplied by 100. If QA found 90 bugs and users reported 10, DRE is 90 percent. A falling DRE means testing is missing more defects, and the escaped bugs should be analysed to improve test coverage.
20
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.
A development model where each development phase has a matching testing phase, such as requirements with acceptance tests and design with integration tests.
22
You receive a new build and the login page itself is broken. What do you do?
Login is a blocker because no other testing can proceed. Confirm it quickly: retry with valid test accounts, check another browser and confirm the right environment and build number. Then log a blocker bug with steps, screenshot and console or network errors, inform the developer and lead immediately, and mark the build as rejected in smoke testing. Meanwhile, prepare test data or review test cases until a fixed build arrives.
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.
A latent defect exists in the software but has not caused a failure yet because the needed conditions have not occurred, such as a leap-year bug that appears only on 29 February. A masked defect is hidden by another defect, for example a broken discount calculation you cannot reach because the cart page crashes first. After the first bug is fixed, the masked one appears, which is one reason regression and retesting matter.
Testing shows presence of defects, exhaustive testing is impossible, test early, defects cluster, the pesticide paradox, testing is context-dependent and absence-of-errors is a fallacy.
/* CSS selector using the test id */
button[data-testid='login-btn']
// XPath using the test id
//button[@data-testid='login-btn']
// XPath using the visible text
//button[normalize-space()='Login']
29
How do you verify database schema changes in a new release?
Get the migration script or change list. Compare the schema before and after: new tables and columns, data types, lengths, default values, NULL rules, indexes and constraints. Check that existing data was migrated correctly, for example a new status column filled for old rows. Run the main app flows to confirm queries still work. Finally, confirm the rollback script works on a copy, so the release can be reversed safely.
A performance baseline is a set of measurements of the current system under a known load, such as response times, throughput, error rate and resource usage. Every new build or release is compared with it to spot regressions. For example, if the checkout API had p95 of 800 milliseconds at 200 users last release and now shows 1.5 seconds, the change needs investigation. A benchmark compares against an industry or competitor standard.
31
How do Selenium, Playwright and Cypress differ at a high level?
Selenium is the oldest, uses the WebDriver standard, supports many languages like Java, Python and C# and every major browser, and is common in older enterprise suites. Playwright supports TypeScript, Python, Java and .NET, runs Chromium, Firefox and WebKit, and has built-in auto-waiting, tracing and parallel runs. Cypress runs inside the browser with JavaScript or TypeScript, has a friendly runner and is popular with front-end teams.
32
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.
33
A manager says the app has 50,000 daily users, so the load test must run 50,000 virtual users at once. How do you respond?
Explain that daily users are not concurrent users. Of 50,000 users a day, only a fraction are active at the same moment, and even they pause between actions because of think time. Use analytics to find the real peak concurrency and request rate, for example 1,500 concurrent users at peak hour, and model that with a safety margin. Running 50,000 users clicking at once tests a load that never happens and wastes effort.
34
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.
35
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.
401 Unauthorized means the request has no valid authentication, such as a missing, expired or wrong token, so the client should log in again. 403 Forbidden means the user is authenticated but does not have permission for that resource, such as a normal user calling an admin API. Testers verify both: call without a token to expect 401, and call with a low-privilege token to expect 403.
It checks app behaviour on different networks: Wi-Fi, 4G, 5G, slow 2G or 3G, high latency, packet loss and no network. Also test switching between Wi-Fi and mobile data in the middle of an action, and airplane mode. The app should show loaders and clear offline messages, retry safely without duplicate actions and not freeze. Network throttling tools in developer options or proxy tools help simulate these conditions.
39
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.
40
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.
Tips to crack the Fidelity Investments Software Testing interview
Revise Java or Python, SQL and core CS subjects, and practise medium-level DSA problems for technical rounds.
Learn basic investment concepts like stocks, mutual funds and retirement accounts to understand the business domain.
Prepare behavioural answers on teamwork and learning, using clear STAR-format stories from projects or internships.
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; Fidelity Investments interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Fidelity Investments Software Testing interview?
Candidates usually go through 4 stages: Online coding assessment; Technical round 1 (DSA + language); Technical round 2 (design or domain); Managerial and 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 Fidelity Investments Software Testing interview?
This practice set leans on Automation Basics for Manual Testers (6), Test Case Design (6), Bug Life Cycle and Jira (5), Manual Testing Basics (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Fidelity Investments interviewers ask you to walk through real work.
Are these the exact questions asked at Fidelity Investments?
No. These are curated practice questions that match the skills and difficulty usually tested in banking & finance interviews like Fidelity Investments's. They are not a leaked or verified list of past questions.
Where does Fidelity Investments hire Software Testing professionals in India?
Fidelity Investments has large teams in Bengaluru, Chennai, Gurugram. Openings and locations change often, so check the Fidelity Investments careers page and filter by city and experience.