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