一些公司没有QA的情况下，测试的任务往往都是由产品来搞定的，但是这也可能会测试的不完整，看看作者的一些产品测试经验，可能会给你启发。
蝉小队做产品的就6个人，2只产品汪，3个工程师，1个UI设计师。没有QA。至今为止发了5款App，故障率很低，几乎没出现过需要紧急修复的重要bug。说说我们做测试的经验吧。
1、
一定要写测试用例。
一定要写测试用例。
一定要写测试用例。
测试用例我用Mindjet来写，把每一个需要测试的分支写出来，但不标注测试方法与预期结果——都在我脑子里呢，所以我写的用例几乎没人能看懂。你们也别找我伸手，我的测试用例和PRD是同一个东西，怎么可能给外人看。
每次写新产品的测试用例，大约需要两三个小时，花费时间不多，但极痛苦，必须是情绪相当稳定，并且拖到没法再拖的时候，才会逼着自己“静下心来”写这个。一边写一边呲牙咧嘴，自言自语“不是人干的活儿啊”。写完第二天再检查几遍。
2、
测试由我和另一只产品汪策策来做。平时我负责iOS，他负责Android，但测试的时候我们一起上，各测试一轮，对着事先准备好的测试用例撸一遍就好了，发现问题就记录在Tower上，指派给工程师。工程师勾掉，通知我们回归测试。大版本发布前还会全面回归一次。
Tower上的产品项目，按产品模块分成5-10个模块，需求与bug记录在各自归属的模块里，再标记“#版本号”，或者用“！”标记优先级，相当清晰。
通常我用iPhone6测试，iOS工程师用iPhone6 plus测试，策策用iPhone4(iOS7)测试。
Android的话，我司的测试机有Nexus5，三星S4，三星note2，米2，红米，华为低端机，魅族mx3。Android工程师用1台测，策策用2台测，我用1台测，尽量分开。
和大公司严谨的流程不一样，蝉小队测试期间的节奏相当快，每天都提若干测试反馈，每天发1-5个新包测试。工程师白天修复bug，我和策策晚上加班测试，第二天工程师上班时，Tower上已经写满了新的反馈。大版本测试通常用5-7天(小版本1-3天)，时间略长，原因是我有边测试边改需求的恶习，主要改交互不顺手的地方，一摸上手就知道感觉不对，当初设计不到位吖。于是边改需求我还得边改测试用例。
3、
大版本发布前，蝉小队会发动15-30分钟全员测试。
全员测试的绝招是——发彩票！
每找到一个bug，或者提出一项合理建议，发2元彩票，第二天兑现。以前用淘宝买给大家，现在网上禁售彩票，就去实体店买给大家。所以蝉小队一到测试时间都挺开心的，我走来走去地大声说：各位，发财的机会到了，中了500万一定要投资敝司当股东啊。
这句话我翻来覆去说了两年，有人好像中过30块钱。
最多的一次，我记得全员测试发了30多张彩票，说明在我和策策的测试完成后，大家还帮我们找到30多个bug，常有“吓出一身冷汗”的bug被挖出来，多半是出乎我们预料之外的产品场景，或者特殊的机型和系统版本。上个月的生辰1.1测试也发了10张彩票出去。
如果是蝉游记这样结构复杂的产品，全员测试之前还会分工，A小组测这个模块，B小组测那个模块，C小组……
4、
最后解释一下为什么蝉小队不设QA。
首先，我是绝对相信QA的，专业能力比我这种半吊子测试好到不知道哪里去了。但我也坚持亲手测试产品，因为测试流程逼着我反复大量触碰每一个细节，摸着摸着发现“哪里感觉不对”，然后快速提改动需求。如果我已经投入这么多时间来测试，而且也能找到大部分的bug，再额外设一个QA就比较冗余。
同时，我和研发工程师两端对接，直截了当，如果再插入测试工程师，同一个需求就得讲两遍，或者“凑齐人开会”，效率大减。而我在测试期间临时改需求，还得通知测试工程师，他烦我也烦。为了追求敏捷，我选择精简流程，压缩掉一切可以节约的环节。所以产品经理兼任交互设计师，兼任测试工程师，能大大提高流程效率。但从工作量的角度上来讲，再兼任UI设计师或者研发工程师就不现实了，PM+交互+QA已经塞满了我的工作时间，就算我有这个能力也没法兼任UI和RD，那会拖慢进度。
对于50人内的创业小团队，从效率出发，如果个人能力比较强，蝉小队的产品团队配置可能是相当好的方案。其实我这一个PM也够了，但我还要管不少运营、人事和资本层面的事情，占用了一半时间，所以必须有另一位PM来帮助我。这个配置能达到的效果是，拿蝉小队的4-5月举例：
-发布蝉游记5.0和5.01 iOS，算是中等规模的迭代
-发布携程周末1.0(从头研发)和1.1版本
-发布生辰1.1 iOS和Android 1.0(从头研发)
-5月底发布蝉游记网站大改版
-UI设计师除了上述产品设计外，还出了另一个玩票App的UI稿，排期在6月研发
-我在5月应该可以抽些时间，彻底重构玩票App“方言君”的原型
-我还帮另一款App友情重构了产品框架原型
