Test Planning

Every project starts with a choice: what to build and how to ensure it works. Without a plan, you risk spending weeks writing code that fails or doesn’t do what the user needs. A clear test plan turns this uncertainty into a roadmap. It lets you use Test-Driven Development, where you write the rules of success before you start coding, ensuring you know exactly when you’re done. It enables Continuous Integration and Deployment, meaning your work is checked automatically every time you save changes, so bugs are caught immediately rather than weeks later. It supports Code Quality and Refactoring, allowing you to improve your code’s structure without fear of breaking existing features, because your tests will alert you if anything breaks. In systems that learn from data, a test plan helps you decide whether to verify the smallest part (a single calculation), the connections between parts (data moving through the system), or the entire user experience (clicking through the app). This concept gives you the decision framework you will reuse in every subsequent testing topic.

Testing is about answering two questions: 'What could go wrong?' and 'How much effort is it worth to check it?' Imagine you're a quality inspector for a factory that makes cricket bats. You have a limited budget. You don't inspect every single bat with equal thoroughness — the junior bats for ₹500 get a quick look, but the international pro bats for ₹50,000 get a full lab test. Why? Because a defect in a cheap bat costs little, but a crack in an expensive bat could ruin a player's career and your reputation. The same logic applies to software. Some functions are rarely used and cheap to fix if they break; others are in the critical path of every user and cause outages or financial loss. Risk-driven test planning means you allocate your testing effort where a failure would hurt most. You also decide the level: a unit test checks one function in isolation (fast, cheap, but doesn't prove the whole system works), an integration test checks two components together (like the bat fitting the handle), and an end-to-end test checks the whole flow from user click to database response (slow, brittle, but confidence-building). The plan is not a list of every possible test — it's a strategy for where to put your effort to get the best safety per hour of work.

Think of test planning like planning a medical check-up. You have a limited appointment time, and you want to catch the most dangerous conditions first. The doctor doesn't run every possible test on everyone — she asks about symptoms, risk factors, and family history. A young athlete with a knee pain gets an MRI for the knee, not a full body scan. A person over 50 with a family history of heart disease gets an ECG and blood tests, not a skin allergy panel. The decision is risk-based: high likelihood of a dangerous condition + high cost of missing it = more testing. The level of testing is like choosing between a blood test (unit — checks one biomarker) and a full stress test (end-to-end — checks the whole cardiovascular system under load). The blood test is cheap to repeat and pinpoints a specific issue, but it won't tell you if the heart can handle a marathon. The stress test is expensive and takes time, but gives you confidence that the whole system works together. Just as a doctor's plan is a written strategy, not a random list of tests, a software test plan is a document that says: 'These are the risks, these are the levels, this is how much effort each gets.' Where the analogy breaks down: a medical check-up is done periodically on a healthy person, but software tests run continuously, every time code changes. Also, in software, the plan is not just for one check-up — it's a living document that the team updates as the system evolves. And unlike a doctor, you can automate tests to run thousands of times a day, so the plan is about initial design, not just budget allocation. The plan's value is that it forces you to think: 'Given my limited testing time, what must not break? What would hurt the most if it failed?'

Test planning is the systematic process of deciding what to test, at which level (unit, integration, end-to-end), and to what depth, based on the risk of failure and the cost of that failure, balanced against the effort available for testing.

You have no prior notes in this library yet, so we are starting fresh. This concept belongs to Software Testing, and it connects directly to your other notes: it leads naturally into Test-Driven Development (where you plan a test *before* writing the code) and Continuous Integration and Deployment (where your planned tests run automatically). The test plan decides the shape of the automation you will later build with tools like Playwright and Selenium for end-to-end tests, and it uses the systematisation tools of Equivalence Partitioning and Boundary Value Analysis to choose *which* cases to include. Contract Testing is a level of testing you will choose in the plan when you have separate services. The plan also decides whether you need Accessibility Testing or Performance Testing as separate tracks, based on the risk profile of your application. In the world of AI, a test plan for an ML system is even more crucial because the model's behaviour is probabilistic — you cannot just check 'does it work', you must define acceptable error rates and test across different inputs (see 'Application' below).