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