1.5 冰山
伴随成功到来的，必然是更多的、全新的挑战。
1.5.1 假失败
首先遇到的是用例假失败（False Failure），也就是类似足球比赛中假摔的问题，或者因为非缺陷原因导致的自动化测试用例运行失败。一般大批量的测试运行开始于每个发布的若干个最早期的几个Sprint之后；这时候基本上已经达到100%通过率的测试用例。但在新版本上的通过率会有一个明显的降低，从上一版本的全部通过快速下降到60%甚至更低，然后就是一场艰苦卓绝的排错与根因分析的攻坚战，逐步又将通过率提升并稳定在95%左右，直至在最终发布前回到100%，并以此循环往复。
通过测算，发现一个典型的功能测试团队（如5～8个人）如果只配备一名全职的自动化测试工程师，那么他的时间基本都被排错的工作占据了。只能在两个发布的间隔期，也就是每季度有1～2个星期，这个团队才有时间和精力去增加他们的自动化测试用例。当然，这个速度是远远赶不上手工测试用例增加的速度的。很快，这种挫败感会降低实施自动化测试最初给团队所带来的乐观与兴奋。如果不及时应对，甚至会动摇管理层对于自动化测试持续投资的信心。
1.5.2 低优先级的自动化Backlog
随着新特性的开发需求量的饱满，导致许多产品经理（PO）不得不去安抚客户耐心等待。而忙碌的SCRUM团队的一个正常的举动，就是Sprint计划会有意识地降低对于属于“技术债”的自动化Backlog的选取率，集中精力去完成产品开发的工作。
1.5.3 破窗与“造轮子”
当一个自动化测试框架的缺陷从被报告到它的修复经常超过一个月的时间，这自然而然就引发了破窗效应。类似的这种行为很快从个人蔓延到整个组织，由此带来的后果就是许多以前尝试利用Selenium作为他们Sprint自动化测试一部分的开发团队，率先放弃了这一测试方式，并重新回到了不测试或者只有少量API/单元测试的时代。
An君和其他投身于自动化的测试工程师一样，无奈选择了加入再“造轮子”的行列。这一行为也导致了在用例中植入了许多原本属于框架部分的Selenium代码。
如果有机会回过头去看那一时期的自动化测试框架的缺陷，很有意思的一个现象就是，经常有些缺陷的描述信息或者附件里面包含了测试人员提供的如何修复该缺陷的 Java 代码，甚至是一个完整的重构的类。