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