Skip to content

ISTQB Interview Questions in Gurgaon

36 practice questions with answers for ISTQB interviews in Gurgaon.

ISTQB jobs in Gurgaon

Gurgaon (Gurugram) is home to many multinational, consulting, fintech and consumer-internet offices. Interviews often expect strong business understanding along with technical skills, especially for analytics and product-facing roles.

Below are 36 questions that match the mix of service, product and domain employers hiring manual test engineers in Gurgaon.

Solved for GurgaonStart 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

Explain collaborative user story writing, the 3 Cs and INVEST.

Save to ▾
Show answer
User stories are written collaboratively by business, development and testing. The 3 Cs are Card (the medium describing the story), Conversation (how the story will be used, documented or verbal) and Confirmation (the acceptance criteria). A good story follows INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable. If stakeholders cannot say how to test a story, it is probably unclear or does not reflect real value.
02

Show two defects a static analysis tool can find without running the code.

Save to ▾
Show answer
def get_discount(amount): if amount > 1000: rate = 0.1 return amount * rate # rate undefined when amount <= 1000 def old_helper(): return 0 print('done') # unreachable code The tool flags a possibly undefined variable, a data flow anomaly, and unreachable code. Both are found statically, before any test is executed.
03

Write a test charter for an exploratory session on a checkout page.

Save to ▾
Show answer
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.
04

How many tests are needed for full statement and branch coverage of this nested code?

Save to ▾
Show answer
if a > 0: if b > 0: s1 else: s2 else: s3 Statement coverage needs 3 tests, because s1, s2 and s3 are on different paths. Branch coverage also needs 3: (a > 0, b > 0), (a > 0, b <= 0) and (a <= 0). With full if-else structures, both criteria need the same number of tests.
05

An exam question asks for the 'best' answer and two options seem correct. How do you decide?

Save to ▾
Show answer
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.
06

Describe the activities of the review process in CTFL v4.0.

Save to ▾
Show answer
Planning defines scope, purpose, quality characteristics, exit criteria, effort and timeframe. Review initiation ensures everyone has access and is ready. In individual review, each reviewer assesses the work product and logs anomalies, recommendations and questions. Communication and analysis discusses anomalies and decides their status and actions. Fixing and reporting creates defect reports, the author fixes them, and results are reported against exit criteria.
07

How did you give feedback on a senior colleague's document that had many issues?

Save to ▾
Show answer
Situation: a senior architect's design missed several error-handling flows. Task: give feedback respectfully. Action: I grouped comments by theme, framed them as questions with concrete examples, noted the strong sections, and offered to discuss in person rather than only posting comments. Result: he accepted most points, appreciated the clear feedback, and later invited me to review his designs earlier.
08

What makes an inspection different from other review types?

Save to ▾
Show answer
Inspection is the most formal review type. It follows the complete review process, uses defined roles and checklists, requires individual preparation, applies entry and exit criteria, and collects metrics such as anomalies found per page to improve both the development and inspection processes. The author cannot act as review leader or scribe. It suits safety-critical and high-risk work products, but it costs the most effort.
09

Find the minimum tests for statement and branch coverage when there are two independent if statements in sequence.

Save to ▾
Show answer
if a > 0: s1 if b > 0: s2 Statement coverage: one test with a = 1 and b = 1 runs s1 and s2, so 1 test. Branch coverage: each if needs a true and a false outcome. Tests (a = 1, b = 1) and (a = 0, b = 0) cover all four branches, so 2 tests.
10

Exit criteria are not met, but the business wants to release tomorrow. What do you do?

Save to ▾
Show answer
Testers provide information; the release decision belongs to stakeholders. I would prepare a short report showing which criteria are not met, open defects by severity, untested areas and the resulting risks, with possible mitigations such as feature flags, hotfix readiness or limited rollout. If stakeholders accept the risk, I would record the decision and the residual risks in the completion report.
11

How does component integration testing differ from system integration testing?

Save to ▾
Show answer
Component integration testing focuses on interfaces between components of the same system and is usually done by developers or testers who know the architecture, often with stubs and drivers. System integration testing focuses on interfaces with other systems and external services, such as payment gateways or government APIs, and needs production-like environments. Incremental integration, top-down or bottom-up, is preferred over big-bang because it localises defects.
12

What is the value of static testing?

Save to ▾
Show answer
Static testing detects defects in the earliest phases, when they are cheapest to fix. It finds defects that dynamic testing cannot, such as unreachable code or defects in non-executable work products. It helps evaluate quality and build confidence, improves shared understanding among stakeholders, and gives fast feedback on code through static analysis in CI. Reviews cost effort, but the total cost of quality is usually lower.
13

A defect you closed last week appears again in a new build. What could be the cause and what do you do?

Save to ▾
Show answer
Possible causes include a code merge that overwrote the fix, a fix made only in one branch, or a deployment of an older artefact. I would re-open the defect with evidence and the build numbers, ask the team to check version control history, and add an automated regression test for the defect so it is caught immediately if it returns again.
14

A field accepts integers from 5 to 15. List the 3-value BVA test values.

Save to ▾
Show answer
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.
15

The requirements are incomplete and release is in two days. How do you test?

Save to ▾
Show answer
I would use session-based exploratory testing. I would write short charters for the riskiest areas, agree priorities with the product owner, run time-boxed sessions, note defects and questions, and debrief after each session. I would add error guessing for common failure types and a quick checklist for critical flows, and report clearly which areas were covered and which risks remain.
16

