Asad Safari发起了这个讨论，他说他的一个应用没有任何测试 ，团队中的开发人员不熟悉单元测试，距离截止日期也只有3个星期的时间供团队测试。他希望得到一些建议，指导如何在这样的约束条件下测试。
Phlip回应道：他曾多次处于类似环境 ，并推荐以下建议：
1.加入一个可选模块，能够通过任意或是指定的输入来驱动应用；
2.向程序中加入日志，把错误信息和断言存入日志文件中；
3.编写一个大单元测试，调用你所有的程序，提供前面提到的输入，然后梳理日志；
4.编写一个大的断言，在其中指出日志应该没有任何错误；
5.现在开始一个一个排错。每次去掉一个错误，去掉对它的异常处理。
Phlip指明：在这个大测试保护伞之下，如果时间允许，团队可以开始编写小规模的、目的更明确的测试。他还指出：虽然团队可以在接下来的三个星期等待上面的做法产生效果，编写和运行更小的单元测试应该马上开始 。
Adam Sroka同意Phlip的建议，并补充道：
| 没错，很多团队碰到质量低劣的代码时，会放慢速度，产出的价值也会减少，而这对于质量没有任何好处。我们需要更实用的解决方案……如果没有从一开始就加入测试，那么就很难完全把测试做好，这是没问题的。但是就此认为测试没有价值，这是错误的看法。测试虽然不完美，但仍有其价值所在。 |
Brian Spears却没有被他们说服，他认为敏捷不是魔法 ，在三周时间内恐怕没法产生什么好解决方案。他说：
| 敏捷不是魔法，对这种紧急情况的解决方案，如果有的话，就是要投入很多很多时间，这明显不是敏捷的做法。 |
Adam反对这个看法，指出有很多团队如果进入类似境况，都采用了敏捷。这是团队变得有实效的机会，也是让软件变得更好的启动之旅。
Annette认为：这种情况最应该做的就是用很多很多时间做手工测试 ，因为到了这个阶段，自动化测试就太费时间了。推荐从重要的和与收入相关的功能开始测试。Annette也推荐了Lisa Crispin和Janet Gregory合著的Agile Testing 一书。
Charles Bradley提出了类似的建议，不过他指出还要获得一个有条件的承诺 。他说：
| 你的时间很有限，所以从业务角度来看，将ROI最大化是最佳选择。就使出吃奶的劲头做手工测试吧！但是要从你的老板那里得到承诺：他们无论如何也不会再让你的团队这么做了 ……他们应该先规划好时间和金钱完成自动化测试……着手下一个发布工作时就应该马上开始 ，甚至更早，比如开始修复当前版本的bug时。 |
因此，编写完整的测试套件，也许不是最适合当前情形的做法，团队最好开始手工测试。而这并不能削弱在一有机会时就编写适当的测试套件的做法。正如Jonathan Rasmusson 指出的：
| 你所能做的就是修复bug，然后在上线之前尽一切可能完成手工测试。这就是你到这个时候还能做的事情。更大、更重要的问题，是你在三周截止日期到达之后要做什么。 |
