Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About LTIMindtree hiring for ISTQB roles
LTIMindtree is an Indian IT services and consulting company formed by the merger of Larsen and Toubro Infotech and Mindtree, and part of the L&T Group. It provides cloud, data, ERP, testing and digital engineering services for global clients. It hires for software engineers, test engineers, data analysts, data engineers and ERP consultants.
For ISTQB roles, this LTIMindtree practice set focuses most on Static Testing (6), Fundamentals of Testing (6), Testing Throughout the SDLC (4), Black-Box Test Techniques (3). It has 16 easy, 14 medium questions, so you can start easy and work up to the harder ones.
Company type
IT services
Headquarters
Mumbai, India
Main India offices
Mumbai, Pune, Bengaluru, Chennai, Hyderabad
LTIMindtree 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 LTIMindtreeStart 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.
Define clear objectives and measurable exit criteria; pick a review type that fits the objective, work product and people; review small chunks so reviewers stay focused; give feedback to authors so they improve; allow enough preparation time; secure management support; make reviews part of the culture to promote learning; and train participants for their roles. Review results must never be used to evaluate the performance of individuals.
02
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.
03
What is the difference between testing and debugging?
Testing triggers failures caused by defects (dynamic testing) or finds defects directly in work products (static testing). Debugging is a development activity that reproduces a failure, diagnoses the root cause and fixes the defect. After the fix, testers run confirmation testing to check the fix and regression testing to check nothing else broke. In short, testing finds and reports problems, while debugging locates and removes them.
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.
05
Explain error, defect, failure and root cause with an example.
A human makes an error (mistake), for example misreading a requirement. The error produces a defect (fault or bug) in a work product such as code or a document. When defective code is executed it may cause a failure, meaning the system does something wrong or fails to do something. The root cause is the fundamental reason for the error, such as time pressure or unclear requirements. Failures can also come from environmental conditions like radiation.
06
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.
07
How do you report test status to non-technical stakeholders?
I focus on decisions they need to make. I use a short dashboard: overall status in plain words, coverage of key requirements, open critical defects and their business impact, top risks with mitigation, and what is needed from them. I avoid jargon, use simple charts and trends, and keep detailed data available for anyone who wants it. Different audiences may need different levels of detail.
08
Business users test a new payroll system in their own office before go-live. What kind of testing is this?
This is user acceptance testing, because intended users validate that the system meets their needs in a realistic environment before deployment. If it were a commercial product released to external customers at their own sites for feedback, it would be beta testing. If potential users tested it at the developer's site, it would be alpha testing. Look for who tests and where.
09
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.
10
Why does 100 percent branch coverage guarantee 100 percent statement coverage, but not the other way round?
Every statement lies on at least one branch, so exercising all branches executes all statements. The reverse fails when a decision has an empty outcome. Example: 'if x > 10: print(big)' followed by 'print(done)'. One test with x = 15 runs every statement, giving 100 percent statement coverage, but the false branch is never taken, so branch coverage is only 50 percent. This is called subsumption.
11
Match these tasks to test activities: identifying test conditions, creating test data and suites, comparing actual and expected results, archiving testware.
Identifying and prioritising test conditions is test analysis. Creating test data, arranging test procedures and assembling test suites is test implementation. Running tests and comparing actual with expected results is test execution. Archiving testware, handing it over and recording lessons learned is test completion. Exams often mix design and implementation: designing test cases is test design, while preparing them to run is implementation.
12
Tell me about a time you missed a defect. What did you learn?
Situation: a defect in date formatting reached production after my testing. Task: understand why and prevent it. Action: I owned the miss, found my test data used only one locale, and added test cases for other date formats and locales. I also shared a checklist for locale testing. Result: no similar defect appeared in later releases, and I learned to review my test data as carefully as my test steps.
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.
14
How do you learn from sample exams instead of just counting your score?
After each timed attempt, review every question, including correct guesses. For each mistake, note the learning objective, the chapter and why the right option is correct in the syllabus text. Group mistakes by chapter to find weak areas, re-read those sections, and redo similar questions after a few days. Aim for consistent scores of 32 or more out of 40 before the real exam.
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.
16
A quantity field accepts 1 to 100. List the 2-value BVA test values.
The valid partition is 1 to 100, with invalid partitions below and above it. For each boundary, take the boundary and its closest neighbour in the adjacent partition. Lower boundary: 0 and 1. Upper boundary: 100 and 101. So 2-value BVA needs four values: 0, 1, 100 and 101, and four test cases give 100 percent 2-value boundary coverage.
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.
18
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.
19
What is risk, and how do project risks differ from product risks?
A risk is a potential event or condition whose occurrence causes an adverse effect. Risk level is determined by likelihood and impact. Project risks affect the management and control of the project, such as staff shortages, delays, budget cuts, vendor problems or tool issues. Product risks relate to quality characteristics of the product, such as missing functionality, wrong calculations, slow response, poor security or bad usability.
20
In a review, what is the difference between an anomaly and a defect?
Reviewers log anomalies: observations that differ from what they expected. Not every anomaly is a defect; some turn out to be misunderstandings, open questions or improvement suggestions. During communication and analysis the team decides each anomaly's status, owner and required action, and confirmed ones become defects for the author to fix. This keeps reviews constructive instead of treating every comment as the author's mistake.
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.
22
Why is early and frequent stakeholder feedback important?
Early and frequent feedback catches misunderstandings about requirements before they become expensive. Without it, the product may not match what stakeholders want, leading to costly rework, missed deadlines, blame games and even project failure. Regular feedback through reviews, demos and backlog refinement keeps the team focused on the most valuable features and builds a shared understanding of what is being built.
23
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.
24
Which black-box test techniques are covered in CTFL v4.0?
CTFL v4.0 covers four black-box techniques: equivalence partitioning, boundary value analysis (2-value and 3-value), decision table testing and state transition testing. They derive tests from the specification without looking at the internal structure, so tests stay valid even when the implementation changes. Use case testing, which was in older syllabi, is no longer part of the v4.0 Foundation syllabus.
25
What is the difference between confirmation testing and regression testing?
Confirmation testing checks that an original defect has been fixed, by re-running the failed tests or new tests that cover the change. Regression testing checks that a change, including a fix, has not caused adverse effects elsewhere, in the same component, connected components or the environment. Regression suites grow and run often, so they are strong candidates for automation, typically inside a CI pipeline.
26
What is static testing and how is it different from dynamic testing?
Static testing examines work products without executing them, through manual reviews or static analysis tools. Dynamic testing executes the software. Static testing finds defects directly, such as ambiguous requirements or coding standard violations, while dynamic testing causes failures whose defects are then located by debugging. Static testing works on non-executable products like requirements and test plans, and finds defects dynamic testing cannot, such as unreachable code.
Test analysis answers 'what to test': it analyses the test basis, identifies testable features, defines and prioritises test conditions, and evaluates the test basis for defects. Test design answers 'how to test': it turns test conditions into test cases, identifies coverage items, defines test data requirements and designs the test environment. Example: the condition 'login with a locked account' becomes, in design, a case with exact inputs and the expected error message.
Functional testing checks what the system should do, covering completeness, correctness and appropriateness. Non-functional testing checks how well it behaves, using ISO/IEC 25010 characteristics such as performance efficiency, usability, security, reliability, compatibility, maintainability and portability. Black-box testing is specification-based, and white-box testing is structure-based. Any test type can be applied at any test level, with a different focus at each.
29
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.
30
Why did you decide to take the ISTQB Foundation certification?
Model answer: I wanted a structured base in testing rather than learning only from tools. The CTFL syllabus taught me standard terms, test techniques like boundary value analysis and decision tables, and how testing fits into Agile and DevOps. It is recognised across many countries, so it helps me communicate with global teams. Preparing for it also improved how I write test cases and defect reports.
Tips to crack the LTIMindtree ISTQB interview
Practise aptitude, logical reasoning and basic coding questions, as the online assessment is usually the first filter.
Revise SQL, OOP and testing fundamentals, plus any cloud or data tools you list on your resume.
Learn about the L&T Group background and the LTI and Mindtree merger to answer company-related questions.
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; LTIMindtree interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the LTIMindtree 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 LTIMindtree ISTQB interview?
This practice set leans on Static Testing (6), Fundamentals of Testing (6), Testing Throughout the SDLC (4), Black-Box Test Techniques (3). Revise those first, then practise explaining one or two of your own projects end to end, because most LTIMindtree interviewers ask you to walk through real work.
Are these the exact questions asked at LTIMindtree?
No. These are curated practice questions that match the skills and difficulty usually tested in it services interviews like LTIMindtree's. They are not a leaked or verified list of past questions.
Where does LTIMindtree hire ISTQB professionals in India?
LTIMindtree has large teams in Mumbai, Pune, Bengaluru, Chennai, Hyderabad. Openings and locations change often, so check the LTIMindtree careers page and filter by city and experience.