我目前的测试架构师的工作

    最近一直在忙工作,已经很久没有在这里发文了,真的很抱歉!
 
    最近在忙什么呢?还是在忙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,分析我们的工作有哪些缺失,及时地补足。这个工作比较繁琐,不过也是有意义的。正如温伯格所说,投诉是存在质量问题的信号。整理和分析投诉,是向所有的测试人员和管理者展示我们的工作有多糟糕的有力工具。
 
    好了,忙忙碌碌中,先写这么多了,希望我的这些努力不会白费,我们的质量会有所提高。

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/tech/opensource/191228.html

(0)
上一篇 2021年11月14日 15:17
下一篇 2021年11月14日 15:17

相关推荐

发表回复

登录后才能评论