PM自己做QA是种怎样的体验
前两天看到纯银大大说他亲自做QA，正好现在的实习也是自己在做测试方面（非自动化）的工作，所以当回标题党，顺便找个机会夸夸自己。
目前关于QA我看过最好的文章是从QA到EP，是一位豌豆荚的前辈写得，里面提到的一本书How Google Test Software也非常经典，值得研读。主要观点就是QA摆脱纯测试的定位，逐渐成为开发技术团队的支持者，提供各类高效的工具，这可能会对QA和测试岗的同学提供努力和前进的方向。
当然我不是做工具的，是来提需求的，所以其实不是真正的QA，而仅仅只是人工手动测试，主要就是功能和异常测试。（最近在考虑要不要来点自动化测试，不过暂时还没有结论）
这种测试首先需要对需求和PRD有比较全面的了解，然后编写测试用例，这种测试用例主要是给自己提醒和记录，避免遗漏某些功能和异常，其他职能的人估计很少会看。最后也是最简单的，就是根据测试用例进行测试，发现bug和未被处理的异常。
PRD是PM自己写的，自然很熟悉，那如何编写测试用例呢？
关于测试用例我看过的比较全的文章是测试用例大全，感兴趣的人可以看看。我编写时一般从这三个方面入手：页面可能存在的输入、页面可能存在的输出、页面中各组件或内容状态的变化，以及这三者中可能出现的异常。细节不多说，反正有输入的地方就有输出，有输入输出的地方就有异常，有异常的地方就可能有bug。
那么PM做QA或是测试有什么好处和坏处呢？
好处：
更熟悉产品，编写测试用例其实也是对自己设计的一种再熟悉，能够理清产品的每个模块以及各模块间的联系，是对PRD的一种延伸。
反思设计，在写测试用例时会发现容易出错的点并思考如何解决这些点，如果有更好的设计是否能够避免，同时从开发和设计角度出发，对需求有进一步的思考，例如紧迫性和真伪性等
更有耐心，由于测试的时候需要考虑到各类可能出现的情况，所以对每一种情况都要有相应的应对措施，这也就是为什么一个看上去很小的功能却可能有几十条测试用例，每个小用例也需要用心编写。
更流畅的沟通，一般在测试的过程中是会发现很多bug的，这时候PM就能对这种bug更清楚了解，对实际完成的效果和自己的预期认知更清晰，与其他岗位的沟通交流更有目标性。
学习新的领域知识，扩充自己的知识面。
坏处：
适宜功能和代码量不大的小项目，太大的项目效果不好。
PM工作量加大，可能需要加班
结论
测试或QA还是非常有用的，PM可以自己尝试写测试用例，从新的角度学习和理解产品
顺便为公司的产品打个广告：
品质好物，非礼莫属
官网：http://www.giftsfeeling.com
扫描二维码即可直接下载
非礼
