问题往往出在“应符合标准”上。到底产品应当符合什么标准？
这个标准每个人都有自己的答案，可以是明确的需求文档，可以是行业标准，可以是监管规定，可以是最终用户的建议，也可以是测试工程师的直觉。
你以为我和别人一样，给你罗列出一大堆模糊的名词，你自己随意选？
问题的关键并不在于你有多少选择，而在于如何找到那个最适合的？
我推荐给你的原则是，客户导向，因势利导。
我用一个例子来说明：
我曾经作为产品经理，主导了一次接口的迁移。原本该功能使用A系统提供的接口，但是由于A系统已经不再维护，因此很多个性化需求无法使用，需要迁移到B系统的同类接口上。
我在需求评审后，参与了测试人员的用例评审。评审会上，测试人员挨个讲了一遍他的用例，然后问大家，有什么问题么？
我建议测试人员思考以下问题：
- 为什么要进行本次迁移？
- 本次迁移最终的效果是什么？
- 接口迁移这一类代码变更一般会带来哪些影响？
- 本次迁移涉及哪些系统，哪些用户，哪些业务？
- 这些系统的特点、用户的诉求、业务的特性各是什么？
- 在本次迁移过程中，第4条中涉及的主体会受到哪些影响？
- 哪些影响是对我们最重要的，不可接受的？
- 如何判断这些不可接受的影响都已经被我们搞定了？
这就是客户导向这条原则的一个具体应用。回答了这些问题，一个测试人员就会知道哪些是最重要的测试用例，应该作为本次测试的重点。测试人员可以找产品经理和开发经理一起讨论。
客户导向获得测试的范围和重点之后，编排计划时，应当“因势利导”。
最关心产品是否能上线的人一定是产品的负责人。这个角色有可能是产品经理，也有可能是部门经理。客户的需求，市场的形势，领导的期望，就是我们能够因的势。
我建议测试人员回答以下问题：
- 客户、领导和产品经理对产品质量的期望是什么？
- 现状与期望的差距有多少？
- 满足这个期望我们需要做哪些工作？
- 时间和人力够完成这些工作吗？
- 有哪些资源我可以借助？
用这些问题对大家的期望进行管理，哪怕真的是资源不足测试不充分，至少客服团队已经做好了迎接投诉潮的准备。
- 有哪些外部依赖？我有办法解决吗？
- 有哪些风险，我们都有应对方案吗？
- 上面这些依赖和风险，有谁能帮我们搞定？
用这些问题对风险进行管理，调动你的客户、你的领导、你的同僚，让他们帮助你。
我认为，经过这样的过程，加上你的专业能力，这个计划一定是最合适的。
本文源自公众号 <a id="js_name" style="margin: 0px; padding: 0px; color: rgb(87, 107, 149); -webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system-font, BlinkMacSystemFont, " helvetica="" neue",="" "pingfang="" sc",="" "hiragino="" sans="" gb",="" "microsoft="" yahei="" ui",="" yahei",="" arial,="" sans-serif;="" font-size:="" 15px;="" letter-spacing:="" 0.544px;"="">价值驱动软件测试