[threeseed]

I am sure we have both spent time in Agile projects. Let me ask you. When stories end up in the QA column do they just test the story or everything the story could possibly touch ? Be honest.

Because that right there is the problem when you are dealing with systems with lots of interconnected components. There just isn't enough time for the "randomly try to break anything" phase.

[loopbit]

Yes, they usually only test the feature and you are right, when you are dealing with plenty of interconnected components, it's more difficult to do complete tests and there's a higher chance of something slipping by unnoticed.

However, on every build the unit, integration and acceptance tests should run and should alert if something is not right[0]. Automated testing can't cover all the use cases, but there's no reason they couldn't catch most of the issues we've seen with OSX lately (a good example of a system with plenty of interconnected components). On top of that, the good QA people I know always run some random manual tests not related with the story itself on every feature release just to make sure everything is still as expected.

The time is there if it is, along with the expectations, managed correctly. Only in smaller chunks instead of a big, single block of time at the end.

Even though, there's always the chance that there's a completely unforeseen side effect (a test can prove that there's an error, but can't prove that there are no errors), all of this is to try and minimize that chance. In general, I think that these issues appear more often related to specific systems (lots of interconnected components) or environments (lack of proper testing), rather than with specific methodologies (back in the non-agile methodologies days, programs still had bugs).

[0] Like, for example, an edge case of a method being fixed. That can have knock-on effects if other parts of the system were relying on that method failing.