做程序员喜欢的测试人员

lsekfe

程序员与测试在工作流中是上下游的关系，而且工作上联系紧密，沟通上难免出现各种各样的问题。笔者作为管理软件行业的一个程序员，也算是和测试人员打过多年交道。希望能从程序员的角度出发，为测试人员提一点建议。 首先，我们一起来看一下程序员们最不愿意从测试人员口中听到哪些话？ 1、XX，又发现了一个严重BUG！ （尼玛，文案错误也要算C级BUG吗？尼玛，1号BUG和2号BUG是同一个问题，你提两遍C级？要不要哥把你提的BUG在JIRA里都置成Not a BUG） 2、我提的BUG怎么不清楚了？上次提的问题到现在都没有改！ （尼玛，你提的BUG里面，截图有木有？操作环境有木有？好容易写点文字描述又不加标点！有木有！我只能按我自己的理解改喽！） 3、XX，你到我这来看一下，我这测出个问题！XX，过来，又有问题。。XX，又有问题。 （泪。。能不能让哥安安静静写2个小时的程序，程序员很忌讳碎片化的时间，思路都木有了啊。。又要重新想啊。。） 开发和测试是项目进程中至关重要的两个环节，程序员与测试人员若能相亲相爱，一定是PM们最愿意见到的事情。然而不同角色的人员在共同完成项目的过程中，实现天衣无缝的合作总是很有挑战的事情。诚然，这些挑战可能是由于参与人员的能力问题，这无可避免。但我更愿意相信，沟通不畅、习惯不佳、缺乏换位思考等因素才是最常见的。测试人员在实际的工作中如果能够注意以下内容，相信一定会成为程序员喜欢的测试。 1、份内之事做到专业 提交BUG要描述清楚。注明操作步骤、测试环境、描述清楚正常现象和BUG现象的差异。 BUG级别设定不要全凭主观看法，应该和产品、开发人员沟通后，确定一套评价标准，客观评估。 尽量避免提出重复BUG，两个不同页面的相同问题应归为一个BUG的两次出现。更深层面的相同BUG原因，可以多和工程师沟通了解。 2、沟通之中互相理解 最终程序员的工作方式，不要一发现问题就找程序员，编码过程中思路被打断对程序员来说是很痛苦的事情。可以收集多个问题后统一找程序员处理，或是在即时通讯工具上留言，看程序员的时间安排，给他几分钟时间缓冲，在其方便的时候沟通。 测试最怕“Not a BUG”，程序员怕的是“C级BUG”和“重开”。设C级和置重开时慎重一些，不确定的可以先和程序员沟通过再提。 3、功夫在诗外 熟悉业务、了解客户，对于测试人员来说也是非常重要的。测试人员不要机械的去验证功能和需求文档的差异。对业务和客户的了解能够帮助你更好的设计用例、定位问题。 多和程序员沟通，了解开发思路。了解开发思路能够帮助测试人员找到测试步骤的盲点，更容易测出真正的问题。这样的沟通，也会帮助开发人员检验开发思路的正确性，更好的提高项目团队的效率。 如果项目团队里有一个这样的测试人员，任何一个离开项目的程序员都会怀念他的。 当然，程序员们也不能被惯坏了，一味的要求别人如何配合自己。在项目中换位思考，互相理解也同样是程序员应该注意的事情。做相亲相爱的一家人，才能携手并肩，一起向前！ 文章出自：http://www.uml.org.cn/Test/201109145.asp

kexinqw11

看了你的这篇文章，我理解你所说的，但是做一个测试人员，文章中的有些观点还是有点不敢苟同：
对于问题1.XX，又发现了一个严重BUG！   一个BUG导致系统两处出问题，在使用者的角度去看这两处使用都有问题那么就是两个问题，提两个BUG无可厚非，人家用户才不管你是不是一个原因引起的.要怪就怪你当初不应该产生这个BUG。
对于问题2、我提的BUG怎么不清楚了？上次提的问题到现在都没有改！   缺陷描述不清晰确实是有些测试人员做的不对，但是开发人员在修改缺陷的时候，是否也应该和测试人员确认下不清楚的地方呢？不能说测试人员做不到位，你开发人员也做不到位。若如这样，那就半斤八两。
对于问题3、XX，你到我这来看一下，我这测出个问题！XX，过来，又有问题。。XX，又有问题。  别说程序员了，任何人在工作的时候都不愿被打扰，这个时候就需要沟通，两者都协商好，都可以相互理解的。
对于你说的测试人员不要机械的去验证功能和需求文档的差异。对业务和客户的了解能够帮助你更好的设计用例、定位问题。  若真按照你这样所说，那需要需求文档何用？ 程序员不根据需求文档，只按照自己的想法设计程序，理所当然地认为这就是用户的需求，这样可行吗？ 测试人员和开发人员再怎么熟悉需求都没有业务人员来的专业。当真的出现程序设计和需求文档不一致，那就要找业务人员商量，确认真是需求有问题，还是程序设计有问题。