Infoq发布了文章，这里我还是吐槽原文，未修改的，让大家品味下：
2、无悔选择测试之路-路上的抉择、进取
有了流程规范，接下来是实施和持续改进，运用在一个项目上，先做了三个月吧，不停地测试，编写功能测试用例，也走了2条弯路：
1、用例花了大量时间编写，就连：打开浏览器，输入xx，点击登录，这个也记录了（这种是早期状况）。
2、我居然还请缨加入开发，因为看到一些任务完成不了，后来雷叔也指明，测试做测试应该去做的，如果我当时帮忙做开发，那么很多测试都完成不了，一样保证不了质量。
所以，测试人员除了要了解业务之外，使用简单、清晰的语言结构来进行测试之外，还应该准确定位自己，明白自己在整个版本迭代中，控制质量的位置！
大家可能想知道，那段日子锻炼了什么？那三个月无法忘记，每天高强度测试，用的最多的就是，功能测试：边界值、场景法；白盒测试。其实就是锻炼了测试的基础技能和流程管理。
后来测试管理逐步建立，但是在测试过程中，应当如何提高代码质量，也参考了敏捷开发中高质量 Java 代码开发实践:http://www.ibm.com/developerworks/cn/java/j-lo-agile/，做了一些适合团队的改进：
这6点不言而喻，这种迭代版本中java代码质量提升的模式，已经采用了将近一年，非常有效果。
同年Q2，对测试管理进行了改进，其中是受到，@段念-段文韬，组织敏捷测试（http://www.infoq.com/cn/news/2011/01/dn-agile-test-3）影响，采用类似“一页纸计划”的测试文档（在此要感谢@段念-段文韬）在redmine进行管理，之前每次整理测试计划，发送给开发人员，实际上耗费了一些时间，并且成效不大，现在的任务：需求、开发、测试，全部交给redmine管理，所有事情一目了然，对任何人都是可见的，有没有完成，进度如何，非常清晰。
ok，之前不是讲过检查表的做法吗？虽然覆盖了不少范围，用了一段时间，收效不大，决定改进，变成季度性检查，包括的方面比较多。
后来为了规范整个开发测试流程的管理，包括开发、测试的交互，又制定了SQA框架，轻量级的：
图 最初制定的SQA框架（2011年3月31日）
后来发生了比较大的变化，做的更好、更轻量级，无独有偶，买了一本@朱少民老师，的：《全程软件测试》，发觉这个SQA框架也是***到目前的每个环节，更适合目前团队的scrum模式，在此也要感谢@朱少民老师，真是相见恨晚，不然可以少走很多弯路！！！
大家可能会问，scrum模式，有很多用户故事，测试人员怎么利用？为什么想到这个，当知道遗漏了测试场景，会很不爽，怎么避免呢？加上@Aullyxiao的《软件测试之魂》提到分层测试的想法，想了想，还可以结合这么整：
对于目前的开发架构来说，一个用户故事，或许涉及这四个点，可以从这个四个点入手来进行质量保证，如何做呢？单元测试就开发人员处理了，代码审查，测试人员可以参与和监督，其实就是要保证将：开发任务与提交到svn的代码进行关联，这样子，当测试人员检查开发任务的时候，就可以找到改变过的代码，曾经试过从这些代码里面查看逻辑，找到分支场景，补充到测试用例里面。当然，在此期间，看过@架构师Jack，《功能测试用例基础设计模型》，也采用了其中一些；还有@季哥来自淘宝，的探索式测试，我觉得自己还需要时间来消化。