36 practice questions with answers for ISTQB interviews in Mumbai.
ISTQB jobs in Mumbai
Mumbai is India's financial capital, so banks, fintechs, insurers, media and consulting firms drive much of the hiring. Data and QA interviews often include domain questions on payments, risk, trading or customer analytics.
Below are 36 questions that match the mix of service, product and domain employers hiring manual test engineers in Mumbai.
Solved for MumbaiStart 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 difference between severity and priority?
Severity is the degree of impact the defect has on the system or its stakeholders, such as a crash or data loss. Priority is the urgency of fixing it, usually set by the business or product owner. Testers usually suggest severity, and priority is decided in triage. Example: a crash in a rarely used admin report is high severity but may be low priority.
02
How should you answer 'select TWO' questions in the CTFL exam?
Read the instruction carefully, because you must select exactly two options and usually get the point only if both are correct. Evaluate each option separately as true or false against the syllabus. Eliminate absolute statements and options that describe a different concept. If you are sure of one, compare the remaining options carefully. These questions appear in the exam, so practise them in sample papers.
03
An exam question asks for the 'best' answer and two options seem correct. How do you decide?
Re-read the stem for keywords such as 'most likely', 'best', 'first' or 'not'. Compare both options strictly against the syllabus wording, not your company's practice. Often one option is partly true or too absolute, using words like 'always' or 'guarantees'. Choose the option that fully matches the syllabus definition. Practising official sample exams builds this habit.
Automation saves time by reducing repetitive manual work such as regression runs, comparisons and data entry. It prevents simple human errors through greater consistency and repeatability. It gives more objective assessment, such as coverage, and access to measurements too complex for humans. It reduces test execution times, giving faster feedback and earlier defect detection, and frees testers to design new and deeper tests.
The two common formats are scenario-oriented, such as the Given/When/Then style used in BDD, and rule-oriented, such as a bullet-point verification list or a tabulated input-output mapping. Acceptance criteria define the scope of the story, reach consensus among stakeholders, describe positive and negative scenarios, serve as the basis for acceptance testing and support accurate planning and estimation. Teams can also use other formats as long as criteria are well defined and clear.
Situation: our team wrote test cases with no clear technique, and suites kept growing. Task: improve efficiency. Action: I applied equivalence partitioning and boundary value analysis to the form validations and used decision tables for pricing rules, removing redundant tests. Result: we cut the regression suite by about 30 percent while finding more boundary defects, and my lead asked me to train two juniors.
07
What is branch testing and how is branch coverage measured?
A branch is a transfer of control between two nodes in the control flow graph. Branches can be unconditional, like straight-line code, or conditional, like the true and false outcomes of an if or the cases of a switch. Branch coverage = branches exercised / total branches x 100. Branch testing designs tests so that every branch, including the hidden false path of an if without else, is exercised.
08
A field accepts integers from 5 to 15. List the 3-value BVA test values.
In 3-value BVA, each boundary gives the boundary value plus both neighbours. Lower boundary 5 gives 4, 5 and 6. Upper boundary 15 gives 14, 15 and 16. So the six values are 4, 5, 6, 14, 15 and 16. Compared with 2-value BVA (4, 5, 15, 16), the extra values 6 and 14 help detect mistakes in comparison operators inside the range.
Register through the ISTQB member board for India or an ISTQB-accredited exam provider. Create an account, choose CTFL v4.0, and pick either an online proctored exam or a test centre. For online exams, check your webcam, microphone and internet in advance, and keep a valid government photo ID ready. Results are usually shared soon after the exam, followed by the certificate.
10
How is configuration management handled in a DevOps environment?
In DevOps, configuration management is largely automated within the CI/CD pipeline. Source code, test scripts, pipeline definitions and infrastructure as code are all in version control. Each build gets a unique version, artefacts are stored in a repository, and environments are created from versioned templates. This makes test results reproducible and lets teams trace exactly which code, tests and configuration produced a given result.
11
Find the minimum tests for 100 percent statement and branch coverage of this code.
read(x)
if x > 10:
print('big')
print('done')
Statement coverage: one test with x = 15 executes every statement, so 1 test.
Branch coverage: the if has a true and a false outcome, so tests with x = 15 and x = 5 are needed, 2 tests.
12
Why does CTFL v4.0 recommend starting non-functional testing early?
Non-functional tests are often left to the end, but late discovery of performance or security problems can threaten the whole project. v4.0 recommends starting early, even at component level, for example measuring response time of a key service. Some tests need special environments such as a usability lab. Many non-functional tests reuse functional tests but measure a different quality, like checking login speed under 500 concurrent users.
13
How does a tester contribute to release and iteration planning?
In release planning, testers help write testable user stories and acceptance criteria, take part in product and quality risk analyses, estimate test effort for stories, define the test approach and plan release testing. In iteration planning, they join detailed risk analysis of stories, check testability, break stories into testing tasks, estimate testing effort and identify the functional and non-functional aspects to test.
14
Marks from 0 to 100 give: 0-39 fail, 40-59 pass, 60-100 distinction. How many partitions and 2-value boundary values are there?
Valid partitions: 0-39, 40-59 and 60-100, plus two invalid partitions: below 0 and above 100, so 5 partitions. Boundaries in 2-value BVA: -1, 0, 39, 40, 59, 60, 100 and 101, which is 8 values. Five tests give 100 percent EP coverage, and eight tests give 100 percent 2-value boundary coverage. Note that output partitions like fail, pass and distinction also guide the partitioning.
15
Your manager asks you to lower the severity of a defect to meet release targets. How do you respond?
Situation: before a release, my manager wanted a payment defect marked minor. Task: stay honest without creating conflict. Action: I explained the actual impact with data, how often it occurred and affected users, and suggested keeping severity accurate while lowering priority if the business accepted the risk, with a workaround documented. Result: the manager agreed, and the risk was recorded transparently.
Component testing checks individual units in isolation. Component integration testing checks interfaces and interactions between components. System testing checks overall behaviour, both functional and non-functional. System integration testing checks interfaces with other systems and external services. Acceptance testing focuses on validation and readiness for deployment. Each level has its own objectives, test basis, test objects, typical defects and responsibilities.
17
Testing found 80 defects and users found 20 more after release. What is the defect detection percentage?
DDP = defects found in testing / (defects found in testing + defects found after release) x 100
= 80 / (80 + 20) x 100
= 80 / 100 x 100
= 80 percent
So testing caught 80 percent of known defects. Tracking DDP across releases shows whether test effectiveness is improving.
18
What happens in test monitoring, test control and test completion?
Test monitoring gathers information about testing to check progress and whether exit criteria are met, using metrics like test case progress, defect counts, coverage and cost. Test control uses that information to give guidance and corrective actions, such as reprioritising tests or changing the schedule. Test completion collects data from finished activities to consolidate experience, testware and other information, usually at milestones like release or end of iteration.
19
Which work products can be examined by static testing?
Almost any work product that can be read and understood: requirements, user stories, acceptance criteria, architecture and design documents, source code, test plans, test cases, test charters, backlog items, contracts, project plans, schedules and budgets. Static analysis tools need work products with a formal structure, such as code or models with defined syntax. Products that are hard for humans to interpret, like third-party executable code, are not suitable for review.
20
How does decision table testing work, and how is coverage measured?
Decision tables model combinations of conditions and the resulting actions, which suits business rules. Each column is a rule: one combination of conditions with its actions. With n Boolean conditions, a full table has 2 to the power n columns. Coverage items are the feasible columns, so coverage is exercised columns divided by feasible columns. Tables can be minimised by merging columns where a condition does not affect the outcome, shown with a dash.
21
You join a Scrum team with two-week sprints. What testing activities would you do during a sprint?
I would join backlog refinement to review stories and acceptance criteria, help estimate test effort in sprint planning, write acceptance tests early, pair with developers on automation, test each story as soon as it is ready, keep regression running in the CI pipeline, run exploratory sessions on new features and share testing feedback in the retrospective. Testing runs continuously rather than at the end of the sprint.
22
Your tests achieved 100 percent branch coverage, yet users reported a defect. How is that possible?
Coverage shows which code was executed, not that the code is correct or complete. The defect may come from a missing requirement that was never coded, which white-box testing cannot detect; from specific data values not used in tests; from integration or environment issues; or from wrong expected results. Coverage is a useful measure of thoroughness, but it must be combined with black-box and experience-based techniques.
23
What are false positives and false negatives in testing?
A false positive is a test result that reports a defect when none exists, for example a test failing because of wrong test data or an unstable environment. A false negative is a test that passes even though a defect is present, so the defect is missed. False positives waste time and reduce trust in tests; false negatives are more dangerous because defects escape to production.
White-box testing considers the whole implementation, so it can find defects even when the specification is vague, outdated or incomplete. Coverage gives an objective measure of thoroughness. It can also be used in static testing, for example dry runs of code or pseudocode. Its main weakness is that it cannot detect omissions: if a requirement was never implemented, no white-box test will notice it.
25
A tester logs a defect titled 'Login broken' with no other details. How would you improve it?
A better title is 'Login - valid credentials - error 500 after clicking Sign in'. The report should add the build number and environment, browser and device, preconditions such as user type, numbered steps, test data used, expected result, actual result with the error message, a screenshot or log, severity, suggested priority, and a reference to the related test case. This lets a developer reproduce it immediately.
26
Tell me about a time testing was squeezed at the end of a sprint. What did you do?
Situation: stories reached me only in the last two days of each sprint. Task: stop testing from being a bottleneck. Action: I proposed writing acceptance criteria and test cases during refinement, asked developers to merge smaller stories earlier, and automated API checks in the CI pipeline. Result: within three sprints, carried-over stories fell from five to one, and the team added early testing to its definition of done.
In the whole team approach, any team member with the right knowledge can perform any task, and everyone is responsible for quality. The team shares a physical or virtual workspace, and testers work closely with business representatives to create acceptance tests and with developers to agree the test strategy and automation. It improves communication and uses combined skills, although safety-critical contexts may still need higher test independence.
28
Tell me about an exploratory testing session that found a critical defect.
Situation: a ticket booking app had passed all scripted tests. Task: run a one-hour exploratory session on seat selection. Action: I tried quick double taps, switching networks and booking the same seat from two devices. Result: two users could book the same seat. I logged a detailed report with videos, it was fixed before release, and concurrency tests were added to the regression suite.
29
What does a test plan contain according to CTFL v4.0?
A test plan typically covers: context of testing (scope, objectives, constraints, test basis); assumptions and constraints; stakeholders with roles and responsibilities; communication; a risk register of product and project risks; the test approach (test levels, types, techniques, deliverables, entry and exit criteria, independence, metrics, test data and environments); and budget and schedule. It documents how test objectives will be met and is updated as the project changes.
30
Production defects increased over the last three releases. How do you analyse and act?
I would categorise escaped defects by module, root cause and the test level that should have found them, and calculate defect detection percentage per release. Typical findings are missing regression coverage, unclear requirements or environment differences. Actions might include requirement reviews, adding regression tests for each escaped defect, improving test data and environment parity, and tracking the trend to confirm improvement.
31
Give an example of a high-severity low-priority defect and a low-severity high-priority defect.
High severity, low priority: the app crashes when exporting a report in a legacy format that almost nobody uses; the impact is severe but rarely triggered, so it can wait. Low severity, high priority: the company logo is misspelled on the home page before a major launch; functionality is unaffected, but brand impact makes it urgent. Severity reflects impact, priority reflects business urgency.
32
Your manual regression suite has not found a new defect for several releases. What do you do?
This points to the 'tests wear out' principle. I would review the suite against recent changes and defect data, refresh test data and steps, add tests for new features and risky areas, and run exploratory sessions to find new kinds of defects. Stable regression checks are still worth keeping and automating, because their job is to confirm unchanged areas still work, not to discover new defects.
33
Write a BDD scenario for locking an account after three failed login attempts.
Feature: Account lockout
Scenario: Lock account after three failed attempts
Given a registered user with an active account
When the user enters a wrong password 3 times in a row
Then the account is locked
And the message 'Account locked. Try again after 30 minutes' is shown
Given sets the context, When is the action and Then is the expected outcome.
The manager decides what is reviewed and provides resources. The author creates and fixes the work product. The moderator, or facilitator, ensures meetings run effectively, mediating and managing time. The scribe, or recorder, collects anomalies and records decisions. Reviewers perform the review and may be team members, experts or stakeholders. The review leader takes overall responsibility, deciding who is involved and organising the review. One person can hold several roles.
35
The product owner writes vague acceptance criteria such as 'search should work well'. What do you do?
I would suggest a short three-amigos session with the product owner and a developer. Together we would turn the vague criterion into testable ones, for example 'searching by product name returns matching items sorted by relevance', 'no results shows a helpful message' and 'results load in under 2 seconds'. Writing them as Given/When/Then scenarios makes them clear and ready for ATDD.
36
Which test estimation techniques are described in CTFL v4.0?
Estimation based on ratios uses historical figures, such as a development-to-test effort ratio. Extrapolation uses measurements from the current project, for example averaging the last three iterations. Wideband Delphi is an expert-based technique where experts estimate separately and iterate until consensus; Planning Poker is an Agile variant. Three-point estimation uses optimistic, most likely and pessimistic values to calculate a weighted estimate and its standard deviation.
Which companies hire ISTQB professionals in Mumbai?
Companies with large offices in Mumbai include TCS, Accenture, Capgemini, LTIMindtree, Hexaware, CGI. Use their company pages below to practise employer-specific sets.
Are ISTQB interviews in Mumbai different from other cities?
The questions depend more on the company than the city. Mumbai's mix of employers decides the style: Data and QA interviews often include domain questions on payments, risk, trading or customer analytics
How do I find ISTQB jobs in Mumbai?
Shortlist companies with Mumbai offices, keep your CV focused on ISTQB projects, apply on company career pages and job portals with the Mumbai filter, and practise the questions on this page before each interview.