这段时间虽然很少做测试工作，可是无论是准备测试外包推广资料，还是听外国客户分析需求，或者是对其他项目组进行的规范检查，感触都颇多。大概由于自己是一名测试人员，所以也更多的以测试角度去思考这些事情。特别是在检查youtalk项目组后，再结合以前检查Open Activity的情况，我更深刻地意识到提高测试力量不应该只是测试部门要做的事情，而应该是一个“全民意识”。

在这里，我将自己在测试工作中或者是在规范检查中遇到的几种比较典型的现象列举下来，如果我的认识有偏差，希望大家批评指正；当然更希望大家能够讨论，给出解决建议。另外，也有一些是包括我在内的部分测试人员都比较头疼却还没有解决方案的问题，也希望能得到大家的帮助。

1. 测试依赖客户

这是我在规范检查中发现的问题，这通常发生在没有安排专门测试人员的项目组中。至于后果，大家应该都清楚，那是长期这样，将会大大降低客户对我们的信任度，并且这对于我们的质量提高也是毫无好处的。

解决这个问题，得从思想上增强质量意识，而对象，则应是公司的每一个人。

2. 这是谁提交的bug

测试人员几乎都遇到过这样的情况，“这是谁提交的bug，客户提出的吗？需求上明确说明了吗？”如果后两个问题都给出的是否定的回答，那么，很可能这个bug会被降低优先级甚至是拒绝修改。

当然这得从两个方面来考虑改进，对于测试人员而言，得提高自己的测试技术，提高bug的质量；另一方面，大家都得意识到，提高质量是我们共同的目标。

3. 侥幸心理

虽然在以前的规范检查中，也曾意识到这个问题，而真正思考它，则是本次SPP客户反溃回来的bug引起的。这次的bug有几个改动比较大，特别是在产品已基本成型的后期，则要付出更大的代价。然而，那些bug本来在之前已发现，可是一种“反正不影响使用，客户不提出来不用改了”的侥幸心理搁置到了现在。

该如何平衡质量与代价？

4. 测试从何下手

检查过两个不含测试人员的项目组，关于测试方面，都抱怨着同一个问题：测试技术缺乏，测试力度不够，有时甚至不知从何着手。

我想能意识到这一点是很好的，但要解决这个问题，一方面希望测试部门能制定相应的测试规范，同时随时将经验总结并共享；另一方面，如果能组织一些测试人员与开发人员之间的沟通交流及学习培训活动，相信能够有所帮助。

5. 没有领头羊

测试部门正处于发展建设中，我想我们可以更多地从这方面进行考虑，希望部门内每个测试人员都有自己的特点和长处，譬如某项目需要进行性能测试时，希望能够立即找到可以请教及协助的测试人员，而不是抓瞎。

6. 忽视bug分析

以前总以为bug分析是测试流程的一部分，理应测试人员来完成。可是在完成本次规范检查后，我意识到，bug分析对于测试人员重要，对于开发人员或者是兼任测试的开发人员更为重要。毕竟，我们的终目的不是发现bug，而是杜绝bug的产生。

似乎想得挺多，真正写出来却也没有几点。只是希望通过大家的讨论，能提高所有人的质量意识，并给出一些建议，特别是对于测试力量薄弱的项目组。