Which black-box test techniques are covered in CTFL v4.0?

Save to ▾
Show answer
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.
17

Why is traceability between the test basis and testware important?

Save to ▾
Show answer
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.
18

A key tester resigns and a vendor will deliver a module late. How do you treat these risks?

Save to ▾
Show answer
Both are project risks. For the resignation, I would mitigate by documenting knowledge, pairing another tester for a handover and adjusting assignments; a contingency plan could be a short-term contractor. For the vendor delay, I would monitor delivery dates, prepare stubs to test our side, reorder testing to start other modules first and agree a contingency with management.
19

How does testing relate to quality assurance and quality control?

Save to ▾
Show answer
Testing is a form of quality control (QC): a product-oriented, corrective approach that checks work products. Quality assurance (QA) is process-oriented and preventive: it improves processes on the idea that a good process produces a good product. Test results are used by both. QC uses them to fix defects, and QA uses them as feedback on how well the development and test processes are performing.
20

What is the difference between verification and validation?

Save to ▾
Show answer
Verification checks whether the system meets its specified requirements: 'Are we building the product right?' Validation checks whether the system meets user and stakeholder needs in its operational environment: 'Are we building the right product?' Both are testing objectives. Example: verification confirms the eight-character password rule is implemented, while validation checks that real users can actually register easily on a mobile phone.
21

Ten automated tests fail overnight, but the cause is an expired SSL certificate in the test environment. How should this be reported?

Save to ▾
Show answer
These failures are caused by the environment, not the test object, so they should not be logged as product defects. I would raise one environment issue with the infrastructure team, mark the test results as blocked or environment failure, and re-run after the certificate is renewed. I would also suggest monitoring certificate expiry so the same false positives do not recur.
22

Historically, development and test effort are in the ratio 3:2. Development is estimated at 600 person-days. Estimate the test effort.

Save to ▾
Show answer
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.
23

You identified 6 equivalence partitions and your tests exercise 4 of them. What is the coverage? Does adding a second test in the same partition help?

Save to ▾
Show answer
EP coverage = exercised partitions / identified partitions x 100 = 4 / 6 x 100 = 66.7 percent. Adding another test in an already covered partition does not increase coverage, because coverage counts partitions, not tests. To reach 100 percent you need tests in the two missing partitions. Exams often include such distractors to see if you count tests instead of coverage items.
24

A review meeting turns into people blaming the author. How do you handle it as moderator?

Save to ▾
Show answer
I would refocus the discussion on the work product, not the person, remind everyone of the review objectives, and record the anomaly neutrally. Afterwards I would speak privately with the people involved. To prevent repeats, I would set ground rules, train participants and make sure review results are never used to judge individuals. Authors in a safe culture share work openly, so reviews find more defects.
25

What happens in test monitoring, test control and test completion?

Save to ▾
Show answer
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.
26

Your tests achieved 100 percent branch coverage, yet users reported a defect. How is that possible?

Save to ▾
Show answer
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.
27

What are the objectives of a defect report?

Save to ▾
Show answer
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.
28

Which test estimation techniques are described in CTFL v4.0?

Save to ▾
Show answer
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.
29

What are the risks of test automation?

Save to ▾
Show answer
Unrealistic expectations about what a tool can do; inaccurate estimates of the time, cost and effort to introduce and maintain it; using a tool where manual testing is better; relying on the tool too much and ignoring critical thinking; dependency on the tool vendor, which may go out of business or retire the tool; open-source tools being abandoned; and tools not compatible with the development platform or not meeting regulations.
30

What is risk, and how do project risks differ from product risks?

Save to ▾
Show answer
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.
31

What are the five test levels in CTFL v4.0?

Save to ▾
Show answer
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.
32

What is branch testing and how is branch coverage measured?

Save to ▾
Show answer
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.
33

How should you answer 'select TWO' questions in the CTFL exam?

Save to ▾
Show answer
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.
34

Why does CTFL v4.0 recommend starting non-functional testing early?

Save to ▾
Show answer
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.
35

How do you learn from sample exams instead of just counting your score?

Save to ▾
Show answer
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.
36

A test suite executes 8 of 10 executable statements and 3 of 4 branches. What are the coverage figures?

Save to ▾
Show answer
Statement coverage = 8 / 10 x 100 = 80 percent. Branch coverage = 3 / 4 x 100 = 75 percent. To raise them, look at the control flow graph to see which statements and which branch outcome were missed, then design inputs that force execution down those paths. Coverage tools in CI pipelines report these numbers automatically for each build.

Companies with offices in Gurgaon (3)

Frequently asked questions

Which companies hire ISTQB professionals in Gurgaon?

Companies with large offices in Gurgaon include Accenture, Nagarro, EPAM Systems. Use their company pages below to practise employer-specific sets.

Are ISTQB interviews in Gurgaon different from other cities?

The questions depend more on the company than the city. Gurgaon's mix of employers decides the style: Interviews often expect strong business understanding along with technical skills, especially for analytics and product-facing roles

How do I find ISTQB jobs in Gurgaon?

Shortlist companies with Gurgaon offices, keep your CV focused on ISTQB projects, apply on company career pages and job portals with the Gurgaon filter, and practise the questions on this page before each interview.