前两天看到纯银大大说他亲自做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可以自己尝试写测试用例，从新的角度学习和理解产品