这次IAGW的测试，代码没有按时提交，原计划上周四完成的代码，今天还不能提交测试，delay了两天，因为计划跟实际实现有偏差，也有部分原因是其中的管理协调工作没有做好，不过项目不紧张，delay一两天倒没什么影响.我担心的是他们没有做好单元测试，提交的测试会出现很多问题，也有点担心大家在工作的时候还没有一个非常明确的时间观念，自觉要求自己按时完成该做的工作。通过这件事情，为了提高整个团队的工作效率和产品质量，我决定在今次的测试引进测试阶段周报告，每周末花一个小时整理过去一周的测试情况，目前想到的统计情况包括：缺陷统计、主要缺陷描述与分析、进度状况、以及目前存在的问题、风险和建议。我想通过对测试每个测试阶段的总结和分析，可以及时反映当前工作状态、存在的问题，帮助项目小组成员了解当前的项目进度和发现并解决现阶段存在问题，推动下一阶段工作的顺利开展。这也算是对自己测试工作的监督吧，否则花那么多的时间和精力去设计的测试计划，就没有任何意义了。而且，自己都没做好，怎样要求别人也做好呢？
虽然今天产品没有提交测试，不过工作还是非常的忙碌，需要整理产品文档模板、重新调整测试计划与测试要点、全面考虑报表的功能并给开发提建议，还有就是各开发之间的工作协调。今天上午主要的工作还是协调，了解项目的进展，协助开发人员之间的工作，为他们整理相关的文档模板，这次项目的开发，缺少了一个统筹全局的角色，开发人员之间的工作没有协调起来，这一点以后需要改进。在目前没有合适这样的觉得的情况下，我应该做好相关的协调工作，以提高整个团队的工作效率，不过意识到这点有一点点晚了，因为项目的开发已经接近尾声了。
因为事情太多，中午都没休息，终于在大家下午上班前把文档的模板给整理好了。这次文档的编写，做了一点改进，就是先花时间整理好文档的模板，由各模块的开发负责人补充，最后由QA整理与完善，以前所有的文档都是由QA完成，而这个改进可以大大减轻QA的工作量，也可以让QA有充足的时间来审核和完善相关的文档。
下午进行统计报表的设计，对比梦网在实际开展业务需要使用到的有效统计和目前产品的统计需求，整理了一份统计报表说明文档。没想到几个报表的设计花了差不多下午的时间，虽然花了比较多的时间和脑子，但设计能力和业务分析能力得到了一个比较好的锻炼，这个时间的花费是值得的，以后可能还会遇到更多的未知的情况需要自己花力气去思考去设计的。关于设计，其实，还有一个工作要做的就是制定统计规范，这个工作应该在设计阶段完成的，那么开发在代码实现的时候就可以根据规范来做统计，避免在测试中出现太多的问题了。完善的规范是一个好东西，可以作为软件开发和测试的依据，不过，如果规范不明确或有歧异就不好了，就正如局方这次下发的规范一样，很多地方的定义模糊不清，还有些地方相互矛盾，以致我们在代码实现和案例编写的时候遇到了很多麻烦。一个团队的工作有赖于规范，就如一个国家的统治有赖于制度一样，我们的社会，从来都不缺少制度，只是缺少制度的执行者，因为制度的不完善，因为人太聪明总挑空子钻，导致我们的制度的执行力度总是很弱。不过一个团队的软件开发，就没那么复杂了，什么问题都可以拿出来谈，只要是合理的规范也都会很好地执行。
因为上班一整天都在干活，下班的时候挺累的了，下班就想走了。以往比较大项目的测试，在测试阶段总是要加班，希望今次能够将效率提高，在上班时间完成必要的工作，下班则做自己该做的事情。不过，测试任务摆在那里，deadline已经确定，能否在上班时间按质按量完成，就得看我们的工作效率以及与开发之间的配合默契度了。
最近广州的天气太热了，晚上躺在床上一个劲地发热冒汗，好长时间都没睡着。我有个不好的习惯，睡不着的时候，一定要给某人打个电话或发条短信，似乎就是那么简单的几句话就可以让我心情平静下来安静入睡了。
后记：关于昨天设计的统计报表，今天听到了不同的声音，有同事提出了新的建议和疑问，这样的讨论，其实应该在设计阶段完成的，在数据库设计review的时候我没有全面考虑清楚应该如何呈现，没有及时提供建议和组织讨论，的确是我做得不好的地方，早上在我回复建议的末尾，很诚恳地向我的同事道歉。虽然现在的讨论有那么一点点晚了，但是late better than never，而且，如果是在上线之后客户才提出来，那么修改的成本就更加大了。讨论之后，最终数据库表结构还是没有修改，而是呈现的时候采取了我的建议，这个不太规范的数据库设计，一方面目前的表虽然扩展不容易但可以满足目前的需求，另一方面开发也觉得修改起来改动的地方太多。这让我有点担心以后的扩展，我有点不是很清楚自己该继续坚持他们重新设计，还是应该接受目前的设计呢？