前言
前几天，看到一篇国外博主 Vitaly Sharovatov 的博文, 谈到 认知一致性陷阱 在企业和研发团队中的，因为 认知一致性陷阱 的存在，往往很多本可避免的错误决策被推行。而测试人员可以在其中发挥出更关键的作用。
读后很有启发，深入思考后，草就此文，与诸君共飨~
认知一致性陷阱
认知一致性陷阱是指个体在持有某种立场或认知后，倾向于选择性地接受与之一致的信息，而忽视或忽略不一致的信息，从而形成自我强化的认知闭环，导致难以客观评估现实。
上世纪50年代，费斯汀格与卡尔史密斯、所罗门阿希等心理学家，做过很多相关实验，证实了认知一致性偏差的广泛存在
- 试验者在执行枯燥任务时，低报酬者比高报酬者更倾向于改变原先评价，以合理化行为与结果的矛盾。
- 另一个实验中，大部分试验者会因为其他人的错误答案，而改变原先自己的正确选择。
- 试验者在不同标价的同种食材食品中，会倾向认为标价更高的食品更为美味
以上试验，其实简而言之，就是我们说的 “从众心态”
认知一致性导致的质量风险
企业中，因为以上“从众心态”，顺从主要意见而导致的质量问题并不鲜见。
- 一个冒烟都无法通过的开发版本匆匆提交测试，只是因为开发人员“觉得”没问题了
- 领导拍脑袋想出的一个功能，匆匆上马，因为不符合用户实际需求，成为摆设甚至必须回退
- 缺少对用户群体的调查和真实使用场景的分析，新功能完全无法使用
上面这些问题，真的没人在发生前觉得可能有问题吗？只是因为大多数人没有意见或者到了流程节点，默认就推行下去了。
之前看到一个初创公司CEO的观点：软件测试人员在成本效益方面"弊大于利"。如果招聘的都是具有质量意识的优秀开发人员，就不需要专门的质量角色。
但事实确实如此吗？ 我此前的文章中，曾经讨论过“开发思维” 和 “测试思维” 的不同：
- 开发人员更倾向追求确定性。基于确定性的需求，步骤，定义产品的表现。
- 测试人员则需要基于不确定性来考虑各种可能路径和分支场景，基于未知来评估产品的可能表现。
而且，在一个基于绩效驱动的组织中，开发人员被雇佣来是为了交付成果，而不是质疑。评估他们的标准是他们的构建能力，而不是他们发现和应对问题的能力。
再基于 认知一致性陷阱，在一个强调产出的组织中，质疑的声音会被不断弱化，所以具有优秀质量意识的开发人员，在这样的环境下，也很难做到质量优先。
测试，岗位赋予的“异见者”
很多“从众心态”的人员，其实能意识到问题不对，只是缺少提出“异见”的勇气，但一旦有指出问题的挑战者出现，便也能积极提出意见。
而测试这个岗位，则从职能设定上就是被赋予且被期望去提出质疑和挑战。
这也正是测试这个岗位存在且重要的必要性所在：降低他人的异议门槛，为团队创造批判性思维空间。
而作为测试人员，也不要囿于研发生命周期的限制，积极测试左移，更多参与前期环节，才更能体现角色的价值。
当然，认知到这点，也要接受成为“带来坏消息的人”这个定位。坦然面对，团队走向成功，离不开这样的角色。
结语
喜欢看古装历史剧的同学，应该都熟悉，在历朝历代，都有“御史”这样的官职，作为谏议言官，虽然多半不受皇帝大臣待见，但体系的运转，却不能缺少这个监察审议的存在。
而测试人，也正颇似软件研发这个体系中的“御史”。
不要担心测试报告上的“不通过”，那就是测试这个职能存在的意义。
