软件测试只有走技术路线才有出路吗？
纯业务测试，是有出路的，说没出路的大概是没见过纯业务能够达到什么样的高度吧。就坐在隔壁同事的经历，现在已经当上业务架构师了，天天和客户开会，和开发大佬开会讨论需求设计。由于公司产品是toB端的，业务极其复杂，不同的客户对业务的需求不一样，甚至不同的客户对某个特定的业务需求点会有决然相反的要求。绝大部分开发，甚至开发主管，都不敢说对整个产品的业务全局非常了解，在设计功能的时候往往会无意识的看问题相对片面，反而测试团队，有个做的很久的对业务是无比纯熟，久而久之，开发在设计功能的时候也习惯去问这几个业务大佬的意见。虽然人家不会开发，不会码代码，但是对基本的设计开发模式还是有所了解的，加上又对业务熟，测试又干了很久，对哪个模块以前出现过什么样的问题，踩过哪些坑都非常了解，于是公司就直接设立了这样一个业务架构师的职位，直接按在他头上，和大客户的对接，了解客户反馈，澄清现有功能设计，现在公司内部的业务设计都是他负责，他还负责和部分售前部门对接，为每次开发的新功能做ppt做介绍。这些事情以前都是摊牌给每个开发团队自己做，做出来质量参差不齐，效果也不是很好，现在有一个专人负责这方面的事情，开发团队也轻松了。能做到这样一个职位，基本上公司不倒。产品不倒，也就不会失业，这个职位做的越久，公司内部就越没有人能够超越他。哪怕万一公司倒了，也有机会跳槽去友商。其实，不管是做业务测试，或者是开发测试，只要你的能力能够对公司产生价值，公司就愿意为你付费 ，当然以上这些都是有前提的，你所在的行业足够大，公司的产品也有足够的市场竞争力，值得在业务上深耕才行。否则就一个小产品，业务简单又没几个客户的话，业务搞得再熟也没人理你呀。其实我也很难理解现在的观点，就是评价一个测试好不好，先决条件是会不会代码。测试干的好不好，跟会不会代码一毛钱关系都没有评价一个测试能力唯一标准，就是看验证过的功能还有没有问题。我见过那种会编程的测试人员，过手的功能一塌糊涂，明显的问题发现不了，异常的情况很少考虑，更多的时候是跟开发一起怼产品，说产品的设计不合理我也见过一点代码都不会的测试人员，为了验证一个偶现的问题，在运维那里查看日志，将抓包的请求发给开发，尽力沟通希望开发给一点思路提示，不停的期望重现定位。这两种测试到底哪种能力强？代码确实给测试的很多工作带来便捷，这个毋庸置疑。但是代码并非测试的唯一衡量标准吧。我用postman测试接口，需要会代码吗？我用fiddler抓包分析请求数据，需要会代码吗？我用jmeter做下压测，需要会代码吗？
业务测试并非没有出路，测开不是测试唯一发展的目标。业务测试最重要的是提出检查点，善于使用各种工具，就算工具满足不了你，有一个团队在你后面支持，只要你提出测试方式，具体的方法让开发给你编写脚本又有何不可？
页:
[1]
