36 practice questions with answers for ISTQB interviews in Kochi.
ISTQB jobs in Kochi
Kochi's Infopark and SmartCity host IT-services firms, product companies and start-ups, making it Kerala's largest tech job market along with Thiruvananthapuram. Testing and data roles are common in its service and product teams.
Below are 36 questions that match the mix of service, product and domain employers hiring manual test engineers in Kochi.
Solved for KochiStart 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
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.
02
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.
03
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.
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.
05
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'.
06
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.
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
Describe a time you led a test team through conflicting priorities.
Situation: two product owners wanted their features tested first in the same sprint. Task: decide fairly and keep the team focused. Action: I brought both to a short meeting, scored the features by business risk and release dates, and agreed a shared order with the delivery manager. I shared the plan with the team and tracked it daily. Result: both features shipped, and the risk-based method became our default.
09
An order can be placed, shipped, delivered, cancelled or returned. How would you test this workflow?
State transition testing fits because behaviour depends on the current state and events. I would draw the diagram, for example placed to shipped, shipped to delivered, placed to cancelled, delivered to returned, and build a state table. Tests cover every valid transition and attempt invalid ones, such as cancelling a delivered order or returning an undelivered one, checking the system rejects them correctly.
10
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.
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.
12
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.
13
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.
14
Tell me about a time you introduced a new tool to your team.
Situation: test cases lived in spreadsheets and traceability was poor. Task: introduce a test management tool. Action: I compared options with the team, ran a two-week pilot on one module, migrated priority test cases, built simple dashboards and ran short training sessions. Result: the team adopted it within a month, and release reports that took a day now took an hour.
15
Which good testing practices apply regardless of the SDLC model?
CTFL v4.0 lists these: for every software development activity there is a corresponding test activity; each test level has its own specific objectives; test analysis and design for a level begin during the corresponding development phase; and testers are involved in reviewing work products as soon as drafts are available. Together these practices support early testing and quality control in waterfall, V-model and Agile projects alike.
16
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.
17
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.
18
What is the difference between verification and validation?
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.
19
What is checklist-based testing and what are its risks?
In checklist-based testing, the tester designs and runs tests to cover the conditions on a checklist built from experience, user needs or knowledge of why software fails. Items should be specific and testable, not vague or automatable by tools. Checklists give some consistency and guidance when detailed test cases are missing, but they become less effective over time as developers learn to avoid those mistakes, so they must be updated regularly.
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.
21
Explain equivalence partitioning and its coverage.
Equivalence partitioning divides data into partitions whose values are expected to be processed the same way, so one value per partition is enough. Partitions can cover inputs, outputs, configuration items or time, and include valid and invalid partitions. They must be non-empty and must not overlap. Coverage is partitions exercised divided by partitions identified. With several inputs, Each Choice coverage requires every partition of every input to be used at least once.
22
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.
23
Model an ATM PIN entry with three attempts as states and transitions. How many tests are needed for valid transitions coverage?
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.
25
A production hotfix must go live in three hours. How do you decide what to test?
I would do a quick impact analysis to see what the change touches, run confirmation tests for the defect, then a risk-based regression subset covering the changed module, its integrations and critical business flows like login and payment. I would use the automated smoke suite in the pipeline, record what was not covered, and plan fuller regression in the next regular release.
26
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.
27
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.
28
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.
The test pyramid shows that tests have different granularity and that a healthy suite has many small, fast, isolated tests at the bottom, such as unit or component tests, and fewer large, slow, complex end-to-end tests at the top, such as UI tests. Middle layers often cover API or integration tests. The pyramid helps teams plan automation so the suite is fast, stable and cheap to maintain.
An informal review has no defined process or formal output and aims to detect anomalies. A walkthrough is led by the author and aims to educate, build consensus, generate ideas and detect anomalies. A technical review is done by technically qualified reviewers led by a moderator, aiming at consensus and technical decisions. An inspection is the most formal, follows the full process, collects metrics and aims to find the maximum number of anomalies.
31
Ten automated tests fail overnight, but the cause is an expired SSL certificate in the test environment. How should this be reported?
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.
32
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.
33
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.
34
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.
35
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.
36
What information does a defect report typically contain in CTFL v4.0?
A unique identifier; a title with a short summary; date observed, issuing organisation and author; the test object and test environment; context such as test case, test activity and test data; a description for reproduction with steps, logs, screenshots, and expected and actual results; severity; priority; status such as open, deferred, duplicate, re-opened, closed or rejected; and references, for example to the test case.
Which companies hire ISTQB professionals in Kochi?
Companies with large offices in Kochi include UST. Use their company pages below to practise employer-specific sets.
Are ISTQB interviews in Kochi different from other cities?
The questions depend more on the company than the city. Kochi's mix of employers decides the style: Testing and data roles are common in its service and product teams
How do I find ISTQB jobs in Kochi?
Shortlist companies with Kochi offices, keep your CV focused on ISTQB projects, apply on company career pages and job portals with the Kochi filter, and practise the questions on this page before each interview.