最近一直在忙工作，已经很久没有在这里发文了，真的很抱歉！
最近在忙什么呢？还是在忙test architect的工作。这几个月的工作让我对test architect也有了更深的认识。
就说说我最近做了些什么吧。
我首先是深入到每个领域，了解他们是如何做测试的，测试的范畴、策略和方法，尤其是call processing这一块，为了有更深的了解，我还做了些case。
和每个领域的technical leader都聊过天，也记录了他们现在存在的问题，同时根据他们提出的问题，想办法来帮助他们解决。
其实我个人非常迷惘，因为所谓技术上的support概念是很模糊的。如果是实验设备不够，有项目经理和直线经理来解决。如果是需要测试自动化，有测试自动化的项目组来解决。我一开始花了很多时间在测试自动化上，但后来证明这些时间是白费了，因为后来基本上是自动化的项目经理直接找各个组的technical leader了，而我过于热情的参与反而引起了负责人的不满。我一开始想提出仔细选型，不要盲目上马，可惜测试自动化的压力很大，项目经理的个人经验已经决定了选型的结果，我也不好再说什么。
后来通过真正开始做测试，才发现现状并不如那些technical leader们表述的那样，而是比那个糟糕得多。我才发现我们非常不重视test plan的review，test report的review根本就没有。case写得五花八门，有春秋大义型的，有絮絮叨叨型的，而且基本没有coverage的check和记录。
我开始把我的工作重点转向需求的测试覆盖上了。很意外的是，有些组的同事根本不看系统需求文档，而直接看实现文档，很多系统需求被漏掉了。他们的test plan进行review的时候，更关心细节，而不关心测试的需求覆盖率，场景覆盖率和error case。其实这些才是测试的重点，而不是具体的操作步骤。没有测试报告，就无从知道软件质量到底怎样，也没有测试人员的任何反馈。
我开始要求加入到所有的test plan的review meeting上，并且要求必须有test report的review meeting。Quality Manager也和我一起制定了test plan文档的template，其实这些东西以前都是有的，搞了敏捷之后全扔掉了。当然我们还加上了测试人员对软件质量的反馈一章。我设计了一个checklist表格，以帮助测试人员检查和记录case的覆盖率，并且在plan review时一起过这个checklist。
测试人员的心态很有意思，当我提出要加case，或者加步骤的时候，他们通常是很反感的，好像增加了他们的工作量，并且让他们很可能完不成任务。我写了一篇文章，告诉所有的人，测试人员的职责不是pass case，而是通过case的执行，找到系统的bug。找bug才是我们的工作。我们必须保证当我们的case pass的时候，我们的系统工作是OK的，是会让用户满意的。如果做不到这一点，就是失职。只要系统还有问题，我们可以义正词严地不让case pass，而不是心慈手软地放水。要知道，放了水，责任就在测试人员身上了，这是引火烧身。
为了加强内部信息共享，我们买了一个
服务器，专门用于文件共享。我们成立了一个四人小组，负责文档的整理和介绍工作，以方便所有的测试人员能够最快地找到需要的资料。
我设立了一个内部技术交流网站，以加强测试人员相互间的信息和经验交流，可惜的是，只有少数几个人经常光顾，大多数人都借口工作忙，几乎从不上这个网站。我在内部网站上分享了很多有用的工具和个人的经验，可惜效果并不明显。大家还是比较习惯于通过邮件被动地接收信息。我只好同时写文章和发邮件，双管齐下。
为了减少开会的次数，我协助将培训的过程全程录音，做成video，这样大家就可以灵活地安排时间接受培训，而且可以反复地听讲。我已经做了不少录像，目前效果还不错，已经减少了一些有经验的工程师手把手教的频率，也希望靠这个办法让大家增加一些自学的能力和习惯。
总体来讲，我几乎没在搞什么技术工作，而在做一些杂事，更有些像个打杂的。唯一还算是技术相关的，就是参与到最新的release的需求制定中。因为要early involvement，我们测试人员被要求参与新feature的需求制定，提出testability相关的意见。我的一部分主要工作也是这个，和我们部门指定的feature owner一起，加入到制定需求的流程当中。这个过程还比较有趣，也是我比较喜欢的。
还有一个工作，就是整理customer报的bug，分析我们的工作有哪些缺失，及时地补足。这个工作比较繁琐，不过也是有意义的。正如温伯格所说，投诉是存在质量问题的信号。整理和分析投诉，是向所有的测试人员和管理者展示我们的工作有多糟糕的有力工具。
好了，忙忙碌碌中，先写这么多了，希望我的这些努力不会白费，我们的质量会有所提高。
