前些日子，在知乎上看到一个很有趣的问题：
回答的讨论也很有意思，有不少都是围绕“100块够不够、给不给、怎么给”来说的，我的角度是，测试绝对是产品团队里一个重要的角色（注意，不是自然人，创业团队可能就是产品经理来做这个角色），没了他们还真的不行，回答如下：
默认前提是，开发已经做了单元测试和冒烟测试（原则上冒烟应该测试来做，但人家都被你们开除了啊，只好让开发来做了，至少保证交给大众的是一个能跑起来的产品），这两项总不至于期望大众来帮忙做吧；
很多Bug其实并不是非此即彼的，产品就这么设计的，内部的测试知道，但外部的大众不知道，觉得用的不爽，提了，这钱是给还是不给？哪怕公司内，测试发现此类问题（比如为了安全考虑，密码第二次输入确认的框不允许复制黏贴），开发说这是一个需求/特性，大家还得再把产品叫过来一起讨论下，外部可做不到；
专业的测试是需要测试用例（Test Case，更不要说TC评审了）的，常见的测试用例（临界值相关、内存会不会泄露、特殊字符什么的……专业测试玩起来一套一套的，分分钟把开发认为没问题的程序搞挂），在大众那里可没有，不踏实，感觉……有点像西医和中医的区别，敏感话题不展开；
专业测试提的Bug是分级的（成熟的产品也应该分级标准和规范），几级以上必须全部close才能发布什么的，开发也会按照级别来确定修复顺序，大众提交上来的，还得安排人去分级review；
专业测试会把Bug指定给特定的开发或产品经理，背后的逻辑是知道技术角度的模块划分，以及对应的负责人，方便流程往下，大众提交上来的，还得安排人去做assign to这个动作；
专业测试懂得用开发明白的语言描述，说清楚是什么机器、什么系统、什么版本……特别是“如何重现”这件事，大众提上来的，Bug重现不了，急死你；
内部经常有针对Bug的讨论，部分Bug可以defer或reject，那么问题来了，谁来牵头组织讨论，确定Bug状态的流转与控制？可不要指望大众会“跟进”自己提交的Bug；
如果开发比较牛逼，理解了，修完了，是否修复的验证谁来做，谁来close这个Bug，确认修复？整体的回归测试谁来做？
QA相关的还没说呢；
其实，这个在方法论里面接近于“UAT，用户接受度测试”，有的也叫验收测试，经常由产品经理代表用户做（当然，有资源最好让用户亲自来），不是找Bug，而是看产品是否满足用户需求、设计是否符合用户认知什么的；
这事儿很好，有条件都做吧，但更多的目的是找个理由和用户互动；
好问题，帮我复习了一遍和测试有关的概念，暂时想到这么多，大家可以补充。
