和开发沟通bug之常见遇到回复

和开发沟通bug之常见遇到回复

走心原创第19期

从一开始，测试就要关注需求。每每在讨论设计时，开发和需求很容易忽略了测试成员，他们潜意识里以为这不关测试什么事。但是，测试也要熟悉业务，熟悉功能，熟悉各类设计，并且测试须要站在用户的角度来去考量他们的设计是否有不合理的地方，并提出本身的建议。这些工做，测试成员须要主动，积极参加，多提建设性意见，这样可能会让开发慢慢发现测试成员的重要性。
其次，沟通最频繁应该仍是关于bug的讨论。下面列出几个遇到的沟通问题，及个人解决办法。
一、“这个bug我这边重现不了啊~~~”
解决办法：这种问题首先要自省，bug描述里面是否没有说清楚。Bug应该简明扼要，重点突出。若是描述存在歧义，必定要总结并尽快改进。有时会遇到几率性的bug，要告诉开发几率是多少，尽量多的提供重现的条件。
二、“这个不是代码问题，需求这么定义的”
解决办法：需求也是人定的，若是以为有异议，能够找需求人员询问清楚，为何这样定义，把本身的想法告诉他们，看他们怎么决定。若是被需求说服了固然是最好的，若是本身仍是不一样意需求的见解，需求又不一样意个人提议，那只能听他的，毕竟权力在他那里。可是咱们能够保留交流的记录，证实曾经在这里发生过歧义。
三、“这块是别人负责的，我负责的部分没有问题”
解决办法：若是bug是由开发的项目经理来分发到程序员，那就是项目经理来面对这样的问题，而不是测试。固然，项目经理固然有项目经理的处理办法。但是，测试遇到这样的问题怎么办呢，把负责相关内容的开发都邀请到一个讨论组里，让他们本身讨论，这样更清楚，没必要在测试这里中转。若是他们都以为代码没问题，而我也有强有力的截图和真相，那就只有上交给上级领导，让他们来决定怎么解决。
四、“有问题吗？”（也就是开发不认为这是个问题）
　　解决办法：测试人员必定比开发要敏感，对bug的容忍度也要低一些。特别是一些不符合用户习惯的bug，开发总以为无大碍。好比，一个列表默认的宽度过小了，致使初次打开，有一些内容被隐藏在后面，可是这个宽度能够手动调节。开发以为问题很小，不影响功能，并且也有解决办法，因此不认为是bug。这个时候，就要发挥测试的本事了，嘴甜一点，说说好话，态度柔和一些。由于既然是小问题，解决起来必定不难，耐心地催开发的改过来就好。催一次不行催两次，记住态度必定要好。
五、“用户不会像你这样操做的！”
　　解决办法：用户怎么操做，谁都预料不到。咱们不可能覆盖全部可能性，可是大多数用户会出现的操做，咱们固然要测试。慢慢地把开发从代码的世界里带出来，带到用户的世界里，让他换个角度思考问题，毕竟软件开发不是为了实现功能，是要知足用户需求的。若是最后仍是没能说服他，第一贯上级反映，第二作好沟通的记录，未来备份在测试报告里。
　　除了bug上的问题，还有测试安排上的问题，有时候小功能没有作好，或者某个文档、图片没有上传，等小功能作好了文档上传以后，极可能开发忘记告诉测试。因此，平时的工做中，必定要主动记录问题，主动沟通和督促，并反复确认，不要怕麻烦。
　　总结起来，测试在工做上要主动询问，态度上不能轻易妥协，习惯上要善于记录细节，方法上软硬兼施。

• End -
  做者：脑洞大大的吃货狮子座，喜欢专研技术，勤于总结概括,用文字结交朋友，擅长与生活相爱相杀，乐于分享的一个技术狂人。
  软 件 测 试 君
  听 说 看 了 这 个 号 可 以 干 掉 领 导· 猜你喜欢的文章 ·