The feedback loop is this: 1. When the user says the service doesn't work (which means it doesn't work according to spec) we look what is at fault (is it the u

The feedback loop is this: 1. When the user says the service doesn't work (which means it doesn't work according to spec) we look what is at fault (is it the user that misunderstood the spec, the spec is faulty or the implementation is faulty). 2. If the spec or implementation is faulty we ensure there is a test that checks the correct behavior (and fix the spec if necessary). For example, the user might submit a piece of logic that in his view should work correctly but it does not. This might get distilled to a test. 3. We ensure the test fails (which means we were able to reproduce the error). 4. We fix the code and ensure the new version passes the test. 5. We get back to the user to confirm. Now, if you read it you will notice following: - after completion of the process we are left with a test to check, so as users complain with problems and incidents the spec and library of tests checking the spec gets updated. This is the feedback loop that updates the library with relevant tests over time ensuring more complete suite. - this is no different form the idea of TDD, just implemented for functional testing. It is not like there is something fundamentally wrong with TDD, it's that TDD cannot be effectively forced on developers. On the other hand, it can be enforced for functional testing because it is just a simple fix to incident/bug handling process.