现有的各种测试相关文档都很齐备，但是已经有较丰富经验的我感觉到其中的信息有很多都是不必要的冗余，老早想把它们给简化简化。因为我这个人总觉得，如果是没有必要的或者不需要的信息，为何一定要放在文档里呢，直接不写不行了么？放在那里总会吸引人去看一眼，然后心想“哦，N/A。”，这也是时间和精力的浪费啊！保持文档干净整洁，只记录有意义的信息，不是很好么。而且，在原来的测试管理工具中，测试用例和测试计划，都有很多不同的版本，针对的是不同的产品发布版本。版本多也好的，但问题是有的时候时间上新的版本不一定是信息新的，对于后续的测试人员来说，这会增加他们的工作量。还有是每一份测试计划所描述的都有局限，所有的信息都是针对当时的那个版本测试任务，针对其中所要验证的功能，而这只是被测对象所有功能的一个子集，看不到一个整体的景象。

　　Scrum试点项目提供了这样的一个机会，可以去操作这种简化，因为我是第一个，也是项目团队数量扩张前的一个测试出身的团队成员，一定程度上享有一锤定音的权力。而Scrum这种开发模式，要求测试用例的全集必须能持续地体现被测系统的全景，因为每一个迭代所新开发出来的功能都要进行验证，而之前已经存在的功能也需要进行回归测试（其实在敏捷的方式下，“回归”这个说法已经没有了意义），因此我们必须随时都掌握着当前新的测试用例集合。而另一方面，增量式的开发需要频繁地回归验证以前的功能，对手工测试的方式来说这是不可能完成的任务，必须秉持自动化的思想，而这也正是我的坚持。不过当时我和Scrum Master以及项目经理在自动化上的意见有些出入，为此交流过无数次，我记得后我们还是坚持了自动化的想法，因为我确确实实做到了。

　　自动化的地位得到提升，间接地使得另一个问题浮出水面，也即测试计划。在传统的模式中，由于测试工作大多根据模块或者领域来划分，以单个项目的形式来进行管理，持续时间较长， 每一个测试项目所要验证的功能数目也比较多，因而需要安排一个单独的测试计划环节，还需要产生出测试计划文档，并且由相关人士来评审。但是在Scrum这种迭代增量式开发方式下，每一个迭代所开发的功能数量都不会很多，而要执行的测试用例却呈现不断增加的趋势，因为它要执行新功能测试用例加旧功能回归测试用例。对于测试计划这个活动来说，如果每一个迭代都要开测试计划评审会议，产生测试计划文档并且得到批复的话，将会是一笔非常大的管理性开销，而且每一个测试计划的重复信息量都很大，还会产生很多的版本。因而测试计划这个活动在Scrum模式下必须得改变才行。

　　还有一个收到影响的是缺陷追踪实践。我们也是4个人的团队，而且都坐在同一个会议室里，面对面肩并肩。如果发现一个缺陷，还得打开IE浏览器（呃，其实我用FireFox更多一点），打开缺陷追踪系统的网页，输入各种信息提交缺陷报告，等待邻座的开发人员在专心写代码的时候收到通知邮件，打开网页，研究分析缺陷相关的信息，然后再给我提要求，然后我们再通过网页来回几个回合？当然这样做很没有必要，我们自然是可以面对面交流的，但是交流完解决了问题，我们是否还需要记录呢？将这样的问题记录到缺陷追踪系统中去，到底有没有意义，毕竟记录信息也还是要花时间的，而这样的问题可能在一个迭代里会遇到很多，还有可能很多缺陷并不是什么大问题，几分钟可能改好了，要记录吗？

　　还有一个问题是，在传统的模式中，等到测试人员开始工作，通常都是代码已经开发完毕，有较稳定的产品版本供测试人员使用。但是在Scrum的模式中，在一个月的迭代周期里，我们是否也应该如此操作？这样做的问题在于，在迭代刚开始的那一段时间里，开发人员很忙，测试人员却很空，空得无事可做，到了迭代快结束的时候却是忙得不得了。更让人担心的是，如果这么晚才开始测试，测试又发现了不少的软件缺陷的话，剩下的时间根本不够给开发人员用来修复缺陷。这样的开发过程必须得有变化。还有是，每一个迭代都会拿到不同的新功能开发任务，但这些新功能的情况会有不同，有的功能开发任务相对较轻松却需要花不少功夫测试，有的功能则是开发很困难测试很容易。因此必然会出现在一个迭代当中，开发测试工作所需要的工作量比例不同，但此时开发测试人员的比例在一个团队中确实保持不变的，在Scrum保持团队稳定的原则前提下，如何处理这样的情况呢？

　　这些都是我想要利用Scrum试点项目这个机会，或者是作为Scrum试点项目中的测试人员必须要思考解决的问题。