背景
在日常的工作中，我们会频繁的应对各种各样的需求和任务，尤其在整体的一个产品周期内，流水线上的各个环节：从需求到开发再到测试直至最后的交付，整个过程中，各方的合作和交流也日益的频繁，于是多出来了很多可能看似不必要的沟通过程。比如需求评审阶段，最开始可能对需求一头雾水之时，就被拉去做评审，然后仅仅是听开发和产品的二人转等等，这些都是我们很可能经历过，或者正在经历的真实情况。
现状分析
其实之后分析下，原因很简单，就是整体的测试没有提前的一个充分的预知，或者有了预知也没有一个充分的准备，这是一个比较现实的现状。究其根本，还是人员的配比问题，试想，如果比例均为1:1:1，是不是根本不会存在这样的问题，也就完美的避开了整个痛点。但是现实并非如此，国内几乎所有的公司，测试人员都保持着一个较低的配比，从1:3到1:10不等，而且绝大部分可能是1:5-1:8之间，这就注定了对测试本身是一个比较大的考验和挑战。
思考和破局
而针对测试者本身，面对这种情况 ，我们绝大多数人可能会疲于应对各种各样的需求，因为大家都是这样，整体改变局面还是很困难的，所以只能去更多的堆积时间来缓解这样的情况，开始可能会有一定的效果，随着项目的逐渐深入，可能就会越来越累，陷入恶性的循环。于是基于这样的现状，便催生出来一部分自动化的需求，自动化的测试便被抬到了越来越高的位置。不可否认，自动化在一些有确定性结果的需求测试上面，确实取得了一些比较显著的效果，以及一些重复性的操作上面，节省了一些人力空间，可以做更多的其他任务的支持。
这些可能也是绝大部分公司的一个解决途径，这确实不失为一个出路，从某种意义上而言，这部分的改变也体现了测试的一部分的价值，提高了工作效率，比之前可以做更多的事，无论对自身还是对公司层面，都是一种促进的积极作用。
但是与此同时，我们之前所说的这些，都是在我们站在整个流水线中来看待和工作的，我们只是在整个过程中，去建立自己的想法和观念，这样我们所能改变的，也仅仅是我们自身所影响的一小部分，这其实是非常有限的，或许，我们可以去做更多的尝试，去进行更进一步的思考。
欢迎关注一起沟通交流～
