去年开始，下定决心闯入互联网，不为别的，就是冲着互联网浮躁的薪水。
一年多时间以来，从公司的第一个测试工程师，到现在15人的测试团队leader，别人叫我测试总监，但我觉得我只是一个测试团队打杂的人。培养了几个骨干，分担了不少活。
在这一年的时间里，每次我面对乱七八糟的开发流程，我都拿敏捷来安慰我自己，告诉我自己这就是互联网正常的敏捷开发模式。但在每一次大版本上线后，面对线上问题反馈，面对数据修复，面对开发焦躁的表情，面对老板一次次的抱怨。测试作为开发流程的最后一关，总需要进行一次次的总结，和被教导，需要进步。然后我一次次的总结，一次次在例会上咆哮：
1.需求可以再完善一点吗？改动能早一点吗？
2.开发人员需要懂点业务吗？需要自测吗？能不能别没开发完成就说提测？
3.发布版本频率能不能控制一下？一天别动不动就丢页面，丢JAR包上去？
总结之后，大家也就意识到团队是问题，团队，测试只是一个环节。团队需要项目经理去打造，我能说的能做的不多。
但这次总结，我想总结一下，在这样的开发流程下面，测试应该怎样面对，说直接的就是该如何存活？
1.必须做好反馈。测试从始至终，大致过程就是预防BUG、发现BUG、总结BUG。其中最关键的当然是发现BUG了。所以发现了BUG要及时反馈，在敏捷下，很短的测试时间里，大概就3-5天的测试时间，耽误不起。所以发现阻碍测试的问题，必须马上反馈。所以，我成立的反馈机制如下：
1）项目测试进度日报：已经进入提测阶段的项目，项目测试负责人在完善下班前，必须发出当天进度邮件，陈述当天的测试进度。什么功能可测，是否通过，什么功能不可测，为什么不可测。
进度日报的作用，个人觉得有以下作用：
1.曝光开发进度，开发人员为了满足进度，在没完成开发就提测
2.项目经理只问能否上线，但不跟进测试过程遇到的问题，比如测试环境，就通过邮件声明测试进度
3.邮件备案，一旦延期，项目经理难逃其责
2）项目测试进度周报：每周四晚上，项目测试负责人要发项目测试进度周报，这主要是例会需要，因为是老板最关注的。
后补.......
