36 practice questions with answers for ISTQB interviews in Jaipur.
ISTQB jobs in Jaipur
Jaipur has a growing IT and IT-enabled services market, with delivery centres, SaaS start-ups and back-office analytics teams around Sitapura and Mahindra World City. Many candidates here also apply to remote and hybrid roles with Delhi NCR teams.
Below are 36 questions that match the mix of service, product and domain employers hiring manual test engineers in Jaipur.
Solved for JaipurStart 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 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.
02
What is the difference between the test management role and the testing role in CTFL v4.0?
v4.0 describes roles, not job titles. The test management role owns the test process, the test team and leadership of test activities, mainly planning, monitoring and control, and completion. The testing role owns the engineering side: test analysis, design, implementation and execution. One person can hold both roles, and in Agile teams some management tasks are done by the team while cross-team coordination may sit with a test manager.
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.
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.
05
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.
06
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.
07
The requirements say the system must be 'fast' and 'user-friendly'. What do you do?
I would log these as anomalies in a review because they are not testable. I would ask stakeholders for measurable criteria, for example 'search results appear within 2 seconds for 95 percent of requests at 1,000 concurrent users' and 'a new user completes registration in under three minutes without help'. Testable requirements make test design, acceptance and sign-off objective and prevent disputes later.
08
Tell me about a time you convinced developers to adopt a code coverage quality gate.
Situation: escaped defects kept coming from untested code paths. Task: improve unit testing without slowing the team. Action: I showed coverage reports linking low-coverage modules to production defects, proposed a gate of 80 percent branch coverage on new code only, and helped write the first tests. Result: within two months coverage on changed code rose sharply and escaped defects in those modules fell.
09
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.
10
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.
11
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.
12
Explain defect density and defect detection percentage.
Defect density is the number of defects per unit of size, such as per thousand lines of code or per function point. It helps find defect clusters and compare components. Defect detection percentage (DDP) is defects found by testing divided by all defects found, including those found after release, times 100. A falling DDP means more defects are escaping, which signals weaker test effectiveness.
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.
14
Give a checklist you would use to review a user story.
Is it written as 'As a [role], I want [goal], so that [benefit]'? Does it follow INVEST: independent, negotiable, valuable, estimable, small and testable? Are acceptance criteria clear, measurable and testable? Are error flows and edge cases covered? Are terms consistent with the glossary? Are dependencies and non-functional needs stated? Are vague words like 'quickly' or 'etc.' present? Log each anomaly with location, description and a suggestion.
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.
16
A developer says one value per partition is enough. Why might you still add boundary tests?
Equivalence partitioning assumes all values in a partition behave the same, but many defects occur at the edges, where developers write '>' instead of '>=' or use the wrong limit. One middle value like 35 in an 18 to 60 range will never reveal these. Boundary value analysis adds tests at 17, 18, 60 and 61, so the two techniques together give good coverage with few tests.
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.
18
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'.
19
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.
20
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.
21
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.
22
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.
23
Testers spent a day testing the wrong build version. How do you prevent this?
This is a configuration management failure. I would ensure every build has a unique version shown in the application and in the release notes, that deployments to test environments are automated and logged, and that test runs record the build version tested. Entry criteria should include confirming the build version. A deployment notification in the team channel also helps everyone stay aligned.
24
Derive test conditions for the requirement 'Users can transfer up to 50,000 rupees per day.'
Read the test basis and list testable aspects. Conditions: a transfer within the limit succeeds; a transfer of exactly 50,000 succeeds; a transfer above 50,000 is rejected with a clear message; several transfers in one day are added together against the limit; the limit resets the next day; zero or negative amounts are rejected. Prioritise them by risk, then design test cases with exact amounts using boundary value analysis.
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.
26
A new tester has no domain knowledge and no detailed test cases. How can checklists help, and what is the risk?
A checklist of high-level conditions, such as validations, error messages, navigation and security basics, gives the new tester structure and consistency while learning the domain. Each run can vary slightly, which increases coverage. The risk is that checklists wear out as developers learn to avoid listed defects, so the team should update them with new defect patterns and pair the tester with an experienced colleague.
27
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.
28
A password must be 8 to 16 characters long. What are the 2-value BVA tests?
The partitions by length are 0 to 7 (invalid), 8 to 16 (valid) and 17 or more (invalid). 2-value BVA takes each boundary and its closest neighbour: 7 and 8 for the lower boundary, 16 and 17 for the upper boundary. So test passwords of length 7, 8, 16 and 17 characters, keeping other rules such as character types valid so only the length varies.
29
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.
30
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.
31
How are CTFL v4.0 exam questions distributed across chapters?
Approximately: Chapter 1, Fundamentals of Testing, 8 questions; Chapter 2, Testing Throughout the SDLC, 6; Chapter 3, Static Testing, 4; Chapter 4, Test Analysis and Design, 11; Chapter 5, Managing the Test Activities, 9; Chapter 6, Test Tools, 2. Chapters 4 and 5 carry half the marks and include most K3 questions, so practise techniques and estimation thoroughly.
32
How many tests are needed for full statement and branch coverage of this nested code?
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.
33
The requirements are incomplete and release is in two days. How do you test?
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.
34
How does component integration testing differ from system integration testing?
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.
35
Your defect tracker is full of duplicate defects from several testers. How do you fix this?
I would set up a short daily triage to merge duplicates and link them to one master defect. Testers should search existing defects by module and keywords before logging, and use clear titles in a standard format such as 'Module - action - result'. Defined components and labels make searching easier. Tracking duplicate rates also shows whether the guidance is working.
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.
Which companies hire ISTQB professionals in Jaipur?
Companies with large offices in Jaipur include Nagarro. Use their company pages below to practise employer-specific sets.
Are ISTQB interviews in Jaipur different from other cities?
The questions depend more on the company than the city. Jaipur's mix of employers decides the style: Many candidates here also apply to remote and hybrid roles with Delhi NCR teams
How do I find ISTQB jobs in Jaipur?
Shortlist companies with Jaipur offices, keep your CV focused on ISTQB projects, apply on company career pages and job portals with the Jaipur filter, and practise the questions on this page before each interview.