测试日常杂谈（1）

最近先后有两个做测试的朋友跟我吐槽了他们工作中的烦恼：项目的过程都是测试推动，心累，而且吃力不讨好。总结了下他们两吐槽的问题：

1、开发的技术文档有吗？可以给测试一份吗？

2、比如到了提测点了开发怎么还不提测？

3、终于要提测了，为什么提测质量这么差？

3、测试阶段居然要帮开发做联调测试

4、提了Bug怎么不修？是不是没看见我提的Bug？

5、修了怎么还有问题啊？是不是修复的代码没提交啊？

6、为什么开发总是找测试要数据，要账号，要页面地址？

7、测试用例总是执行不下去，开发到底有没有写代码？

8、为又什么偷偷改了东西不告诉我，我怎么知道要测这个？

那为什么会把测试的工作做成了像一个幼儿园阿姨一样操碎了心.但是却忘了身为测试最重要的工作呢？

以上的问题总结下来是有两个层面的问题：

第一，流程管理层面：每个项目都有清楚的里程碑，每个节点的时间能否把控好都是多个团队合作的结果，提测时间推迟这已经成为一个事实的情况下，测试的抱怨是没有用的，最主要的还是要考虑怎么避免这种情况经常发生。先了解原因是开发估时与能力不匹配还是开发过程中遇到了一些需求的变动，还是有其他外部原因等。在了解清楚后，针对这些原因看看我们能有哪些有效措施去改善它，比如是因为开发过程中有需求设计方案频繁变更，那就要针对这个原因做出相应的措施，例如在开发过程中我们也可以采取站会的形式同步当天的开发进度，测试人员也是有必要参加的，当天的问题一定要在当天有明确的结论和方案。诸如此类的方式针对每一个问题提出有效的管理措施并落实，对整个项目的质量改进也是有非常大的作用。

第二，测试思维层面：其实测试可以在思维方式上调整一下。永远不要把自己所需要的东西指望别人能送给你，这句话也适用于我们的工作中。首先，一定要定位清楚我们始终有一个最核心的原则就是为产品的质量负责。其次，本着这个原则我们需要做哪些事情，需要有哪些辅助（比如，需要完整的需求文档，需要技术文档，需要技术评审）这些事都需要其他团队的配合输出。最后，给出为什么我们需要这些文档的理由，了解技术方案是为了更好的设计用例，设计更好的用例也是为了能够帮助开发更好的完善代码，最终的目的也是为了产品能有更好的质量保障。这是一个闭环的思维，我们把自己的测试思维要覆盖到整个项目开发过程中，做每个环节的质量把控者，你永远是有主动权的，而不是被动的。