我们所面对的，是一个所有人都心知肚明的问题，我们眼前的软件存在诸多BUG，这是一个科学的且合理的假设，也是测试价值存在的前提之一，那么我们从哪里入手？
以我有限的编程经验来看，测试首要关注的是合理的操作能否实现，即，在大多数情况下的大多数用户的使用场景不会出现问题。至于那些非法的，或是极端条件下的情况，我们相对的把这部分工作向后放一放，因为，这些关系到程序的健壮性，而前者关系到程序的可使用性，开发人员更为关心前者，因为这方面的问题直接对自己的能力构成了挑战，相应的，当测试人员在这方面发现BUG时，开发人员心理会产生或多或少的感激之情，天呐，幸好他发现了这个问题，要不然将来可就麻烦了。
我善意的猜测，这样的工作方向有助于测试人员同开发人员之间建立起良好的合作关系，当测试人员在工作中解决掉了开发人员的后顾之忧，他们也会乐于接受你提出的其他问题，比如，这个按钮其实可以再向左放一放。若没有这样的前提，开发人员内心难免抱怨，有那么多问题你不去测，偏偏关心这个不起眼的按钮。
心理上，开发人员对自己的程序很少敢打保票，即便他自己已经调试了很久，因为作为纯粹的思想产物，程序能够隐藏的BUG数量以及BUG的隐藏深度往往超出人们的想象。开发人员希望测试人员同自己一样关心那些根本性的问题，即程序能否正确运行，当然，这种想法是否正确有待讨论。就好比人要先解决温饱然后再考虑个人形象一样，开发人员期望测试工作能够在这个问题上做出可靠性高的结论，这个结论不必以BUG数量作为依据，权威来自每一次工作的完成，当我们考虑高效一词时，是否可以将思路从单位时间上的产能转移一下呢？
测试人员需要自己的权威，我相信，这权威一定不全部来自BUG数量，很大一部分是来自BUG质量。
你发现越多的开发人员担心的BUG，你的权威性就越高，就越能获得开发人员的信任，和尊重。所以，请尝试着寻找开发人员担心的BUG，寻找那些让开发人员忧心忡忡的BUG，这样做似乎违背以用户为中心的原则，可难道开发人员不是在以客户为中心么？
是否存在这样一种心理，认为测试人员比开发人员更为关注软件质量？
如今转入开发的我回顾自己的测试经历时不经倒吸一口凉气，因为那时，我就是这么想的，我天真的认为开发人员没有测试人员更关心质量，仅仅是因为他们从不编写详细的文档，仅仅是因为他们对我提出的BUG常常漠不关心，当角色发生转变时，从内心深处，我寻求测试人员的帮助，期望他们对我的程序测试出更多的BUG，这样，当用户真正使用时才不会发生问题，至少我负责的那部分不发生问题。
为什么测试与开发之间有着种种说不明的矛盾和纠纷呢，我想，这和测试人员认为开发人员不如自己关心质量有关系，这和开发人员认为测试人员没有和自己关注同一个质量层次有关系，即，开发人员认为测试人员没有把重点放在应该放的地方，仅仅因为他们关心了自己没有关心的方面，譬如一个按钮的颜色或是其他的确实是问题但不是开发人员最关心的问题的问题，所以你看，开发人员同样关心质量，他们同样不希望软件出问题。
我之所谓更高效的测试，不是从产能方面考虑，而是从工作效果上考虑。
即，一种更有效获得开发认可进而更高效合作的方法，一种更可能获得开发人员尊重与理解的工作方法，最客观的评价往往不是来自朋友，而是你的敌人，测试的敌人就是开发。
我必须强一点，我绝不认为测试要受制于开发，或听从于开发，测试的独立性与我所谈到的去关心开发人员关心的BUG并不矛盾，独立性强调的是管理权的所属以及行动自由的程度，但就工作内容而言，开发与测试不能由此而割裂。
工作方向上的对立不应导致工作关系上的对立，去做开发人员没有做到的事情，去寻找那些让他们担忧的可能存在的BUG，用一份测试报告表明这些BUG已经被发现或是不存在，至于那些关乎到质量但又不那么迫切的需要给予关注的BUG，我劝各位一句，那些真的不重要，至少没有想象中的重要，不要为了证明自己工作的价值而强调它的重要性，项目经理和开发人员真的不买这账，能证明这些BUG重要的是市场，而非测试人员，而非测试理论，所以，放弃那些权威产出率低的BUG，将重点放在那些权威产出率高的问题上来，这些才是体现效率的地方。
当最关心的问题被解决以后，当你获得了权威与信任，一些问题自然会迎刃而解，这包括上一段所提及的不那么重要的BUG，当你获得权威，你的任何言论都具有权威。
