• 我是楼上。原来默认是匿名。

  • 聊一聊职业发展 at 2018年12月03日

    如果我年轻的时候就悟到这些,有多好。😄

  • 聊一聊职业发展 at 2018年12月03日

    试着答一下啊。
    1.都要依托。如果没有复杂的环境和复杂的问题需要解决,时间长了人就会蹉跎,面试的时候遇到了很多这样的同学,被自己一成不变的工作耽误了,在职业生涯的中早期,平台的好坏其实更取决于它能不能制造一大堆问题让你解决,成为你成长的养料,而不是普通意义上的高大上就是好公司,举个例子,前两年有一段时间总接到一个著名外企的工程师应聘,但是存在一个通病:公司平台把什么都封装了,应聘者也没有去研究怎么封装的,为什么要这么做,做了多年的"点点点"同学,虽然有准一线大厂的背景,但是能力上几乎丧失了竞争力。 但是,如果平台不错,你自己蹉跎了自己(看不到问题,不愿意解决问题),那也不行,面试时候也遇到了很多这样的同学,很多问题视而不见,这样工作多年可能和工作一年没啥区别。 还是努力能力增长-》换更有挑战,也回报更高的工作。这种正向循环最重要。

    2.小公司更重视结果。小公司问题也往往十分多,你能把这些问题清晰的定义出来,给出改进指标,把收益说明白,然后做到了,很容易得到认可。实际上小公司是更容易争得话语权的,因为里边能人不多,稍微优秀一些就能体现出来。举个例子:在上家公司的时候,有个测试小伙伴就做到了一点:比产品懂业务细节,所有开发的代码做CR,懂的所有的代码细节。慢慢的,他变成了团队中话语权最强的人,因为他总能指出别人的错误,说的特别在点子上。所以每次考核总在前边,所有团队成员都很佩服,重大产品方面决定很多都会咨询他,是否能上线基本上也是他说了算。工资自然是涨了很多。 另外一个建议是别给自己设限,别把自己只定位成测试,例如,如果自己是最懂产品的人,小公司很容易转变成产品,甚至产品总监。 有准备并抓住机会的话,小公司很容易胜出,见过很多这样的例子。

    3.我觉得其实还是问题驱动,努力解决好你眼前的问题,被认可,其实就全面发展啦。一个我非常佩服的同事的一篇文章供参考:http://www.qkey.top/ce-shi-kai-fa-gong-cheng-shi-de-career-path/ (上边也贴过) 我十分认同
    另外从市场角度看,其实:安全测试工程师、性能测试工程师这种工种的岗位需求是很少的。原因两点:1.小公司需要人是万金油,啥都做。2.大公司全部平台化服务化了,实施没有啥技术难度,很多人依托平台很快上手。大厂,很多性能测试是开发自己完成的,调优也是开发完成的,不需要什么专职的性能测试工程师。

    4.职级越高,需要懂的东西越多,因为懂得足够多才能正确决策。其实在我心中质量是所有人的事儿,“测试开发”的定位是用自己的开发能力更好的保证系统质量。比较认同google团队中的职责划分,具体可以参考: https://testing.googleblog.com/2016/03/from-qa-to-engineering-productivity.html

    5.不是大神,共同学习。

  • 聊一聊职业发展 at 2018年11月19日

    又被面试啦,简要答一下:
    通用的思路:
    基于风险的测试。测试的本质是抽样,时间资源总是有限的。要把资源用在刀刃上。先看看那个模块是干嘛的,是不是重要,如果出问题,影响面有多大?然后具体问题具体分析。如果是核心模块,会造成重大损失,那质量一定是不能丢的,抽调别的力量加强这块儿投入,把风险明确的传递给主要干系人,必要时延期项目。如果是非关键模块,识别出问题,可以做:设定一个最小实现目标,砍feature,用运营/客服的手段补足。长效方法:自动化防护网建立,让回归的时间成本、人力投入成本低下来;在项目的初期就能够一定程度的识别这种风险,早加资源,别让这种事儿变成到了最后:一坨毛病,deadline不变。 QA最大的一个价值就是:像探照灯一样很早的预期到风险,并同步给主要干系人。

    其实这类问题,主要是看看你以前在项目里怎么做的。实战经验非常重要,能积累很多“土方法”。

  • 聊一聊职业发展 at 2018年11月14日

    http://www.qkey.top/ce-shi-kai-fa-gong-cheng-shi-de-career-path/ 阿里的测试最高P的职业路线的建议。

  • 聊一聊职业发展 at 2018年11月08日

    你很可能会遇到短板。短板是:可能无法让团队变成一个技术型团队,来应对越来越多挑战。如果公司转型,会比较痛苦。
    谈一谈我的观察。在多年前,有很多离岸的测试中心,印度的infosys ,文思、东软的测试外包兴盛年代会有大量这样的机会。但是离岸外包测试的岗位这几年在大幅度收缩。传统企业也在转型,同研发过程结合越来越紧密的QA的工作范畴大了很多,技能要求也在逐步加强。只掌握黑盒技术的TL无法带领团队很好应对现有的挑战,所以这样类似的职位是会不断萎缩的。这是大趋势。

    能够知人善用,找专业的人来补充技术的短板,自己own起整个质量解决方案是一条路,我见过一些成功案例,一些管理型的TL能够走到比较高的位置,也能把团队带的很好。不过它有几个前提:1.你能搞的定领导,他只信任你,认可你。如果你的领导只关注结果,你又能搞的定结果,这是走得通的。2.你能搞定底下的小伙伴,他们愿意这样跟着你干,技术好,综合能力强的人愿意甘于你下(长期下来这点挺难的,如果你无法正确作出技术决策,无法给底下小伙伴方向上的引领,人家凭什么服你,开心的长期跟你干?)3.大团队的历史:你跟团队长期奋战,一同成长,团队飞速发展,你被顶到了那个位置(如果空降,只有所谓的纯管理能力,还是挺难的,我没有见过这样成功的例子)。4.持续补足自己的技术短板,不见得是具体的怎么撸代码,而是要了解业界主流技术,他们能解决的问题,长处短处,你的团队是否需要他们,团队里谁可以撑起来。5.对你所在公司的业务要全通,尤其是IT系统需要支撑的业务要精通(不多说,这点很重要)。6."技术管理"能力真的行(什么是技术管理能力,可以参考底下那本书)。

    推荐的书:成为技术领导者 最近去世的大师温伯格写的,系统性论述。我是几年前读的,对我一直影响很大。

  • 可以实现个chrome extension开源:)

  • 跟被测物同语言最好。

    1. interop 不会有坑。
    2. 开发能读懂,沟通不会有坑。
    3. 如果是单元测试或者结合很紧的接口测试可以跟生产代码放在一起。加入CI经常跑,保持有效性。
  • 聊一聊职业发展 at 2018年10月12日

    不同团队差异很大的。整体的导向是让开发承担更多质量活动,提高开发测试比。

  • 聊一聊职业发展 at 2018年10月12日

    推荐的就是那本 The little black book on Test Design

lxg0618@163.com 其实很少用gmail了。。。