刚入行在一家创业公司做产品助理，兼任测试工作。因为不懂技术，就做一些黑盒测试。当时就是测功能，正常异常流程都走个遍。有些时候还不知道是不是bug，比如在按钮/文字链上鼠标hover的时候，鼠标指针应该呈手形而不是箭头形。直到领导说了，才明白。哦，这也是bug呀。在CEO提bug给我，让我跟进跟开发。我跟开发一提这个Bug，对方就不愿意改，说这没事，来回几次。最后我说这是CEO提的必须改，这才解决。总之，测的不规范不系统
后来到现在公司了，招了一名测试，这才与测试人员打交道，知道是怎么回事。这4年下来，有8-9个测试合作过了。记录下来一些协作沟通技巧，供参考。
分三部分说，第一是产品小循环各环节沟通协作（需求->设计->开发->测试->上线）；第二是我犯的错及反思；第三是我看到其他部门的一些做法
第一产品小循环中与测试沟通
需求环节，在需求评审后，与测试沟通排期。开发中途-提测环节，测试人员会写测试用例，开测试用例评审会（一般是大中型项目）。用例用思维导图方式呈现，很直观。
测试会逐个模块逻辑的讲解，并且把关键流程标示出来，关键流程必须走通才能提测，否则无法进行正常测试。其次研发、产品提出实际开发与需求评审会上有变更的地方，测试做出对应的修改及测试注意事项。
前端后端研发联调完，自测没问题，然后发提测邮件给测试抄送产品，并在邮件中注明提测功能、分支、沙箱/测试环境、负责的RD/QA。此时，测试接入，正式开始测试。
测试步骤是先测完一遍主流程，看有无阻塞性问题，有则打回修改重新提测。没有则继续细节异常逻辑的测试。bug都提在JIRA/iwork上，测完大体流程，产品组会拉测试研发一起过一遍主要问题，圈出重点问题list然后预估让研发预估一个时间，边改边测。大型项目还会有封闭开发，产品研发测试都在一个项目专用会议室，这样的话，就把关键问题写在会议室白板上，改完一个划掉一个，很高效。
测试期间，每天早上或晚上下班前（站会制度），产品研发测试都集中开个小会，过一遍当天问题解决情况。圈出第2天的重点。重点是随着产品bug的解决程度变化的，遵循主流程阻塞>数据泄露安全>异常功能>提示缺失异常>ui样式文案，解决了第一级的，后面的变成第一级。
bug并不是非得解决完才能上线，在约定的时间上线，线上跑就行，后面再划分版本修改。不然就会陷入一个怪圈，一直提bug一直修改，没完没了，大家的士气也很低落，要避免。
如果是新功能，那么有时候还要看一些产品的关联的功能是否会受到影响，再测试，确保新功能没问题，也不影响老功能。这点尤其重点，尤其在企业服务产品和大用户量C端产品。
功能测试：有些测试功能，测试一个人无法自己完成，需要开发配合，比如制造服务器异常、支付等情况。压力测试：大用户量的产品做压测，一般是研发或者运维配合才能做，测试写脚本跑。一般是接口压测。安全测试：集团有信息安全部，他们会做专门的安全测试。产品在安全平台提交工单，并把测试账号提供给对方即可测试，然后返回测试报告进行修改。兼容性测试：移动端/H5也需要产品经理协助找一些手机型号做兼容性测试，公司有测试机往往因机器更新慢，需要借用新机器。浏览器也会根据产品需求做兼容性测试。
测试完成没问题，上线前产品经理在新项目重点功能也会跟着测试一遍。上线后测试和产品一定会再测试一遍（俗称回归测试），新功能有关联的也测一遍。有时候即使新功能无关联，我们也会再测一遍产品主流程和其它关键功能，确保万无一失
第二我犯的错及反思
过多干预测试沟通。我过多的干预询问测试，导致测试与研发之间沟通都跟我说问题，然后我来回沟通。这样我做的很累，他们之前缺乏必要的沟通。后来我就反思，然后开会把这个事情说出来，让大家纠正。
对人太好，让其感觉是应该的。对于一些兼容性测试，有时为了快速上线，会一起和测试测各种机型，这样一来就让人感觉这是必须的，费力不讨好。后来我反思，不能这样干了，应该把这个问题向上汇报，这原因有2个，一是排期与上线时间短，二是测试人手不够。排期上线时间一般向领导说明可争取一点。测试人手不够就向测试领导和自己领导反馈，争取测试资源，这样一来专业的人干专业的事。当然，有时候，测试人手确实不够，产品可以补位，但是不能长此以往。
第三我看到其他部门的一些做法
产品上线后有bug，第一时间谁来跟进？其他团队我看到一半是测试第一时间跟进，这样测试的精力在这上面，节省产品的时间精力。我们团队是产品第一时间接触，这样好处是产品能第一时间知道，因为这可能不是bug，可能是产品需求/产品设计问题。坏处是产品的精力难以兼顾。各有所长吧。
---