Through answering a lot of questions on SearchSoftwareQuality.com, I’ve found that terms like integration testing, unit testing, system testing, and acceptance testing often get in the way of talking about testing. There are many of these terms, and they often mean different things to different people.
I suspect we use those labels in an attempt to do one (or more) of the following:
- imply chronological position within a phased life-cycle
- imply a set of common testing practices done within that phase (automation of unit tests, traceability back to requirements, client interviews and surveys, etc…)
- imply who is doing the testing (developers, testers, customers, etc…)
- imply some concept of what risks we might be looking for (a technical concern, how two parts interact, if we’ve implemented what the customer wants, etc…)
- imply some concepts of what areas of the application we are covering (code, interfaces, data, features, subsystems, etc…)
- imply some concept of what oracles we might use in our testing (asserts, specifications, competitor or past products, etc…)
I’m sure they imply other things as well. (Let me know if you think of some I missed. I’ll add it to the list with attribution.)
The reason I think this is important is because while these labels can help, they can also hinder. The can confuse the issue we are talking about since each term comes with it’s own baggage. Often, I find it easier to just talk about testing (oracles, coverage, risk, technique, etc…) as applied to specific problems then to talk in abstract labels we often apply to them.
I wonder if you’ve encountered the same issue?
I think many of us have encountered these road blocks. My current interaction has be dealing with individuals who have read a project management or methodology process book that says the labels are the areas of tests that must occur.
As you say, I find myself having to talk about testing as it applies to a situation and educating project managers and clients that are reading about a methodology that is different then application.
Then showing them the logic of risk, technique, coverage, etc. I also find I have to educate them that quality is owned by everyone not just the person assigned to the testing tasks.