1. What is ad hoc testing?
Ad hoc testing is informal, unplanned testing where the tester explores the software using intuition and experience, with no prepared test cases and no test plan. The tester simply sits down with the application and starts looking for problems.
Normal testing is the opposite. It follows written test cases — documented steps, inputs, and expected results that anyone can execute. That structure is powerful, but it has a blind spot: scripted tests only check what the testers thought to write down. Ad hoc testing explores everything else.
An experienced tester doing ad hoc testing clicks through parts of the application nobody planned to test, enters unusual data, tries odd sequences of actions, and follows hunches about where bugs tend to hide. It is fast and cheap, because nothing needs to be written down first, and it finds bugs that scripted tests miss — weird input handling, broken edge cases, clumsy error messages.
It is also a common last-minute tool. Before a release, when time is short, a quick exploratory pass by an experienced tester can catch obvious problems far faster than writing a full test plan would take.
The limitation is reproducibility. Because nothing is scripted, a bug found by ad hoc testing is hard to reproduce unless the tester documents exactly what they did. And because the technique depends entirely on the tester’s skill and mood, its coverage is uneven — it cannot be relied on to cover everything. Ad hoc testing is a valuable complement to planned testing, not a replacement for it.
AD HOC TESTING
|
v
+---------------+
| Application |
+---------------+
|
+----------+----------+
| | |
v v v
Odd Input Odd Flow Edge Case
| | |
+----------+----------+
|
v
Bug?
/ \
Yes No
| |
v v
Report Explore2. What is exploratory testing?
Exploratory testing is a testing technique where the tester designs and executes tests at the same time, guided by what they learn as they go. Unlike scripted testing, where test cases are written first and then executed, exploratory testing combines test design, execution, and learning into one continuous activity.
The tester starts with a goal — “understand how the checkout flow handles errors” — and explores the application freely, deciding the next test based on what the current test revealed. Each discovery shapes the next action. A strange response to one input prompts a test of a related input. This is why it is called exploratory: the tester is discovering the software’s behavior as they test it.
It draws on three things at once: the tester’s knowledge of the product, their testing experience, and their creativity. An exploratory tester does not follow a checklist; they think like a curious, slightly suspicious user and follow their instincts about where things might be wrong.
The strength of exploratory testing is that it adapts. Scripted tests are fixed at the time they were written, so they cannot chase a lead that appears during testing. Exploratory testing can, which makes it excellent at finding unexpected problems — logic errors, usability issues, and edge cases that nobody anticipated.
The weakness is the same as ad hoc testing’s: results depend on the tester’s skill and are not automatically repeatable. That is why exploratory testing is usually combined with scripted testing — the scripts provide repeatable coverage, and exploration provides the intelligence that scripts cannot.
EXPLORATORY TESTING LOOP
+-------------------+
| Goal |
+-------------------+
|
v
+-------------------+
| Explore System |
+-------------------+
|
v
+-------------------+
| Observe Behavior |
+-------------------+
|
v
+-------------------+
| Learn / Discover |
+-------------------+
|
v
+-------------------+
| Design Next Test |
+-------------------+
|
+-----------> back to Explore3. What is test coverage?
Test coverage measures how much of the software has been tested. It answers the question “how thorough is our testing?” by comparing what was tested against what could have been tested.
Coverage is measured at different levels, and each measures something different. Statement coverage measures the percentage of code statements that were executed by tests. Branch coverage measures the percentage of decision branches that were taken — both the true and false sides of every if-statement. Requirement coverage measures the percentage of requirements that have at least one test verifying them. Function coverage measures the percentage of functions or methods that were called.
The calculation is straightforward: coverage equals the tested items divided by the total items. If 80 of 100 requirements have test cases, requirement coverage is 80 percent.
TEST COVERAGE
+----------------------+
| Total Testable |
| Items |
+----------------------+
|
v
+----------------------+
| Tested Items |
+----------------------+
|
v
+----------------------+
| Coverage |
| = Tested / Total |
+----------------------+
Example:
80 tested / 100 total = 80%Coverage numbers are useful because they expose gaps. Low coverage means large parts of the product are untested and therefore risky. Coverage reports also identify exactly which modules or requirements are untested, so the team knows where to focus next.
Coverage has an important limitation: it measures quantity, not quality. A test suite can achieve 100 percent coverage while testing nothing meaningful — executing lines without checking the results counts as coverage. High coverage is a necessary condition for confidence, not a sufficient one. The useful discipline is to use coverage to find untested areas, then write meaningful tests for them, rather than chasing a number.
4. What is a test plan?
A test plan is a document that describes how testing will be carried out for a project — the scope, the approach, the resources, the schedule, and the deliverables. It is the plan the testing team works from.
A typical test plan contains several sections. Scope states what will be tested and, just as importantly, what will not be. Approach describes the testing strategy — which test levels will be used (unit, integration, system, acceptance), what techniques, and what entry and exit criteria testing must meet. Resources lists the people, tools, and test environments needed. Schedule lays out when each testing activity happens. Deliverables lists what testing will produce — test cases, defect reports, test summary reports. Risks identifies what could go wrong with testing itself and how it will be handled.
TEST PLAN
+-----------------------+
| Test Plan |
+-----------------------+
/ / | \ \
/ / | \ \
v v v v v
Scope Approach Resources Schedule Deliverables
|
v
RisksThe value of a test plan is alignment. It forces the team to decide, up front, what testing will cover and how, rather than improvising as they go. It allocates time and people before they are needed. And it provides a baseline against which testing progress can be tracked.
A test plan sits at a different level than a test strategy. The strategy is the high-level, one-time statement of how the organization approaches testing. The test plan is more detailed and specific to the project, and it can be revised as the project evolves. The plan puts the strategy into action.
TESTING HIERARCHY
+----------------------+
| Test Strategy |
| High-level "How" |
+----------------------+
|
v
+----------------------+
| Test Plan |
| Project-specific |
| details |
+----------------------+
|
v
+----------------------+
| Test Activities |
+----------------------+5. What is a test strategy?
A test strategy is a high-level document that sets the overall direction for testing — the objectives, the approach, and how testing aligns with the project’s goals and risks. It is the “what and why” of testing, set before the detailed planning begins.
A test strategy makes decisions at a broad level. What are the testing objectives — is this a low-risk system where moderate testing suffices, or a high-risk financial system that demands the deepest testing? What test levels will be used, and how much emphasis does each get? What techniques — is the project risk-driven, requirement-driven, or analytics-driven? What are the overall entry and exit criteria — what must be true before testing starts and for testing to be declared complete?
The strategy is shaped by risk. A project where a defect could cause harm or financial loss gets a stronger testing strategy than a marketing website. The strategy states, for example, “because the payment module is high risk, it receives the highest test depth and the most rigorous exit criteria; low-risk informational pages receive lighter testing.”
TEST STRATEGY
|
v
+------------------+
| Testing Goals |
+------------------+
|
+------------+------------+
| | |
v v v
Risk Test Levels Techniques
| | |
+------------+------------+
|
v
Entry / Exit Criteria
|
v
Test PlanThe relationship with the test plan is one of hierarchy. The strategy is the broad, stable statement made once, often at the organization or program level. The test plan is the detailed, project-specific document that implements the strategy — and it can change as the project changes, while the strategy stays constant.
The strategy matters because it prevents testing from being an afterthought. It makes testing decisions explicit and reasoned — based on risk and objectives — rather than improvised in the moment.
6. What is a test case?
A test case is a set of inputs, execution steps, and expected results used to verify that a specific piece of functionality works as intended. It is the basic unit of testing.
A well-formed test case contains specific parts. A test ID and description identify what is being tested. Preconditions describe what must be true before the test runs — the user is logged in, the database has data. Test data is the input used. Steps are the exact actions to perform, in order. Expected result is what should happen if the software works correctly. Actual result and status record what actually happened and whether the test passed or failed.
TEST CASE
+----------------------+
| Test ID |
+----------------------+
|
v
+----------------------+
| Preconditions |
+----------------------+
|
v
+----------------------+
| Test Data |
+----------------------+
|
v
+----------------------+
| Steps |
+----------------------+
|
v
+----------------------+
| Expected Result |
+----------------------+
|
v
+----------------------+
| Actual Result |
+----------------------+
|
v
PASS / FAILConsider a login test case: preconditions — the user is registered; test data — email alice@example.com, password secret; steps — open the login page, enter the email, enter the password, click login; expected result — the user lands on the dashboard. If the test runs and the user instead sees an error, the actual result differs from the expected, and the test fails — a defect has been found.
Test cases matter because they make testing repeatable and verifiable. Anyone can execute a well-written test case, which means the testing does not depend on one person’s memory. Test cases map back to requirements through the traceability matrix, proving coverage. And executed test cases are the evidence that testing actually happened — essential for audits and sign-off.
A suite of test cases, organized and maintained, is the backbone of a structured testing effort.
7. What is Software Configuration Management (SCM)?
Software Configuration Management (SCM) is the discipline of identifying, tracking, and controlling changes to all the artifacts a software project produces — source code, documents, designs, builds, and configuration files. It brings order to the chaos of many people changing the same things.
SCM is built from a few core activities. Version control records every change to every artifact, so the full history is always available and anything can be rolled back. Identification establishes exactly which items belong to the project and which version each is at. Change control ensures changes are proposed, reviewed, and approved rather than made silently. Baselines are approved snapshots that later work builds on. Release management ensures that what ships is a known, reproducible combination of versions.
SCM
+-----------------------+
| Software Artifacts |
| Code / Docs / Builds |
+-----------------------+
|
v
+-----------------------+
| Configuration Mgmt |
+-----------------------+
/ | | \
v v v v
Version Change Baseline Release
Control Control Mgmt
\ | | /
\ | | /
+-----+-------+-----+
|
v
Known & Reproducible
ReleaseWhy does this matter so much? First, collaboration. With version control, many developers can work on the same codebase without overwriting each other. Second, traceability. Because every change records who made it and why, the history of any artifact is knowable — a production bug can be traced back to the exact change that caused it. Third, reproducibility. Because the exact source is recorded, a release can be rebuilt exactly as it shipped, which is essential for debugging and audits.
Without SCM, the project has no reliable answer to the most basic questions: what is the current version of anything, who changed what, and can we go back? Those questions are exactly what SCM answers.
8. What are the four types of software maintenance?
Software maintenance keeps a product working and valuable after release, and it comes in four types: corrective, adaptive, perfective, and preventive.
Corrective maintenance fixes defects. When a user reports a bug — a crash, a wrong result, a feature that misbehaves — the team repairs it. This is the most visible kind of maintenance and what most people picture when they hear the word.
Adaptive maintenance keeps the software working in a changing world. Operating systems get updated, hardware changes, regulations change, third-party services change their APIs. Adaptive maintenance adapts the software to that new environment without adding any new features.
Perfective maintenance makes the software better. It adds new features, improves usability, speeds up slow parts, and polishes rough edges. In practice, this is where most maintenance effort goes, because users continually want improvement.
Preventive maintenance avoids future problems. It refactors messy code, adds missing tests, improves documentation, and removes risky shortcuts — work that makes the software easier and safer to maintain later, even though it adds no visible value today.
SOFTWARE MAINTENANCE
|
+--------------+--------------+
| | |
v v v
Corrective Adaptive Perfective
Fix defects Fit change Improve product
| | |
+--------------+--------------+
|
v
Preventive
Avoid problems| Type | Purpose | Example |
|---|---|---|
| Corrective | Fix defects | Fix a crash on login |
| Adaptive | Fit a changed environment | Support a new OS version |
| Perfective | Add improvements | Add a dark mode |
| Preventive | Avoid future problems | Refactor messy code |
Together, the four types explain why maintenance is the longest and costliest phase of a product’s life. Bugs always appear, environments always change, users always want more, and code always decays if left alone.
9. What is a project charter?
A project charter is a high-level document that formally authorizes a project and defines its purpose, objectives, and the authority of the project manager. It is the founding document of a project.
A charter typically contains the project’s business case — why the project exists and what problem it solves; the scope and objectives — what the project will deliver and what it is trying to achieve; the stakeholders and their roles; the budget and timeline at a high level; and the project manager’s authority — what they are empowered to decide, and to whom they report.
PROJECT CHARTER
+--------------------------+
| Project Idea |
+--------------------------+
|
v
+--------------------------+
| Business Case |
+--------------------------+
|
v
+--------------------------+
| Scope & Objectives |
+--------------------------+
|
v
+--------------------------+
| Stakeholders / Authority |
+--------------------------+
|
v
+--------------------------+
| Budget / High-level |
| Timeline |
+--------------------------+
|
v
+--------------------------+
| PROJECT AUTHORIZED |
+--------------------------+The charter’s most important job is authorization. It is the document that says “this project is officially approved; the project manager is appointed; work can begin.” Before a charter, a project is just an idea; after it, the project legally and organizationally exists, and resources can be committed.
The charter also aligns everyone. Stakeholders, sponsors, and the team all read the same document and agree on what the project is for. When disagreements arise later — about scope, about priorities — the charter is the reference point.
The charter sits at the very beginning of the project lifecycle, before detailed planning. It is deliberately high-level: it does not contain the detailed schedule or designs, which come later. Its job is to authorize and align, and then get out of the way.
10. What is a project baseline?
A project baseline is the approved scope, schedule, and cost of a project, recorded so that performance can be measured against it. It is the fixed reference point for tracking how the project is doing.
There are three standard baselines, together called the performance measurement baseline. The scope baseline is the approved requirements and deliverables. The schedule baseline is the approved timeline. The cost baseline is the approved budget.
PROJECT BASELINE
+---------+
| Baseline|
+---------+
|
+--------------+--------------+
| | |
v v v
+-------------+ +-------------+ +-------------+
| Scope | | Schedule | | Cost |
| Baseline | | Baseline | | Baseline |
+-------------+ +-------------+ +-------------+
| | |
v v v
What to When to How much
deliver deliver it costsThe way a baseline works is simple. At a point in time, the team agrees on what the project will deliver, when, and for how much — that agreement is frozen as the baseline. From then on, actual progress is compared against it. If the project is behind schedule, the schedule baseline shows how far behind. If it is over budget, the cost baseline shows by how much. The baseline is what makes “we are late” and “we are over budget” measurable statements.
BASELINE vs ACTUAL
+------------------+
| Baseline |
+------------------+
|
v
+------------------+
| Compare Actuals |
+------------------+
|
+-------+-------+
| |
v v
On Track? Variance?
| |
v v
Continue Analyze / ChangeBaselines are also the mechanism for managing change. When a change is requested, its impact is measured against the baseline — the change will push the schedule or cost beyond the baseline, and that cost must be approved. Only after approval does the baseline move, to the new approved plan.
Without a baseline, project status is meaningless — there is no agreed “plan” to compare actuals against. The baseline is the plan made measurable.
11. What is a project schedule?
A project schedule is a timeline showing what work must be done, in what order, and when — the tasks, their durations, their dependencies, and the project’s milestones.
A schedule is built in steps. The team first breaks the project into tasks, then sequences them — some tasks can happen in parallel, others must wait for a predecessor to finish. Then each task gets a duration estimate, and the tasks are laid out on a timeline. The result is a chart, often a Gantt chart, showing each task as a bar across time.
PROJECT SCHEDULE
Task A |==========|
|
v
Task B |=======|
|
v
Task C |==========|
|
v
Task D |=====|
---------------------------------------->
TIMEThe most important concept in a schedule is dependencies. A task that cannot start until another finishes is dependent on it. The chain of dependencies determines the critical path — the longest sequence of dependent tasks, which sets the minimum possible project duration. Any delay on the critical path delays the whole project; tasks off the critical path have slack.
CRITICAL PATH
Start
|
v
Task A
|
v
Task B
|
v
Task C
|
v
Finish
A -> B -> C
= Critical Path
Any delay in A, B, or C
delays the project.A schedule also defines milestones — significant points, such as “design complete” or “release”, that mark progress. Milestones make a schedule readable at a glance.
The schedule matters because it is the project’s plan made visible. It shows what should be happening now, which helps everyone focus. It reveals delays early — when a task slips, the schedule shows the downstream impact. And it provides the basis for the schedule baseline, against which progress is measured.
A schedule is never static. As the project proceeds, it is updated to reflect reality — completed tasks, slipped dates, added work. Its value is in being an honest, current picture of the project’s timeline.
12. What is a project closure report?
A project closure report is the document that formally closes a project. It summarizes what the project delivered, whether it met its objectives, what was learned, and the formal acceptance of the results.
A closure report typically covers: the final deliverables compared against the plan — what was actually delivered versus what was promised; the achievement of objectives and success criteria — did the project deliver the value it set out to?; performance against the baseline — were scope, schedule, and cost met?; the lessons learned — what went well, what went badly, and what future projects should do differently; and the formal acceptance sign-off, in which the stakeholders confirm the project is complete and accept the results.
PROJECT CLOSURE
+-------------------------+
| Final Deliverables |
+-------------------------+
|
v
+-------------------------+
| Objectives / Success |
| Criteria |
+-------------------------+
|
v
+-------------------------+
| Baseline Performance |
+-------------------------+
|
v
+-------------------------+
| Lessons Learned |
+-------------------------+
|
v
+-------------------------+
| Acceptance / Sign-off |
+-------------------------+
|
v
+-------------------------+
| PROJECT CLOSED |
+-------------------------+The closure report matters for a few reasons. It formally ends the project — responsibilities wind down, the team is released, and the project stops consuming resources. It captures the lessons learned while the experience is still fresh, turning a project’s mistakes and successes into knowledge that future projects can use. And it provides the official record of what happened, for audit and reference.
The most underrated section is the lessons learned. Every project has them — a process that caused delay, a decision that saved money, a risk that materialized unexpectedly. A team that records those lessons and actually uses them on the next project improves continuously. A team that skips them repeats its mistakes.
Closure is not a formality. It is the moment the project’s experience becomes organizational knowledge.
13. What is technical debt?
Technical debt is the future cost of choosing a quick, easy solution now instead of a better, more solid one. The term borrows from finance on purpose: the speed gained today is a loan, and it accrues interest that must be paid back later.
It usually accumulates under deadline pressure. A team needs to ship by Friday, so it hard-codes a value instead of making it configurable, or it copies a block of code instead of extracting a reusable function, or it skips writing tests. The shortcut works — the feature ships on time. But now every future change to that code is slower and riskier than it should be, because the code is messy, duplicated, or untested. That extra effort later is the “interest.”
TECHNICAL DEBT
Deadline Pressure
|
v
+----------------------+
| Quick Shortcut |
+----------------------+
|
v
Feature Ships
|
v
+----------------------+
| Technical Debt |
+----------------------+
|
v
"Interest" grows
|
+----------+----------+
| | |
v v v
Slower More Risk More Cost
ChangesCommon examples: hard-coded values that must be changed in many places; copy-pasted code that has drifted into slightly different behavior; missing automated tests that make every change a gamble; tangled dependencies nobody fully understands.
Technical debt is not automatically bad. A reasonable trade when a deadline matters and the code will not live long is legitimate. The problem is unmanaged debt. If the team never acknowledges it, the debt compounds — every feature built on top of a shortcut gets harder, until the codebase slows to a crawl and major changes require major rewrites.
MANAGED vs UNMANAGED DEBT
Technical Debt
|
+------+------+
| |
v v
Managed Unmanaged
| |
v v
Repay Small Debt Grows
Amounts |
| v
v More Cost
Healthy Code |
v
Major RewriteThe healthy approach treats debt like real debt: keep a visible list of what is owed, schedule time to repay it in small pieces during normal work, and repay it before it blocks new features or causes failures. A team that tracks and repays its debt avoids the day the whole codebase has to be rewritten.
14. What is a product backlog?
A product backlog is the ordered list of everything that might go into a product — features, enhancements, bug fixes, and technical work. It is the single source of truth for what the product could be, and it is owned by the Product Owner.
The backlog contains items at various levels of detail. The top items, planned for the near future, are detailed and refined — they have acceptance criteria and estimates. The lower items are coarser, often just a sentence or a rough idea, to be detailed when they rise to the top. This is called progressive refinement or “grooming.”
PRODUCT BACKLOG
+-------------------------+
| Highest Priority |
+-------------------------+
| Feature A |
+-------------------------+
| Bug Fix B |
+-------------------------+
| Enhancement C |
+-------------------------+
| Technical Work D |
+-------------------------+
| Future Idea E |
+-------------------------+
| Lower Priority ... |
+-------------------------+
^
|
Product Owner
orders backlogEvery item has a priority. The backlog is ordered by value: the most important items sit at the top. The Product Owner maintains this ordering, weighing business value, risk, dependencies, and stakeholder priorities.
The backlog is dynamic. It is never finished or frozen. New ideas are added, priorities shift, and items are removed as the product evolves. It is a living list, not a static document.
In Scrum, the backlog drives everything. At sprint planning, the team pulls the top items into the sprint backlog and commits to completing them. Each sprint delivers value from the top of the backlog, so the product is always being built toward its most valuable features first.
PRODUCT BACKLOG
|
v
Sprint Planning
|
v
+--------------+
| Sprint |
| Backlog |
+--------------+
|
v
Development
|
v
Sprint Goal
|
v
Product ValueThe backlog matters because it makes priorities explicit and visible. Everyone can see what is most important, what is planned next, and what is merely an idea. That transparency is one of the core strengths of the Scrum framework.
15. What is a sprint backlog?
A sprint backlog is the set of items the development team commits to completing during the current sprint, broken down into tasks. It is the team’s plan for the next two to four weeks.
The sprint backlog is created at sprint planning. The team reviews the product backlog, selects the items it believes it can complete in the sprint, and then breaks each item into concrete tasks. Each task gets an estimate, and the total is checked against the team’s capacity. The team commits to the selected items — a public promise to deliver them.
SPRINT BACKLOG CREATION
+-------------------------+
| Product Backlog |
+-------------------------+
|
v
+-------------------------+
| Sprint Planning |
+-------------------------+
|
v
+-------------------------+
| Select Sprint Items |
+-------------------------+
|
v
+-------------------------+
| Break Into Tasks |
+-------------------------+
|
v
+-------------------------+
| Estimate / Check |
| Team Capacity |
+-------------------------+
|
v
+-------------------------+
| Sprint Backlog |
+-------------------------+The sprint backlog is owned by the development team, unlike the product backlog, which is owned by the Product Owner. The Product Owner decides what the product needs and in what order; the team decides how much it can take on and how it will do the work. The sprint backlog reflects that division of responsibility: it is the team’s commitment, their way of turning the Product Owner’s priorities into work.
During the sprint, the backlog is tracked daily. The team updates task status, and progress is often shown on a burn down chart. The goal is visible at all times: the remaining work, the time left, and whether the team is on track.
SPRINT PROGRESS
Remaining Work
|
|\
| \
| \
| \
| \
| \
| \
| \
+--------------------> Time
Start End
Ideal trend:
Work decreases
toward zeroThe sprint backlog is normally frozen once the sprint starts — new items are not added unless the team agrees, because adding work undermines the team’s commitment. Flexibility lives in the next sprint’s planning, not in inflating the current one.
PRODUCT BACKLOG
|
v
+-------------+
| Sprint |
| Planning |
+-------------+
|
v
+-------------+
| Sprint |
| Backlog |
+-------------+
|
v
+-------------+
| Development |
+-------------+
|
v
+-------------+
| Sprint Goal |
+-------------+
|
v
+-------------+
| Review / |
| Increment |
+-------------+
|
v
Next SprintPremium Content
Unlock Top 50 Placement Questions - Part 3 and all premium lessons with a subscription.
From ₹199.99/year — See plans