* Lack of realistic test input is usually a problem caused by over-reliance on unit testing or lack of monitoring feedback.
* UX review and load & performance testing are usually things that we engage in regularly on trunk or the developer/code reviewer flags up ("this change has load implications/this change requires a UX review").
* "Microsoft famously got bitten by moving away from manual testing" - I'd never advocate eliminating manual testing entirely, just that it should be A) never repetitive, B) not a gatekeeper, C) always exploratory.
>We usually had best-effort integration tests, but they never caught everything,
Nothing ever catches everything but IMHO continuous delivery, short-lived branches, good monitoring and regular exploratory testing, load/perf testing on trunk is the best way to catch as much as possible.
I've started experimenting with integration tests that generate reports with screenshots and story steps, as well, so that there's a tighter UX feedback.
* UX review and load & performance testing are usually things that we engage in regularly on trunk or the developer/code reviewer flags up ("this change has load implications/this change requires a UX review").
* "Microsoft famously got bitten by moving away from manual testing" - I'd never advocate eliminating manual testing entirely, just that it should be A) never repetitive, B) not a gatekeeper, C) always exploratory.
>We usually had best-effort integration tests, but they never caught everything,
Nothing ever catches everything but IMHO continuous delivery, short-lived branches, good monitoring and regular exploratory testing, load/perf testing on trunk is the best way to catch as much as possible.
I've started experimenting with integration tests that generate reports with screenshots and story steps, as well, so that there's a tighter UX feedback.