非直接产出部门，往往都会面临价值阐述的困境，质量部门是其中的一个典型代表；如果说开发部门可以简单粗暴的用人力和功能实现的比值作为自身价值的等值呈现，那么质量部门则很难这么做：功能顺利上线了，是代码写的本来就好，还是质量部门的功劳？测试技术能力的投入建设，真的降低了项目成本或开发效率，还是单纯的炫技和技术跟随？要保障质量的平稳，究竟投入多少人力才是最佳的成本控制？
当然，质量部门的价值所在并非不能说清楚，这些问题当然也有答案，但的确，和直接产出部门的产出价值阐述对比，无疑要费更多的周章。
当前的互联网，聚焦于某项测试技术的讨论，甚至整个质量体系的建设，这类文章有很多，但大多数都在说，我们做了什么，具体是怎么做的，但很少从顶层的视角，从质量的价值体现的视角，来说明我们怎么能得出质量建设路径。
本文将以作者个人的经验，以顶层视角，来做一次质量建设路径分析的泛谈，权作抛砖引玉。
所谓顶层视角，也就是更高层次建设者的视角，他不止是负责质量域的事情，还负责所有产品周期内的事情，甚至直接就是公司整体负责人的角色，具象来说，类似业务条线的测试总监，甚至 CTO、CEO 这样的角色；他们不关心（主要是没有精力）建设内容的具体技术细节，主要关注建设的投入成本和价值呈现，确保方向正确。
如果你的身份是基层执行者，那么你确无必要关注他们的视角，因为你的任务是一层层下派的，在最初的任务划分下，这块已经有人阐述好了并且得到了认同，你只负责具体目标的执行；而如果恰巧你正是最初的建设内容阐述者，你直接面向顶层角色阐述你的建设路径，那么你最好先把自己的视角和顶层视角进行统一，再进行对应的汇报，否则你会面对无穷无尽的质疑，你自以为充分的技术知识储备，如果不能直接转换为非测试域能理解的逻辑，会派不上一丝一毫用场。
如果说，创业最重要的事情，是把事情给风投人说清楚，争取到经营资金，那么在公司内其实也是一样的：如何把你规划的事情，给非领域内的顶层建设者说清楚，争取到公司内的资源倾斜，顺利执行，同样是最重要的事情；
从这个角度来说，如果你正是这样的身份，那么你一定要关注顶层视角。
对测试产出的指标，其实讨论已经有很多了，也提出了很多切实可行的执行方案，诸如：线上的漏测率、发版前的 bug 率、x 分之一的线上崩溃率等等，但对于顶层视角来说，仍然存在困惑之处；第一是，这些指标都太专业太细了，我列的仅仅是其中可能不到 10 分之一，更多的产线可能还有各自的详细指标，很难直接感受到当前的质量情况；第二是，指标不好和测试的活动直接关联起来，看不到测试活动在其中的对应价值；
如果拆开了往深里讲，我自信很多小伙伴都可以说清楚，但所需要的证明数据、所需准备的逻辑链条，又是费时费力，往往不一定给你详细拆开讲的机会；基于 “质量是要保障的” 这个大前提共识，很多时候方案也都可以直接过掉，但对顶层建设者来说，真的理解透了测试活动的价值吗？其实并不好说。
综上，向顶层角色阐述质量的目标，不合宜用专业的测试领域指标，它可以作为后面详细的解释，但是如果用指标直接代替目标，很容易产生认知门槛。
我们可以通过最简单的逻辑假设，来尝试推演一个顶层视角下可以理解的质量岗位的目标。
首先，商品的利润 = 商品的价格 - 成本（当然这是一个最简单的模型，实际上还要考虑盈利方式和边际成本效应等），在 it 的产品里，研测同样属于成本部分（但研发这边稍有不同，这里暂且不提）；
因此，一个极简的质量岗位的目标诞生了，质量岗位的终极目标：0 测试人力，保持输出产品的质量在标准线之上。
这个目标，足够直白易于理解，且一定正确，但很明显当下不可能达到，没关系，我们基于这个目标，继续往下推演。
“0 测试人力，保持输出产品的质量在标准线之上”，要达到这个目标，需要两个条件:
由此，我们可以得出，要实现目标，测试能力建设的方向：
测试能力的建设是为了保障产品不同层面的质量标准，基于质量岗位的终极目标，所有测试能力建设的最终方向，都一定是无人值守的（泛）自动化测试能力
进一步细化来说，基于终极目标，质量的建设方向：
至此，质量岗位的最终目标和建设方向都已经明确，并且逻辑链条足够简单；当前当然是不可能实现终极目标的，但基于目标的建设方向推演是正确的，后续所有的规划路径，都可以按照这个方向采取策略进行；质量岗位的价值，也可以直接和目标实现的进度进行挂上钩，质量岗位做的好不好，就看这两个质量的建设方向的完成情况。
那么还差最后一环，如何具体的根据目标和建设方向，进行质量建设的规划？可以从以下步骤进行落地实施：
一个参考问卷的字段行：
质量标准 能力保障方案 实现人力成本 若无:预计建设成本 是否无人值守 若不是:能否建设 执行/维护成本 是否可纳入统一能力实现
本文探讨了，为什么要关注顶层视角，并且给出了一种可能的，顶层视角下可以理解的质量建设路径；希望可以给读者一点启示。