分类目录归档:其他

软件测试人员该何去何从?

“好多QA转PM,因为QA(的地位)始终是要低一些”

“我现在做的事情跟几年前没有区别”

“资深QA在项目上做的事情新来的毕业生也能做”

上面的话你是不是也有同感?我相信大部分人会这么认为,因为这些表面上看起来的确是这样的!

那么,软件测试人员或者说QA真的有这么惨淡吗?

对于开篇引用的几句话,我们一一来分析一下。

测试工作的价值不容置疑

“好多QA转PM,因为QA(的地位)始终是要低一些”

说这话是没有看到QA所做工作带来的价值。相反的,我认为QA之所以可以转PM是QA工作过程中获得的锻炼挺多的,不仅可以转PM,可以转PO,技术型的QA还可以转Dev。

其实,QA和PM并没有地位高低之分,只是分工和职责不一样,QA转其他角色并不是地位的改变,可能只是更加适合自己。积极主动的做好本职工作,都能为团队带来很大价值;做的不好的话,都同样的不能带来价值。况且,做的不好的PM可能影响到整个团队,所带来的价值远不如一个优秀的测试人员带来的价值大。

团队协作才能成功

我们应该以合作的心态看待这个问题,一直强调的团队为质量负责,需要每个人都有团队的意识,有分工只是因为兴趣特点和擅长领域不同而已,并没有高低贵贱之分。

质量越来越受到各行各业的关注,质量问题不容忽视。软件质量的保障工作,软件产品的测试当然也是非常重要有价值的,这一点根本不用怀疑。

只是,质量的好坏带来的价值不是那么直接可见的。反而需求人员多分析了几个需求,开发人员多开发了几个功能点,又或者多写了几个自动化测试,这些都是显而易见的,似乎带来的价值更大,更容易被人认可和重视。而另一方面,需求的验证、测试的设计、质量状态的关注、风险的把控、快速的发现和定位问题,这些是不容易被量化的,也就不容易被重视或尊重。

能力提升是关键

无限风光在险峰

“我现在做的事情跟几年前没有区别”

这是只看到所做的事情似乎没有差异,比如说都是一起分析需求、设计测试、测试story、写自动化测试等,可能的确几年前就做这些事情,现在还是做这些事情。但是,我相信只要你在做每件事情都能认真对待,有自己的思考和总结,就不会一样。比如:

  • 同样的分析需求,几年前可能只看到BA写出来的需求,看看有没有边角case漏掉了;而现在的你可以从行业业务角度去看待这个需求整体考虑的合理性,是不是能给用户带来价值、能给企业带来竞争力。这两者还是有很大的区别的。
  • 同样的测试story,几年前可能只是根据验收标准和自己想到的一些边角case去测试,一个story需要一天才能测试完;而现在的你,利用自己对于领域知识的掌握、技术的了解、系统功能的熟悉,结合自身这么多年阅历和增加的常识,半天估计能测试包含几个story的一个feature,或者一个junior测试人员测试过的story,你拿过来一下就能发现一些问题。这就是成长,这就是价值!

“资深QA在项目上做的事情毕业生也能做”

如果只是看所做的事情,可能还是停留在表面,跟上一条讲的几年前的自己和今天的自己一样。

当然,有很重要的一点,资深QA不能仅仅是工作年限长,得是有真正的能力,不然的话可能还不如优秀的毕业生。

QA能够随着年龄和工龄的增长,让自己的能力也能不断的提高,才能让测试工作有更多价值的体现。因此,能力提升至关重要!

那么,能力该如何提升呢?

能力提升路径

能力提升路径

看似相同的事情,不同能力的人做出来的效果不一样。为什么他解决问题的能力那么强?我们来了解一下学习提升的过程。

第一阶段,知识积累

通过阅读、听课、观看视频等方式可以获取到知识点,将这些知识点总结归纳之后,变成自己理解的知识。

这是第一阶段知识积累的过程。

第二阶段,经验积累

将所学知识进行试验,进一步用于实际项目,获取实践经验,不断反复的实践可以获得经验的积累。

这一阶段还不够,还没变成真正解决问题的能力。

第三阶段,能力提升

在实践中坚持回顾和总结,对实践过程进行批判和改进,并且举一反三的运用所学知识,将会实现能力的积累。

到此,就实现了知识到能力的转变过程。

