In words
What it is, why it matters, and what it is like.
Why am I learning this?
This concept is the foundation of knowing whether to trust a test result. When you learn software testing — unit tests, integration tests, regression tests — you will write tests to prove your code does what you meant. But a test can be green while the analysis is still wrong, and knowing which kind of wrong happened changes what you do next. Every later testing idea (Test-Driven Development, CI/CD, Code Quality and Refactoring) assumes you can tell the two apart. If you cannot, you will fix the wrong thing and declare victory while the bug survives.
The idea, in plain terms
Think of a cooking competition. The judges taste the dish. If the chef undercooked the chicken, the dish is bad because the cooking was bad — the process. If the chef cooked everything perfectly but the judges were told to expect dessert and got a roast, the dish is bad because the interpretation was wrong — they read the brief incorrectly. Both produce a failed dish, but the fix is completely different: one needs a better oven timer, the other needs a better reading of the instructions.
In software and data analysis, the same split appears every day. You run a query to count your customers. The query runs without errors, but it uses the wrong date range, so the number is wrong. That is a process error — the analysis did not do what you intended. Or the query runs exactly as you wrote it, using the correct date range, and the number is right, but you conclude that customer count is growing because this month's number is higher than last month's — when actually last month was a holiday and the comparison is meaningless. That is an interpretation error — the analysis did what you meant, and you drew the wrong conclusion.
The first kind is fixable by checking the code. The second kind is not. You cannot write a test that checks whether your conclusion makes sense to a human who knows the business context. That is why the two classes need different defences.
An analogy
Consider a medical lab test. The lab receives a blood sample and runs a test for a disease. There are two ways the result can mislead the doctor.
Process error: the lab technician used the wrong reagent, or the machine was not calibrated, so the test result does not reflect what is actually in the blood. The analysis (the test) did not do what was intended. The fix is to calibrate the machine, check the reagent, run a positive control — quality assurance on the process.
Interpretation error: the test is perfectly accurate, but the doctor misreads the result. For example, the test says 'positive for the antibody', and the doctor concludes the patient has the disease, but the antibody could be from a past infection or vaccination. The analysis did exactly what it should; the conclusion is wrong. No amount of reagent checking will help. The doctor needs a different test or a more careful look at the context.
Where the analogy stops working: in a lab, you can often re-run the test on the same sample. In software, the 'sample' might not be re-runnable — the user's data changed, the external service returned different values, or the analysis was run in production on a live stream. You may only get one shot at the analysis, so you have to catch the error before it matters.
Definition
A process error is when the analysis did not do what you intended — the code, query, or procedure has a bug. An interpretation error is when the analysis did exactly what you intended but you drew the wrong conclusion from the result.
Where this sits
This is the foundation for everything in Software Testing. Your library notes the distinction is 'described throughout' Test-Driven Data Analysis, and names copy-and-paste as a leading underlying source of process errors. The defence against interpretation errors is checklists and review, not automated tests. This connects to every testing technique you will study — unit tests, integration tests, property-based testing — because they all target process errors. None of them catch interpretation errors. The neighbouring topics (Equivalence Partitioning, Boundary Value Analysis, Contract Testing) are all about systematically finding process errors. This concept sits above all of them: it tells you which class of error you are dealing with, and therefore which tool from your testing toolbox applies.
