后台回复「MTSC」,领取大会 PPT
阅读本文大概需要 5 分钟。
之前在文章《关于测试行业的高端局和低端局》中我有提到高端局和低端局的问题,还处于低端局的自己,总不能免俗的会和朋友吐槽目前的一些测试现状。
比如测试过程中反馈的问题不受重视,发布上线有用户反馈了才紧急修改。
比如对产品和开发的业务建议,有可能被理解为怀疑和不信任,从而导致沟通中的隔阂。
比如作为业务测试,对辅助测试工具和系统的把控不足,但又不可或缺,导致对他人依赖太重。
我还没列完,朋友就回了一句「所有的抱怨都是在展示自己的无能」。
刚开始我还愣了一下,接着我就给回复了 32 个大写的赞。
一、抱怨解决不了实质性问题
除了赞同这句话总结的精辟之外,我主要赞同的是考虑这个问题的新角度。
抱怨是表面现象,抱怨的本质是希望别人做出改变,这几乎不可能,不然也不会演化到抱怨这个程度。
所以抱怨并不能解决实质性问题,除非你是运用抱怨的策略让别人妥协(可行么?)。
与其抱怨,不如用这个时间去考虑如何解决问题,从而在务实的角度推进事情往更好的方向发展。
比如上面关于给产品和开发建议的事情,如果只是觉得「我有理,就应该听我的」,当然会引起别人的反弹。
或者一开口就是「你这样不对,你应该……」,更是无情的打脸,别人作为对应领域的专业人士,肯定是有他/她这么做的道理。
所以这些可以看着出发点是好的,只是好心办坏事,当然我们也可以抱怨对方玻璃心,但是但是但是,抱怨真的解决不了问题。
请停止抱怨,转身朝解决方案的方向去行动。
当然,这个过程肯定会有很多的困难,那就一个个解决就好了,只要我们盯着的是解决方案,肯定能找到办法,那怕是一个需要暂时搁置的方案,也算是对问题有一个正向的解答。
二、有人把问题当作机会
如果我们已经调整了抱怨的方法,用实际行动去解决抱怨的问题的话,已经无形中就在利用这个机会了。
比如上面第一个关于反馈的问题,分析出来的原因是「测试人员提出来的异常处理,不能确定外网出现的概率,所以在优先级评估上会出现失误」。
其实这就和是否是测试提交的无关,关键是怎么去证实这个问题出现的可能性,之所以用户反馈就有效,是因为用户是真实的用户,这个属性已经证明问题出现的可能性。
如果从这个角度出发,我们的解决方案可以有两个。
一个是从历史案例中搜索和本次问题相关的反馈记录,用真实数据去证明自己反馈问题发生的可能性;
另一个是借助运营等其他角色,剔除测试角色的专有属性,通过他/她的测试结果来间接证明反馈问题发生的可能性;
如果借助上面两个方法最终说服了产品,那么就形成一套可行性解决方案,后续类似问题套用就行了。
如果没有说服产品,产品上线确实收到了用户反馈,那就作为案例进行记录,下次出现类似问题时,就可以当作方案一的证据进行使用了。
如果上线后确实没有收到反馈,那么就总结下用户之所以没有反馈的原因,哪些是我们没有考虑到的,总结的内容可以作为下次判断同类问题优先级的依据。
总而言之,言而总之,只要朝着解决问题的思路去做,不管结果如何,最终都能有所收获,积累起的这些收获就是我们的经验。
三、改变自己才能获得进步
再回到前面的话题「所有的抱怨都是在展示自己的无能」,请允许我再次夸赞下这个总结,再次夸下这个角度的刁钻。
我们都知道,学习能让人进步,所以我们要接受二十多年的专业教育,以及入世后的各种再教育,仔细想想,这些过程其实都是在改变自己,也可以叫塑造自己,亦或者打造自己吧,反正改变的是自己而不是别人。
从这个角度讲,需要自己的改变去适应新的变化、解决新的问题时,如果自己能顺应变化去改变自己,就能吸收新的经验,获得新的进步,只是期望别人的改变,不仅对自己无益,还可能碰一鼻子灰。
以上,结合自己对目前项目实践中碰到的三个问题进行一下自我反思,不知道你是否认同这个观点,或者有其他更好的解答,欢迎留言和我讨论。
当然,如果你觉得自己有所收获,欢迎分享文章到朋友圈 + 点个「在看」让更多人看到,谢谢。
感谢你的分享、转发和在看,我准备了一个抽奖,8 月 20 号上午 8 点 15 分自动开奖。
推荐阅读: