If you are a believer in Agile methods, but don't like Test-Driven Development (TDD), this site is for you!

Many people in the Agile community feel that TDD is a niche technique that works really well for some people but is awful for others.

Sometimes TDD fans go too far by insisting that everyone should use TDD - even saying that if you don't use TDD, you are not fully Agile, or have not given it a chance. We disagree. We explain why here.

Be Agile without TDD!

Product level testing strategy and component level


Really a quality strategy: some things cannot be fully tested for, e.g., security, design integrity, and maintainability.

QA is essential for Agile, but it must operate differently. It must provide oversight over how thorough testing processes are. It must operate at a product level and product integration level, and must ensure that quality processes (such as testing) are transparent, and that deployed product quality (e.g., incident rate) is tied back to quality processes as a feedback loop. It should coach teams in how to create quality dashboards and feedback loops. It should also write its own use case level test cases that can be added to integration pipelines.

There is no need for a “wall” between QA and dev teams; in fact, they should work closely together. QA test programmers can be co-located with dev teams.

Don’t Fire All Your Testers!

The idea that “Agile teams write their own tests” reflects a misunderstanding of the intention of the Agile Manifesto, and is an inappropriate extrapolation of Scrum practices to multi-team situations. It is a practice from the early days of XP, when systems were simpler and monolithic, and emphasis on TDD, because for unit tests, programmers indeed do write their own tests. For today’s complex distributed systems, the majority of issues are in the cross-component interactions, and so integration needs special attention. Unit test coverage is a woefully inadequate metric today. One needs end-to-end tests, automated, run continually. Individual teams tend to do a poor job of that if left to themselves. Even with “feature teams”, it is challenging. (See “The Feature Team Conundrum”.) Having test programmers, or larger teams with sufficient programmers so that many of them can contribute to test programming, is essential; and having test automation leads who look at the overall testing holistically is also essential. Having business analysts who support the PO for writing test specs based on AC is also essential: it takes about a day per story to write a good test spec, and requires a range of business, technical, and testing expertise: the PO cannot do it well and does not have the time. The PO should be focused on the overall feature set – not down in the weeds of the test specs.

No comments:

Post a Comment