Defect and Configuration Management Interview Questions for ISTQB

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.

What information does a defect report typically contain in CTFL v4.0?

Show answer

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.

What is the difference between severity and priority?

Show answer

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.

Describe a typical defect life cycle.

Show answer

A defect is logged as new or open, then triaged: it may be rejected, marked duplicate or deferred, or assigned for fixing. After the developer fixes it, it moves to awaiting confirmation testing. The tester re-tests; if it passes, the defect is closed, and if it fails, it is re-opened. Teams customise the workflow, but each status should have clear rules about who can move it and when.

A tester logs a defect titled 'Login broken' with no other details. How would you improve it?

Show answer

A better title is 'Login - valid credentials - error 500 after clicking Sign in'. The report should add the build number and environment, browser and device, preconditions such as user type, numbered steps, test data used, expected result, actual result with the error message, a screenshot or log, severity, suggested priority, and a reference to the related test case. This lets a developer reproduce it immediately.

Write a sample defect report for a failed coupon code.

Show answer

ID: DEF-1042. Title: Checkout - valid coupon SAVE10 rejected as expired. Build: 3.4.1, staging, Chrome 130 on Windows. Preconditions: logged-in user, cart value 1,500 rupees. Steps: open checkout, enter SAVE10, click Apply. Expected: 10 percent discount applied. Actual: error 'Coupon expired' although valid until 31 December. Attachments: screenshot, console log. Severity: major. Priority: high. Reference: TC-CHK-018.

What are false positives and false negatives in testing?

Show answer

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.

How does configuration management support testing?

Show answer

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.

Why is not every failed test a defect in the software?

Show answer

A failure can be caused by the test itself or the environment, not the test object. Common causes include wrong expected results, outdated test data, incorrect test scripts, misconfigured environments, network issues or unavailable third-party services. CTFL v4.0 therefore talks about anomalies, which are analysed before being reported as defects. Logging every failure as a defect without analysis creates false positives and wastes developer time.

A developer says your defect cannot be reproduced. What do you do?

Show answer

I would re-check that I can reproduce it, then add missing details: exact build version, environment, browser or device, user role, test data, timestamps, logs and a screen recording. I would check whether it is intermittent and note the frequency. If needed, I would reproduce it live with the developer. If it truly cannot be reproduced, we can keep it open with monitoring rather than close it.

Give an example of a high-severity low-priority defect and a low-severity high-priority defect.

Show answer

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.

Your defect tracker is full of duplicate defects from several testers. How do you fix this?

Show answer

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.

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

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.

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

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.

Testing found 80 defects and users found 20 more after release. What is the defect detection percentage?

Show answer

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.

A module of 15,000 lines of code has 45 defects. Calculate its defect density and explain how you would use it.

Show answer

Defect density = defects / size = 45 / 15 KLOC = 3 defects per KLOC. If other modules average 1 defect per KLOC, this module is a defect cluster, so I would increase test depth there, ask for a code review or refactoring, and add more regression tests. Compare density only across similar code, because language and complexity affect the numbers.

Tell me about a time you missed a defect. What did you learn?

Show answer

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.

Your manager asks you to lower the severity of a defect to meet release targets. How do you respond?

Show answer

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.

Explain defect density and defect detection percentage.

Show answer

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.

How is configuration management handled in a DevOps environment?

Show answer

In DevOps, configuration management is largely automated within the CI/CD pipeline. Source code, test scripts, pipeline definitions and infrastructure as code are all in version control. Each build gets a unique version, artefacts are stored in a repository, and environments are created from versioned templates. This makes test results reproducible and lets teams trace exactly which code, tests and configuration produced a given result.

Production defects increased over the last three releases. How do you analyse and act?

Show answer

I would categorise escaped defects by module, root cause and the test level that should have found them, and calculate defect detection percentage per release. Typical findings are missing regression coverage, unclear requirements or environment differences. Actions might include requirement reviews, adding regression tests for each escaped defect, improving test data and environment parity, and tracking the trend to confirm improvement.

Testers spent a day testing the wrong build version. How do you prevent this?

Show answer

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.

How do you run an effective defect triage meeting?

Show answer

Invite the test lead, a development lead and the product owner. Prepare a filtered list of new and re-opened defects before the meeting. For each defect, confirm it is valid and not a duplicate, agree severity and priority, assign an owner and a target release, or reject or defer it with a reason. Keep it time-boxed, record decisions in the tool, and review ageing critical defects regularly.

Describe how you improved the defect management process in a team.