为了规范整个开发测试流程的管理，包括开发、测试的交互，我们又制定了轻量级的 SQA框架，见下图：

图：初制定的SQA框架

　　不过此后这个框架也发生了比较大的变化，做得更好、更轻量级。无独有偶，我偶然的机会买了一本朱少民老师的：《全程软件测试》，发觉这个SQA框架也是渗透到目前的每个环节，更适合目前团队的scrum模式，在此也要感谢@朱少民老师，真是相见恨晚，不然可以少走很多弯路！！！

　　大家可能会问：Scrum模式、用户故事，测试人员怎么利用？为什么想到这个？如果遗漏了测试场景，团队会很不爽，怎么避免呢？结合Aullyxiao的《软件测试之魂》提到分层测试的想法，想了想，还可以这么整：

 

图：分层测试图

　　对于目前的开发架构来说，一个用户故事，涉及这四个点，可以从这四个点入手来进行质量保证。如何做呢？单元测试开发人员处理了；代码审查，测试人员可以参与和监督，其实是要保证：将开发任务与提交到SVN的代码进行关联。这样一来，当测试人员检查开发任务的时候，可以找到改变过的代码。我曾经试过从这些代码里面查看逻辑，找到分支场景，补充到测试用例里面。

　　在此期间，我还看过架构师Jack原创的《功能测试用例基础设计模型》，这个文档2天转发已超过150次，我也向所有同行推荐该测试设计模型实例化的测试用例，供大家消化该设计模型。

　　我当时还借鉴了季哥来自淘宝的《探索式测试》系列文章，包括：《我对探索式测试的体会》、 《组合测试法中的全对偶测试法》、《探索式测试实践之缺陷大扫除和结对测试》。

　　当然这么多东西，我觉得自己还需要时间来消化。

　　继续测试之路??路上的风景

　　也许会有人问：有没有后悔做tester？

　　我过去也常问自己：做得开心吗？产品质量提升了吗？看到自己的前景了吗？找到high点了吗？

　　现在我可以回答：OK，我做到了，并且还可以持续做得更好。

　　可能有很多测试人员会问：测试人员的价值到底何在？在这里，我套用和整合@朱少民老师的一些术语，给出我的回答。

　　我认为，Scrum中测试人员价值应当体现在：

　　1、预防缺陷的手段，提高洞察力，增强业务知识。

　　缺陷在需求、开发前期已经存在了，关键是用什么手段去挖掘出来预防。在sprint前获取到的需求，测试人员可以站在客户角度上来阐述自己的观点，与开发人员进行充分交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。

　　2、在开发过程中，测试人员除了站在客户的角度进行测试，还应当提供更全面的质量反馈，包括代码质量的检查，这个可以通过redmine与SVN双向关联来做检查依据。目前整个过程测试人员尚未参与代码编写，应当参与并推进代码评审，将代码问题及时反馈出来；并且参与或者推进单元测试，检查单元测试状态（确保单元测试达到80%以上覆盖率，帮助开发人员开发出具有良好可测试性的代码），自始至终将质量问题及时反馈出来，保证在sprint的整个过程中质量受到足够的关注，提高质量改进的持续性和可视性。

　　3、随着版本任务的增加，每个版本回归测试的成本增加，可以适当考虑部分稳定功能进行自动化测试。当然，这是远景。

　　4、持续改进、反馈，充分发挥每个版本统计报告的作用，对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。

　　测试人员，应当在自己的道路上看到风景，以前作为开发，写好一个功能，很high；测试人员也要有这种心境，提高了产品质量，预防了缺陷，很high。找到自己的high法，才可以把测试玩得更爽 ，我知道朱少民老师、季哥来自淘宝、段念-段文韬、架构师Jack，都玩得很爽，但是有一点：要爽得靠自己，多跟高手交流，有利于提升自己，但是不要刻意复制别人成功的经验，因为每个团队的模式和环境不大相同。

　　总结

　　每个人离开自己熟悉的领域，投入到新的领域中（说实在软件测试也囊括了开发领域），必然存在一些迷茫，不知如何入手，身边如果有一个靠谱的高手，指点一下，眼前将会一片明亮。可惜，现实总是残酷的，往往很多时候，都要靠自己去摸索，只有经历了、深刻体会了，才知道如何改变，以及如何迎接新挑战，调整到恰到好处的心态。这样子，才能够稳健进入转型的轨道。不要害怕改变和投入，一定要坚定信念，在前进的道路上，多参考同行的成功经验：朱少民老师、段念-段文韬、季哥来自淘宝、架构师Jack、Aullyxiao，迎合团队价值，不断修正自己的偏差，走出一条华丽的直路！

　　我很庆幸，经历了一个测试团队从无到有的创建，同时也帮助开发人员掌握了一些测试的基本技能，用于推进质量保证，让整个团队达到共识。现在的我，只是刚过了转型的痛苦期，测试工作也仅仅是刚刚开始，还有很多有意义的事情需要去做。

　　路漫漫其修远兮，吾将上下而求索！