Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Mphasis hiring for ISTQB roles
Mphasis is an Indian IT services company, majority-owned by Blackstone, providing cloud, application, testing, data and cognitive services. It has a strong presence in banking, financial services and insurance clients. In India it hires for software engineers, test engineers, data analysts and data engineers, often for BFSI-focused projects.
For ISTQB roles, this Mphasis practice set focuses most on Fundamentals of Testing (7), Managing the Test Activities (6), Testing Throughout the SDLC (4), Test Tools and Exam Preparation (4). It has 14 easy, 15 medium, 1 hard questions, so you can start easy and work up to the harder ones.
Company type
IT services
Headquarters
Bengaluru, India
Main India offices
Bengaluru, Pune, Chennai
Mphasis ISTQB interview process
Online assessment (aptitude + reasoning)
Coding test
Technical interview
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for MphasisStart 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 test charter for an exploratory session on a checkout page.
Charter: Explore the checkout page with different coupon and payment combinations to discover pricing and rounding errors. Time box: 60 minutes. Focus areas: coupon stacking, expired coupons, quantity changes after applying a coupon, currency rounding, and using the browser back button. Record test ideas, defects, questions and areas covered. Debrief with the test lead after the session to agree next charters.
Shift-left means performing testing earlier in the SDLC. Practices include reviewing specifications from a tester's perspective, writing test cases before code, using CI/CD for fast feedback, running static analysis before dynamic testing and starting non-functional testing at component level. It costs extra effort early, but saves much more later, because a defect found in requirements is far cheaper to fix than one found in production.
03
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.
04
What do the K-levels K1, K2 and K3 mean in the CTFL syllabus?
K-levels describe the cognitive level of each learning objective. K1 is remember: recall a term or fact, such as listing test levels. K2 is understand: explain, compare, classify or give examples, such as distinguishing project and product risks. K3 is apply: use a procedure in a given situation, such as deriving boundary values or calculating a three-point estimate. Most exam questions are K2.
05
What types of defects are typically found by static testing?
Requirements defects such as inconsistencies, ambiguities, contradictions, omissions and duplicates; design defects like inefficient database structures or poor modularisation; coding defects such as variables with undefined values, unreachable or duplicated code and excessive complexity; deviations from standards; incorrect interface specifications; security vulnerabilities like buffer overflows; and gaps in test coverage, such as missing tests for an acceptance criterion.
06
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.
07
Discount depends on customer type (regular, gold, platinum) and whether the order exceeds 1,000 rupees. How many rules does the full decision table have?
When conditions are not Boolean, multiply the number of values of each condition. Customer type has 3 values and the order condition has 2, so the full table has 3 x 2 = 6 rules. Each rule becomes one test case for 100 percent decision table coverage. If, for example, platinum always gets the same discount regardless of amount, those two columns can be merged, giving 5.
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.
09
Classify as project or product risk: (a) test environment not ready on time, (b) report calculations may be wrong, (c) app may be slow on 4G, (d) budget is cut.
(a) Project risk, because it affects schedule and control of the project. (b) Product risk, because it concerns functional correctness of the product. (c) Product risk, because it concerns performance efficiency, a quality characteristic. (d) Project risk, because it affects resources and management. A simple test: if it is about the software's quality, it is a product risk; if it is about how the work is done, a project risk.
10
Name the main test activities in the ISTQB test process.
The test process has seven activity groups: test planning, test monitoring and control, test analysis, test design, test implementation, test execution and test completion. They are often iterative or done in parallel rather than strictly sequential. How they are carried out depends on context, such as the SDLC, product risks, budget, time, team skills and regulations, so an Agile team performs them in small loops in every iteration.
11
How do you prioritise risks using a likelihood and impact matrix?
Score each risk for likelihood and impact on a scale such as 1 to 5, and multiply to get the risk level. Example: wrong interest calculation, likelihood 3 and impact 5, level 15; slow report export, likelihood 4 and impact 2, level 8; spelling errors, 4 and 1, level 4. Test the highest levels first and most deeply, using more rigorous techniques and earlier test execution.
12
How does configuration management support testing?
Configuration management identifies, controls and tracks work products such as test plans, test cases, scripts, test results, test data, environments and the test object itself. It ensures all configuration items are uniquely identified, version controlled, tracked for changes and related to each other so traceability is kept. Baselines can only be changed through formal change control. This lets testers know exactly which build and testware versions were tested.
13
Historically, development and test effort are in the ratio 3:2. Development is estimated at 600 person-days. Estimate the test effort.
This is estimation based on ratios. Test effort = development effort x 2 / 3 = 600 x 2 / 3 = 400 person-days. The ratio must come from similar past projects in the same organisation, because it changes with domain, risk and process maturity. I would also cross-check with another technique, such as Wideband Delphi, before committing to the number.
14
What are the typical objectives of testing according to the ISTQB CTFL v4.0 syllabus?
Testing objectives include evaluating work products such as requirements and code, triggering failures and finding defects, ensuring required coverage of the test object, reducing the risk of poor quality, verifying that specified requirements are met, checking compliance with contracts or regulations, giving stakeholders information for decisions, building confidence in quality, and validating that the test object works as users expect. Objectives vary with context, test level and the SDLC model.
15
Build a decision table for a loan rule: approve if salary is at least 30,000 and credit score is at least 700; refer if only one is met; otherwise reject.
Conditions R1 R2 R3 R4
Salary >= 30000 T T F F
Score >= 700 T F T F
Actions
Approve X - - -
Refer to officer - X X -
Reject - - - X
Two Boolean conditions give 2 x 2 = 4 rules, so 4 test cases give 100 percent decision table coverage.
16
How do you use the ISTQB glossary to prepare effectively?
Each learning objective lists keywords that you must know. Make flashcards for them with the exact glossary definition and one example from your own work, such as 'test basis: the user story for checkout'. Review them daily with spaced repetition. Pay attention to similar terms, like test condition versus test case, and confirmation versus regression testing, because exams use them as distractors.
17
A review is led by the author, and its goals are to educate the team and reach consensus. Which review type is it?
It is a walkthrough. Walkthroughs are led by the author, and their objectives include educating reviewers, building consensus, generating new ideas, motivating authors and detecting anomalies. Individual preparation is optional. If a trained moderator led it with technical experts to make technical decisions, it would be a technical review; if it followed a fully formal process with metrics, it would be an inspection.
18
What are entry and exit criteria? How do they relate to Definition of Ready and Definition of Done?
Entry criteria define preconditions for starting an activity, such as available resources, testware, a stable build and a test environment. Exit criteria define what must be achieved to finish, such as coverage reached, unresolved defect counts, defect density and passed tests. Running out of time or budget can also be a valid exit. In Agile, exit criteria are often called the Definition of Done and entry criteria for a story the Definition of Ready.
19
Why is traceability between the test basis and testware important?
Traceability links test basis items such as requirements, risks and user stories to test conditions, test cases, results and defects. It lets teams measure coverage, assess the impact of changes, support audits in regulated domains and report progress in business terms, for example 'requirement R12 has three passed tests and one open defect'. When a requirement changes, traceability shows exactly which tests must be updated or re-run.
It is a misconception that verifying software thoroughly and fixing every found defect guarantees success. A system can pass every test against its specification and still be useless if the specification was wrong or the users' real needs were missed. That is why testing must include validation as well as verification, for example early review of requirements with business stakeholders and user acceptance testing before release.
21
A developer misreads a tax rule, codes the wrong formula, and a customer later sees an incorrect invoice total. Identify the error, defect and failure.
The error is the human mistake: the developer misreading the tax rule. The defect is the wrong formula in the code. The failure is the incorrect invoice total seen when the code runs. The root cause might be an ambiguous requirement or time pressure. Remember for the exam that not every defect causes a failure; it does so only when the defective code executes under certain conditions.
22
A manager says, 'Testing found zero defects in this release, so the software is defect-free.' How do you respond?
Testing shows the presence of defects, not their absence, so finding none only reduces the probability of undiscovered defects. I would also raise the absence-of-defects fallacy: did our tests cover real user needs? I would share coverage data, untested risk areas and whether our tests may have worn out. A more accurate statement is 'no defects were found within the agreed coverage and risk scope'.
A defect report gives the people responsible for handling and resolving the defect enough information to fix it. It also provides a way to track the quality of the work product, and it offers ideas for improving the development and test processes. A good report is clear, reproducible and neutral in tone, so that developers can act on it quickly and managers can analyse trends.
24
Why is not every failed test a defect in the software?
A failure can be caused by the test itself or the environment, not the test object. Common causes include wrong expected results, outdated test data, incorrect test scripts, misconfigured environments, network issues or unavailable third-party services. CTFL v4.0 therefore talks about anomalies, which are analysed before being reported as defects. Logging every failure as a defect without analysis creates false positives and wastes developer time.
1) Testing shows the presence, not the absence, of defects. 2) Exhaustive testing is impossible, so use test techniques, prioritisation and risk. 3) Early testing saves time and money. 4) Defects cluster together in a few components. 5) Tests wear out, so update them or write new ones. 6) Testing is context dependent. 7) Absence-of-defects fallacy: a defect-free system can still fail if it does not meet user needs.
A retrospective is held at the end of an iteration, release or project to discuss what went well, what did not and how to improve. For testing, the benefits include more effective and efficient testing, better testware, team bonding, better quality of the test basis and stronger cooperation between developers and testers. Results should be recorded and the improvement actions tracked so that they are actually carried out.
27
How does acceptance test-driven development (ATDD) work?
ATDD is a test-first approach. The team, including business, developers and testers, analyses the story and acceptance criteria in a specification workshop, then writes test cases before implementation. Positive tests come first, then negative tests and non-functional characteristics. Tests are written in a form stakeholders understand, cover every criterion without going beyond the story, and are often automated so they become executable requirements.
28
Your CI pipeline takes two hours because most automated tests are UI tests. What do you suggest?
The suite looks like an inverted test pyramid. I would push checks down: move business logic checks to unit tests, cover service rules with API tests, and keep only a small set of end-to-end UI tests for critical user journeys. I would also run tests in parallel and split suites into a fast smoke stage and a fuller nightly run. Feedback becomes faster and tests less flaky.
All three are test-first approaches. In TDD, developers write a failing unit test, write code to pass it, then refactor. In ATDD, acceptance tests are derived from acceptance criteria with the team and business before development starts. In BDD, desired behaviour is written as Given/When/Then scenarios in natural language that stakeholders understand and that can be turned into executable tests. All three support shift-left.
In sequential models like waterfall and the V-model, testers join early for reviews and planning, but dynamic testing happens later once code exists. In iterative and incremental models such as Scrum, every iteration delivers a working increment, so static and dynamic testing happen at all levels in each iteration, regression testing is critical and automation is usually needed. The model affects scope, timing, documentation, techniques and automation.
Tips to crack the Mphasis ISTQB interview
Learn BFSI basics such as banking transactions, insurance claims and mortgages, since many Mphasis clients are in this domain.
Revise testing concepts, SQL and one programming language well for technical interviews.
Read about Mphasis's Front2Back transformation approach, which the company uses to describe its service model.
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; Mphasis interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Mphasis ISTQB interview?
Candidates usually go through 4 stages: Online assessment (aptitude + reasoning); Coding test; Technical interview; 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 Mphasis ISTQB interview?
This practice set leans on Fundamentals of Testing (7), Managing the Test Activities (6), Testing Throughout the SDLC (4), Test Tools and Exam Preparation (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Mphasis interviewers ask you to walk through real work.
Are these the exact questions asked at Mphasis?
No. These are curated practice questions that match the skills and difficulty usually tested in it services interviews like Mphasis's. They are not a leaked or verified list of past questions.
Where does Mphasis hire ISTQB professionals in India?
Mphasis has large teams in Bengaluru, Pune, Chennai. Openings and locations change often, so check the Mphasis careers page and filter by city and experience.