I think what you're trying to ask is what is defect containment.
Defect Containment is a metric. We probably all use it to some degree. The idea is that you attempt to track the total number of new bugs for every full cycle. The idea here being that it is less costly to find/fix bugs at an earlier stage of development.
However, this particular means of measurement is also very reactive, so it isn't something that can, necessarily, help you in a proactive way until you have a great deal of historical information.
So let's say that I just finish up a project. My defect tracking software has a version and/or build field. I sort on this and I can immediately generate a report telling me the number of new bugs discovered in each phase of testing.
In my experience, the majority of bugs are found in the intiial stage, but this would ultimately be determined by your methodologies. I don't know how this might apply in an Agile environment, though, since I've only ever, relaly, applied this under very structured environments.
Anyway, if I get a result that shows that 70% of bugs were discovered in the first round of testing, 15% in the second round, 10% in the third round, 3% in the 4th round and then 2% in the final round, it shows that the number of bugs found was on the decline throughout the test cycle. This is good because it leads us to believe that we should, based on our numbers, be releasing with very few new bugs.
Now, I can also take this information, chart it out, and compare it to historical data to see how the project fared. In a project where I only found, say 40% of the bugs in the first review then this might lead me to believe that there are a great deal of new bugs still remaining in the system or that we simply introduced more bugs during the development cycle than there were in our first stage of development.
There are lots of things that can get drawn off of this. To keep the answer for you simple, though, it is a means of measuring the number of NEW bus found in a cycle.