前两天我发了篇鼓励测试人员学编程（思维）的文章《做测试到底要不要学编程？》，有不少同学在后台问我，自己底子差，实在跟不上怎么办？
看起来，应该是我没说清楚，导致大家有点误会，测试人员用不用学编程？用，是不是必须学？这个可以视情况而定。
就算是 google 里面的 TE 角色，有些也是很少涉及编程的，所以不会编程，我们可以发挥自己其他方面的优势。
比如，业务专家。
业务是一切的根基，这点大家应该都明白。
产品是为公司目标服务的，业务是为产品服务的，技术是为业务服务的，所以懂业务应该是对技术人员的基本要求。
我在测试经验图谱里面的硬技能分支中，第一个列出来的就是业务逻辑，业务逻辑的重要性用言语简直不足以表达，所以也没有给他定要求，反正就是能搞多熟就把它搞多熟，能尽快把逻辑搞熟就尽量快，绝对有百利而无一害。
当然，要求归要求，理想很丰满，现实很骨感。
技术人员对于业务的问题，第一点主要集中在个人关注点上。
技术人员有自己的工作任务，比如测试人员，更多的是要求专注功能测试、性能测试、兼容性测试、自动化测试等等方面，都是很具体且很重要的事情，这部分事情占用我们的主要精力。
那么用来关注业务本身的时间就比较少，所以经常会出现各种各样的问题，比如：
- 我们提供了用户需要的功能，但是用户不买账；
- 每个用户有自己的要求并且相互冲突，我们没法满足所有人；
- 看起来需求是满足了用户表述的诉求，但是发布后发现用户并不买账；
- 发布前绞尽脑汁想到的所有场景，在发布后才发现我们还是高估了自己的想象力；
这时候，就算有出色的技术，业务目标也会无法达成，最终就是劳民伤财。
技术人员对于业务的问题，第二点主要集中在业务了解的全面性上。
有的人说了，第一个问题我们这没有，我们所有的需求都会过需求评审，确实是解决了用户原始的需求情况下，技术才上手，嗯，能做到这个程度真的很不错了。
但是，有人看到过某些产品逻辑内部打架的情况不？比如：
- A 逻辑写了一个注册表值，结果 B 逻辑给删掉了；
- A 界面用了红色主色调，结果 B 界面用的是绿色主色调；
- A 功能做了一个设置入口，B 功能也做了一个完全不一样的设置入口；
是滴，很多人缺少大局观，看问题只会着眼于具体的问题细节上，一不会扩展，二不会从整体上进行考虑，导致局部最优，而合在一起则是最差。
问题说完了，作为业务测试，我们的优势和努力的方向到底是什么呢？
我的答案依旧是，业务专家。
我理解的业务专家的技能特长包括如下几点：
1、能够快速融入项目，理清项目脉络；
2、能够把同一个产品中各个业务的关联关系熟悉清楚，并了解核心功能是什么；
3、能够从用户视角出发，提出用户体验和使用场景相关的需求问题；
4、能够清晰的明白业务的优先级划分，在投出产出比上做好平衡；
看起来是不是和测试没关系？No，测试即服务，测试是为了质量服务的，只要是能保证质量的事情，测试都可以去推进优化。
如果能达到上面业务专家的要求，那么就可以解决因为关注不够而造成的需求合理性和全面性考虑不周全的问题。
测试是同时离业务和用户都很近的角色，只有我们能把这个环节打通，也一定能发挥更大更重要的作用。
以上，你觉得的技术和业务孰轻孰重？你现在更偏重于技术？还是更偏重于业务？你觉得不懂技术的测试有发展前途么？欢迎留言告诉我你的想法。