测试日常杂谈（2）

最近在做项目的过程中有一些思考，目前手上有两个项目。项目A处于测试阶段，项目B处于需求阶段。

处于测试阶段的项目A，在过程中发现较多的问题需要各个角色的人修改原本的方案或者增加新的设计，姑且不谈为什么会出现这些问题，单从出现了这些问题以后我有哪些思考。

      之前组织的提测前冒烟测试由开发主导，来向大家展示自己代码实现的效果，也可以看作是开发同学的一项成果展示。这次在负责项目A的测试过程中，我决定在项目上预发布环境之前组织大家来一次验收测试。全员参与由测试主导向大家演示整个项目的实现效果。这么做有以下几个目的：

1、考虑到这个项目周期有点长，想跟大家一起再回归一下整个流程的各个功能
2、希望能在过程中发现一些体验上不合理的问题，提出改进的建议。
3、全员参与的情况下如果对现在已实现的业务功能有不满意的地方，可能后续修改起来也不会有心理排斥。

最重要的一点是：项目是大家一起完成的，最终能在上线前先能得到大家自己的一致评价是挺重要的。也让我们能感受到自己做的东西是得到内部认可的，即使有不满意的地方也能及时提出来并改正。希望能在有限的时间内呈现尽可能完整且高质量的产品给用户。

处于需求阶段的项目B，在前期经过一次需求沟通后，大家一致认为目前的设计是满足了一部分需求，但是属于治标不治本的，没有从根本上把问题解决。

      大家经过一番讨论后最终还是决定满足产品的设计方案，实现其功能。过程中能看出来大家是有想法的，但是最终还是选择了用相对成本较低的方式先实现功能。会后我单独跟产品沟通后发现，实际上他们也是明白当前的方案是治标不治本的方案，但是考虑到种种原因，考虑开发实现成本，考虑运营操作成本等方面，没敢大刀阔斧的去改动。我也很能理解他们，不过我还是鼓励产品同学优先考虑的是用户而不是我们内部的问题。因为最终我们是要服务于用户，而内部的研发是辅助更好的在技术上去实现它，有时候产品的设计方案可以刺激到研发人员的创新，所以在需求前期还是尽可能的考虑比较完美的方案。当你的目标是天空时，势必有把握飞过树梢。其实从个人的工作经验层面考虑，你做什么项目并不是最重要的，重要的是你采取了什么样的手段去做成了这个项目。

以上就是本周对工作方面的一些思考。值得欣慰的是，项目A经过跟项目经理的沟通，增加全员验收测试这个环节很有必要以后会流程化。项目B经过跟产品经理的沟通以及对她的鼓励，最终决定重新设计从根本上解决当前的问题。