积累和分享很重要

前面每个阶段都可以获取新的知识,然后经历同样的知识-经验-能力的转变,不断的积累,将会实现能力的提升;每个阶段都可以把知识或经验分享给他人,在帮助他人获得相应知识的同时,更是自身能力提升的一个非常好的方式。

多次反复的知识-经验-能力的转变,达到一定积累之后就会带来惊人的效果,这不是一个线性的增长。

在整个过程中不断发掘自己的兴趣点,将学习、兴趣有机结合起来,会达到事半功倍的效果。

终身成长

了解了能力提升路径,很重要的一点还有可能是我们需要转变固有的思维模式。这里给大家推荐我非常喜欢的一本书《终身成长》,书中讲到两种思维模式:固定型思维模式和成长型思维模式,具备成长型思维模式的人将更容易获得成功。我们需要更多的关注自身的成长,而不是关注外界、跟外界进行比较。

《终身成长》

前面所讲并不只是跟软件测试人员相关,可以适用于任何角色、任何职业的朋友,只是同样作为质量工作者,听到不少人的担忧,才撰写此文。

相信积累多了,就会发生质变!

最后,让我们一起多阅读、多学习、多实践、多思考、多总结、多分享,做到终身成长!

高效会议的13条军规

每天的会议太多了,我都没有时间写代码了…

最近天天各种讨论,我有好多story都没测了…

在蓝鲸项目经常能够听到这样的声音。这也难怪,团队大了,总有各种会议和讨论,沟通成本上升不少。但是我们不能只是抱怨,如何提高开会的效率才是关键。

前同事李光磊写过一篇《极限会议》就是讲的怎么提高会议效率,写的非常好。但其中的原则要真正实践起来可能还是不那么容易让所有人都能快速理解并实施。

本文通过故事的方式分享日常会议的常见问题,并试图从会前、会中、会后三个阶段来列一些相对比较基础的、比较容易落地执行的规则。

会前

场景一:突如其来的会议

一天早上,小青看了看时间,已经是9点半,半个小时后有个面试,这是上周HR就约好了的,他把候选人的简历拿出来看了看,想提前准备一下。

“小青,咱们几个去开个会,头脑风暴一下下周跟客户的catch up XXX的内容!” 突然听到有人叫他,小青回头一看,原来是老王。

“大概要多久?我十点有个面试呢。 ”

“看进度吧,估计得一个多小时,我半个小时前给你们几个发了邀请了。”

“那我肯定不行!我只有半个小时,你不提前看下日历么?再说你现在才发邀请,也没有提前准备啊,我对XXX不是很了解,感觉我没啥可以输入的…”

“快来不及了,时间不好安排,最近大家都忙。要不你先参加半个小时吧!”

小青没办法,只好去参加会议了,大家陆陆续续来到会议室,等人都到齐已经是9:40了…

小青非常不爽,对于老王来说,似乎这一切很正常,因为这样的情形在项目上并不少见。

从这个场景,我们看到有几个方面的问题:

  • 会议没有提前预定参与人员的时间,也没有查看参会人员的时间是否有冲突;
  • 会议没有准时开始;
  • 没有时间提前准备;
  • 小青可能不是合适的参会人员

场景二:Feature kickoff

BA组织某个team做feature kickoff,这是一个在原来某个复杂feature上的功能扩展,由于业务需要,对原feature的设计有改动。在讲解新feature的设计过程中,大家发现BA目前提供的设计可能有些问题,于是大家开始讨论和澄清原来feature的相关设计是什么样的,时间过去了一个小时,还没有正式回到新的feature的kickoff上来…

这个场景存在这样的问题:

  • 会议的目的是kickoff新的feature,但是新feature的设计并没有相关人员的确认(这种确认并不需要全team的人参加),而导致全team人都在的情况下,浪费了很多时间来讨论设计的合理性。这是会议之前没有足够准备的原因。
