[loopbit]

I agree with you, the lack of QA skills in a team is a dangerous thing. But I disagree with the notion that the agile methodologies are the problem, more like an excuse from the same people that would use any other excuse to cut corners[0]. A QA column (or set of columns) fits perfectly with Kanban.

Years ago I started seeing companies combining QA and product teams[1]. It required product people with a bit of technical background but, when done right, worked incredibly well. Nowadays not only I've stopped seeing that trend, but most product teams I see are completely ignorant of technical matters. QA teams seem to be more or less missing or seriously understaffed.

---

[0] Not to speak of the need to be "agile" without changing a single thing in the process. I can't count the number of times I've seen teams using what is, essentially, a waterfall process (including long development cycles with no contact with the customer at all) self-describing themselves as agile.

[1] So the same team defining the new features also creates the tests, both automated and manual, and checked the results.

[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.