Fundamentals of Testing Interview Questions for ISTQB

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.

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.

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.

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.

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.

A small number of components usually contain most of the defects or cause most operational failures, similar to the Pareto principle. Predicted and observed defect clusters are an important input to risk-based testing, so testers focus more effort on those areas. Example: in a banking app, the interest calculation and payment modules may hold most reported defects, so they get deeper and more frequent regression coverage.

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.

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.

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.

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.

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.

In v4.0 the old 'pesticide paradox' was renamed 'tests wear out'. If the same tests are repeated many times, they become less effective at finding new defects because the code they exercise has already been fixed. Testers should modify existing tests and test data and write new tests. The exception is automated regression testing, where repeating the same tests is valuable because the goal is to confirm nothing has broken.

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.

Testware is any work product created during the test process. Examples: test plan and risk register from planning; progress reports and control directives from monitoring and control; prioritised test conditions from analysis; test cases, test charters and coverage items from design; test procedures, automated scripts, test suites and test data from implementation; test logs and defect reports from execution; and the test completion report with lessons learned from completion.

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.

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.

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.

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'.

This points to the 'tests wear out' principle. I would review the suite against recent changes and defect data, refresh test data and steps, add tests for new features and risky areas, and run exploratory sessions to find new kinds of defects. Stable regression checks are still worth keeping and automating, because their job is to confirm unchanged areas still work, not to discover new defects.

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.

Collect the failure details and logs, reproduce the issue and identify the defect. Then ask 'why' repeatedly until you reach a process cause. Example: a wrong discount was shown; why? the code used an old rule; why? the requirement changed without notice; why? there was no change review step. Action: add change notifications and a review step. Fixing root causes prevents whole families of similar defects.

Situation: while testing our final-year e-commerce project, I found checkout accepted expired coupon codes. Task: report it clearly before the demo. Action: I reproduced it three times and logged clear steps, expected and actual results, screenshots and the coupon data, and marked severity high because it meant revenue loss. Result: the developer fixed it within a day, and I added a regression test for coupon expiry.

Situation: a developer marked my defect 'works as designed'. Task: resolve it without conflict. Action: I re-read the user story, attached the acceptance criteria that contradicted the behaviour, and discussed it calmly with the developer and product owner, focusing on user impact rather than blame. Result: the product owner confirmed it was a defect, and we clarified the story wording so similar confusion did not happen again.

Independence ranges from none (authors test their own work), some (a peer in the same team), high (testers outside the team but in the organisation) to very high (testers from outside the organisation). Independent testers find different kinds of failures and challenge assumptions. Drawbacks include isolation from developers, communication delays, adversarial relationships and developers losing responsibility for quality. Most projects mix levels: developers test components, independent testers handle system and acceptance testing.

For safety-critical products, regulations and risk usually demand higher independence. I would keep developer component testing and static analysis, but recommend that system and acceptance testing be done by an independent test team, possibly with external assessors for certification. I would explain the benefits: a fresh perspective, fewer shared assumptions and objective evidence for regulators, while keeping close communication to avoid isolation and delays.

Testing is context dependent. For a medical device I would use formal documented plans, high independence, strict traceability to requirements, demanding coverage targets and evidence for regulators. For a mobile game I would use lightweight plans, exploratory testing, beta users, automation of core flows and fast releases. Factors that drive the choice include risk, regulations, budget, time, team skills, the SDLC and the technical environment.