(图片来源:https://www.smartlinkin.com.tw/article/3137

从前面两个场景的问题,我们来总结一下会前的规则有哪些:

1. 确定会议目标:每次会议一定会有一个目标,只有明确目标,这是会议高效的前提。目标不明确的会议,可能没有开展的必要。

2. 确定会议议程:根据会议目标,把会议议程定义清楚,这样才能在开会的时候严格按照议程,准时结束。

3. 确定参会人员:尽量准确的确定参会人员。如果是讨论,要求参会人员都能有输入;如果是宣布某个决定,确保参会人员是需要被通知到的。如果邀请了不一定要在场的人员参会,对双方都是一个浪费。

4. 提前通知参会人员:定好会议时间、地点,要尽早发出邀请,这样有利于参会人员提前安排好其他工作或会议。同时,在发出邀请的时候,需要告知参会人员是否需要有提前准备的内容,比如组织某个讨论可能要提前收集、思考讨论的素材,组织workshop需要提前准备环境或者相关知识等。

5. 准备好会议需要的东西:不管是组织者还是参会人员,对要提前准备的材料、环境等都务必提前准备好,有时候可能还需要准备一些物料等。一旦有其中一人或者某一件东西没有ready,都会影响会议的高效开展。

会中

场景三: 某会议室10来人约两个小时的讨论

某team正在会议室开会讨论A话题,讨论已经进行到快两个小时,看得出来屋子里的人都有些疲惫,只剩下少数人还在说话讨论,其他有几个人在看手机或电脑,还有昏昏欲睡的。会开了这么久,原本要讨论的A话题没有得出结论,现在大家已经跑题到讨论B了。

“咱们原定时间是一个小时,现在超时太严重了!再这样下去也不会有结果…先结束吧!”终于有人受不了了。

组织者也发现大家有些失控,只好草草结束了会议…

小明本来很想参与A话题的讨论,但是跟另一个会议冲突,他没能参加。赶在会议结束时刻来到会议室,想了解一下大家讨论的结果。没想到并没有得出结论,想找组织者问问是否有大家发言的记录,他想整理一下看是否有什么发现,结果也令他失望,并没有记录…

从这个场景,我们可以看到会中的几个问题:

  • 严重超时
  • 没有控制大家的讨论范围
  • 有部分人并没有全身心投入到讨论中
  • 没有板书或者记录
  • 会议草草结束,没有结论,没有下一步行动计划

因此,总结会中的规则如下:

6. Timebox:严格控制每项内容的时间,避免会议超时。

7. 如果会议不能围绕目标展开从而没有价值,组织者应该提前结束会议;如果某参与者贡献有限或者没有贡献,TA可以选择提前离开后者组织者请TA离开。

8. 严格按照议程进行:讨论过程中很容易走偏,要注意及时拉回来,如果有新的需要讨论的内容,可以记下来下次再讨论。

9. 集中精力参会:非必须要用的情况下,所有参会人员盖上电脑和手机,专心参与会议内容。既然已经承诺可以参会,就不要担心其他工作被此次会议耽误,修build也不是会上看电脑的理由。如果真的有比会议更紧急的事情,可以不参会。(经常有code review或者feature kickoff的时候,有同学带着电脑一直低头忙着,不知道是在听会议内容,还是在忙什么。这样的情况需要尽量避免。)

10. 确定下一步行动计划:每次会议都需要在会上确定下一步行动计划,如果没有该次会议相关的下一步计划,也需要明确。

11. 做好会议记录:清晰记录会议的内容很关键,不仅可以share给没能参会但需要了解的人,也可以作为后续参考用。最好是在开会期间有人直接记录,而不是会后会议再记,这样能够记得清晰也更省事。

会后

场景四:某team的回顾会议

按照惯例,回顾会议开始都先回顾一下上一次的action。今天的组织者是小树,他找了半天没有找到上次回顾会议的总结邮件,也不知道上次有什么action… 原来是上次的组织者在回顾会议结束之后,忘了发邮件了,好在当时拍的照片还在。对照着照片上的action,发现其中有两三个并没有完成…

这个场景的问题是:会议总结没有在会后发出,action也没有好好执行。

由此,我们可以得出会后需要遵循的规则有:

12. 发出总结:组织者需要针对会议结果进行总结,并且发送给所有需要知晓的相关人员。总结需要包括会议讨论事项、讨论结果、action及其owner等内容。

13. 执行相应的action事项:所有参会人员都要按照会上讨论的结果,执行好自己own的action,不要到下一次会议的时候发现action还没有做,这样非常影响会议的效果。

写在最后

大团队的沟通成本很高,高效沟通非常关键,而涉及多人的会议或讨论更是需要高效开展。前面描述的规则执行起来并不难,但是需要大家都能有这个意识,齐心协力,严格执行。