从测试到产品经理

从测试到产品经理

说说测试，说的稍微夸张一些，测试是将产品给到客户的最后一道关卡，需要对产品质量负责，我们上司最喜欢的说的一句话是:“一切暴露给客户的问题都是大问题，一定要做好产品质量的把控”。所以测试需要高度严谨，决不能马虎行事，否则，既是对开发团队的不负责，又是对客户的不负责，好的习惯是形成记录（例如：某时某刻某人，测试的目标、期望、步骤），更进一步的还可以提出对某功能的改进想法，如果测试人员将自己当做用户去使用产品，就能提出各种各样的改进想法，如果对于某个功能，测试人员都觉得用的不爽，客户怎么可能爽。

由测试思维到产品设计思维

我分别以技术角度和用户角度（内部和外部）从两种维度上去测试产品，从技术角度上看（这里不讨论粗心导致的bug），当测试一个功能出现问题时，一般的操作是直接记录描述问题现象，更进一步的话可在个人能力范围寻找问题发生的可能性原因，思考开发人员为什么要这样设计，是考虑不周忽略了某种情况的发生，还是因为技术瓶颈无法解决该问题（一般会提前说明）。多半时间，只要你多想一点，就能使团队开发效率更高，产品做得更好，上面所述，当发现一个问题是因为开发人员忽略了某种情况发生和造成的，此时在测试记录中记录问题发生的现象的基础上再附上你对该问题的评价看法，开发人员会得到更多的信息量，测试人员将得到意想不到的惊喜，首先是开发人员会对其评价增高，二是培养了开发与测试之间的默契，三也是最重要的一点，对产品本身的积极效益。从客户角度上看，一个功能即使在技术上没有问题，也不代表在用户体验上没问题，当测试完一个功能并且评估结果是功能通过时，再往前想一步，这个功能符合体验吗？如果使用这个功能的时候感觉特别别扭，特别反人类，大胆提出或以备注的方式记录在测试文档中，在这个基础上还可以想一步，如果你是开发会怎样设计这个功能，如何提升用户体验感，可以把你的想法告知开发人员。当然大部分情况下，因为测试通常不具备开发能力，也就想不到算法、框架技术、程序语言的方方面面，也许测试出的问题开发早已预估到，已经是在考虑了技术本身局限之后的结果，如果遇到这样的情况，测试人员一般是不具备提出看法的能力的，或者提出的看法只是证实了开发所想，此时更应该与开发讨论，听听他们的想法，用到了什么技术，为什么会造成功能有问题，如何改进等等。

如果测试人员足够优秀，可以由被动接受测试到主导测试。一般开发人员会更多关心其所开功能是否能用，是否达到需求目标，如果测试内容由开发定，那测试清单将变成判断题，即对该功能是否有问题勾选OK or NG(not good)。作为测试，应该将判断题做成问答题，答：该功能NG，现象是xxxxx,原因（可能）是xxxx，改进想法xxxx。测试人员可以从这个切入点去找产品设计的感觉，此时此刻，假定自己是产品经理，假定所有功能已经完成测试，并且对所有功能都有详尽的了解，以100分为满分为产品打个分，如果产品有功能上的缺陷，打个不及格分，直到修复缺陷；如果功能良好，但你觉得有可以提升的地方，打个70分，直到完成提升；如果产品已经做到内部评估的最高水准（至少技术团队认为的最高水准），拿给未参与设计的其他团队人员使用，把70分的产品提升到100分。主导测试，围绕功能的效果进行测试，对整个产品负责，要想到，经过测试后，下一个使用该功能的可能就是客户。

当测试人员按照上述所说去思考后，其行为特征将慢慢偏向产品经理，从单个功能想到由若干功能组成的模块，从模块想到模块与模块之间的联系、兼容性，从所有模块想到整个产品，再从产品回到单个功能时，将产生全新的看法。围绕一个核心，即打造更加完美、出色的产品，测试人员的本职工作是对产品功能的好坏进行评估，测试是整个团队中最清楚产品缺点的人，也正是因为知道了产品的缺点，才有了设计更完善产品的目标，虽然绝大多数时候，测试人员只是上报测试结果，由产品经理进行功能评估，但信息传递难免失真，因测试人员汇报不当，表述有误或有所遗留，都会造成产品经理对产品评估失准；这也给了测试人员展现自我的机会，在上报测试结果的时候对某些关键部分有所保留或有自己的看法，在开会的时候表露出来。当测试人员发现了问题，不仅仅只是记录到测试文档中，找机会向开发或上司学习如何解决问题（这些机会可以是与同事茶余饭后聊起或技术讨论会议等），当然这里不需要你掌握解决技术，而是学习解决思路，学方案。

总结

如果测试人员希望向产品经理靠近，突破口在于成为全公司最清楚产品缺陷的人，试着去思考如何解决产品缺陷，顺着这个思路去探索，将有意想不到的收获。

当然，想成为产品经理，还有非常多的技能需要解锁，关注我，我将在接下来的章节中娓娓道来。