先来聊聊测试与开发的关系吧，我个人的理解是测试是为了向用户证明软件是可工作的，向我们自己内部人员证明软件中还存在问题的，世界上不存在没有缺陷的软件，这应该能得到大家的认同吧，那么剩下的问题就是，软件中存在的这些缺陷我们是否可以接受，用户是否可以接受？

　　我们的软件如果在用户验收时获得了100%的通过，在那里他甚至无法挑出一点毛病来时，作为测试的我会有一种自豪感和满足感！作为开发的你呢？我相信也会有的，因为那是一种对自己能力和工作的肯定。到这里，至少我们知道了测试与开发的目的是一致的，那就是得到用户的肯定。我相信大部分的开发还是能够理解测试作为项目组共同的成员，所做的工作也是想让软件质量更好的(这一观念至关重要，开发在对待每一个提交的问题时如果都持有这种观点将大大减少与测试之间冲突的可能性)。那么我们来进一步聊一下测试提交的“没什么价值BUG”或“没有道理的问题”的话题。

　　首先，我们从时间和成本等方面考虑，对软件进行完全测试是不可能的，作为测试，一样是要区分出重点与非重点的工作内容，可这与我们追求完美的软件的理念是没有冲突的，当我们在测试作为重点测试内容时发现了一些非重点的问题时，我们会提交缺陷，此时，作为开发，没必要也不需要认为测试人员整天就在那捣鼓那些小问题，并且因为这件事而奋奋不平，如果你发现提交上来的都是些你认为不值得改的问题，那你更应该开心，因为可以从一个侧面反应以往认为重要的流程和功能都测试通过了。在这里，请相信测试也是项目组的成员，他们会重点测试那些重要的功能，出现一些小问题时，是因为他想让软件变得离他心目中的完美更接近，让用户的体验更好，如果开发认为这些问题修改起来影响太大或投入产出不成比例，经过讨论和决策后，测试肯定是会接受不做修改的决定的。(这一段中所说的问题是指开发也觉得是BUG，但觉得没什么价值的BUG)。

　　接着，我们探讨开发“不觉得是问题的问题”，经验表明，测试与开发在软件可用性上可能出现的分歧最大，原因在于做为每个独立的个人存在，他们都有着自己的认知和观点，你测试觉得这样改会更好只是你自己的看法，又不能代表用户这样想。此时，我们要再一次想到，测试是为让软件变得离他心目中的完美更接近，其实测试也是用户，他是内部的用户，他会提这样的问题，你能保证外部用户不会有类似的感受？其实他提出这个问题只是担心以后有外部用户以这个问题进行投诉而已。针对这样的问题，我们需要的是评估与讨论而已，请整理好说服测试的话来，用以在日后说服客户。

　　对于开发针对测试所提的某些质量较差的问题的反斥，测试需要好好反思一下自己提交问题的方式，问题描述的方式是否客观，沟通是否到位，同时要理解开发与测试在不同的角度以及不同的环境，看待问题的观点和心态会不大一样，测试要更加主动去改善与开发的关系，因为测试是沟通联系的发起方。

　　个人认为测试是向我们自己内部人员证明软件中还存在问题，我的观点是只要是缺陷，不管是大是小，是否需要修改，我们都必须提交记录下来，因为我们的对内的任务是让我们内部的人员知道有哪些缺陷存在，记录下来将为我们进一步分析软件和产品提供输入，有利于更好的展现出产品的质量以及后续产品的改进、规范的建立、团队的改进等～

　　最后，我想说，我们不怕在内部犯错，只要我们不再犯同样的错误，不让错误随着我们的产品带到客户手里，那我们就是在进步。