Test Planning

This concept is the first step to mastering Software Testing. Before you can write a single test, you need to decide what to test, at which level (unit, integration, end-to-end), and how deeply. Without a plan, you waste effort on the wrong things and miss the critical ones. Mastering test planning unlocks Test-Driven Development (where tests are written before the code), CI-CD (where tests run automatically on every change), and Code Quality and Refactoring (where tests protect you from breaking things). In AI systems specifically, a test plan determines whether the model's behavior is verified at the smallest unit (a single function), at the integration level (the model's output feeding a database), or end-to-end (the whole user flow). 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 CI-CD (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).