06 测试是否需要过早的参与产品需求讨论？
一般我们会认为专业的事交付给专业的人去做，等产品把需求文档写清楚后，我们根据需求文档来写用例即可。但是在当下敏捷的环境中，产、研、测三方需要更早的对齐需求，达成目标一致。所以测试需要适当的左移，协助产品完成需求的梳理，以实例化的形式把需求表达清楚，写好验收条件。这是非常有必要的。有以下几点好处：
- 产品把需求梳理清楚了，也知道怎么验收了
- 研发知道要做什么，做成什么样算是基本做好了
- 测试在这个过程中，就把核心用例设计完成了。还可以给到研发做为自测的标准。
- 产、研、测三方达成一致，避免因为理解上的不到位引发返工浪费。
注：我们可以适当提问题，做实例化，但不要过多的提意见或者帮产品做决定。因为大家对需求的上下文并不了解，不要太过武断。相信产品人员的专业度。
07 项目总是压缩测试的时间，怎么解？
作为研发链的后端环节，时间被压缩的情况时常会发生。我们需要在项目整体规划的时候，就去争取相对独立的测试时间。这个“独立”指的是专门用于回归测试的时间。在敏捷的环境下，我们希望研发人员尽快交付可测试的功能点，分批提测。同时，在最后的回归测试，需要留出专门的时间来处理。
如果因为项目周期紧，不得不压缩测试时间的情况下，测试需要做好以下几个关键点：
做好测试策略：在有效的时间内，如何做裁剪，哪些是必需要保证的，哪些可以适当放松，一定要分好主次，把有限的时间投入到最高价值的业务中；
做好风险控制：识别系统风险，对于无法覆盖到的场景，需要提前考虑会产生哪些风险，对应的策略是什么，分别对应的预案是什么，提前在组内形成统一的回复口径，避免各说各的。
组内通报：把上面两点落地到文档上，并通报相关人员，大家达成共识。
08 线上发现缺陷，都是测试人员的问题么？
这个问题是对测试人员的终级拷问。花了那么多时间和精力投入到测试中，为什么还会有问题遗留到线上呢。对于这个问题，个人的理解是，先解决问题！测试人员需要积极配合开发，先把问题解决了，这个时候不需要去考虑是谁的责任。
事后追溯的时候，需要先分清楚问题的类型，并加以改进。一般会有以下几类：
简单易现的问题：如果是比较简单就复现的问题，那作为测试人员就要反思下为什么了，这个锅跑不了，还是要有对自己的工作负责的态度。
特定场景或者数据才会出现的问题：这种情况，遇到一次，就完善一次用例（如果能自动化，就最好了），同时思考为什么只有这种情况才会出现，类似的还是不同环境配置引起的问题。这类问题需要注意平时的积累，形成自己的经验，这类问题，可以团队一起背，但要给出改进方案，不能多次在同一个地方跌倒。
深层次的偶发问题：这类问题其实是提升团队技术能力很好的试验场，集中力量解决掉就是了，更能激发技术宅男们的热情。这类问题，一般情况下做好线上监控，能及时预警，比客户更早或者不能落后太多发现，就可以的，让团队有缓冲解决问题的时间就好（准备好相关的话术，安抚客户也是OK的）。
09 发现bug越多说明测试越有效？
还记得第3问么？测试开发为什么会对立，大多数就是因为缺陷的归属问题。测试人员发现缺陷是应尽的责任，但并不是唯一的责任。测试活动并不是以发现缺陷为最终目标。很多测试人员会以挖掘出一个经过N个步骤（N大于10之类的），才会出现的缺陷为荣。个人并不是很认可这种观点。从用户的操作行为来看，可能永远无法发现这类问题。把大量的时间花费在这上面，并不值得（如果这类缺陷会引发重大问题，才有价值）。
测试的本质是希望贯穿整个研发周期，形成闭环，并持续改进测试流程，以终为始、系统地分析测试需求，在资源和测试目标之间寻求平衡， 基于风险的测试策略是必不可少的 在分析和设计的基础上，尽可能地实现自动化测试。
10 测试有没有钱途
这个问题本来想放在第一问的，毕竟是大家最关注的问题。但个人觉的这也不是个问题。软件测试现在虽然不像前几年那么火爆，但还是处在行业的红利期，所以钱途还是有的（隔壁的土木同学都提桶跑路了）。测试不是一个能让你大富大贵的暴利行业。但做为一个安身立命的职业，还是绰绰有余的。大家可能会在忧虑“35岁”现象，但这是你从事大部分行业都会遇到的问题（事业的尽头是编制），我们能做的，是让能力的增长跟上时间的增长，不管是在专业技能上的积累，还是在管理、人脉等软技能上的积累，都需要跟上行业的发展，现在没有什么可以让你躺平的行业（家里有矿的另说）。测试的天花板也没有你们想的那么低。没事多看看招聘信息，多和行业高手互动。测试还是大有可为的。
10问聊完，大家对测试是否有新的认知呢？在整理这10问题的时候，自己也做了更多的思考，测试这份职业还是比较好玩的。个人从事测试10多年，还是热爱这个行业的。测试相关的问题，欢迎沟通交流。
