定会议室，开灯，喊人，确认会议结束，关灯。约下一次会议

测试 ld 可以揽问题，毕竟测试要对质量负责的这点责任心要有。但不能全揽在自己头上，测试可以改进，但是问题全甩到测试头上，那以后还怎么搞。其他部门对质量就完全没有一点责任了？测试完全兜底了？
这种问题在我看来，测试就是算有责任也是小责任，可以基于问题做为后续改进的参考。主要责任还是在前期准备，是流程的问题，要罚也罚不到一线测试。如果我是这个测试 ld，要罚就罚 ld 啊，这样大家也会比较信服。

一个业务测试专家对一个公司的价值一定远远大于开发测试工具专家。开发测试工具专家的能力是通用的，而业务测试专家的能力才是这个公司积累的宝贵财富，很难替代的。

先实习比啥都重要，别觉得测试就是这些技术。这些技术说实话都是死的，对毕业生来说最重要的是测试思维，很多应届生没接触过测试，觉得测试就是找 bug，但是对一个新人更多的要求是测试思维的逻辑性。你连测试点都梳理不清楚，会那些都没用。所以先去找家公司实习起来，有了测试的感觉，这才是拉开和其他毕业生的方法

没有业务能力的测试开发，只是一个支撑角色，它的价值在于业务测试团队的认可。
我之前在的大厂，业务测试人员的价值就是要大于纯测试开发的，绩效也是偏向于业务测试人员。因为团队可以没有测试开发，但是不能没有业务测试。
作为测试前三年你可以关注技术，但是至少你工作 3 年以后，你不管做什么你都要开始沉淀业务，足够的业务深度才能体现你的价值

从我个人经历这么多不同的公司来看，说实话没什么测试开发做的事情开发是不能做的，就算要学习，开发的学习成本也比测试低很多。真的如果开发技术很强的测开，没有公司不会考虑把他放到开发位置这样可以发挥更大的作用。
所以测试开发如果只是纯工具开发，其实和测试真没啥关系，就是工具开发。测试开发如果自己都不接触业务测试，真的没必要挂着测试的名头

测试提供自测用例，明显自测用例可以覆盖但是遗漏到测试环节的 bug，标记为自测型 bug。拿自测型 bug 作为开发提测的绩效考核指标

讨论团队学习的问题就像讨论教育一下，教育的本质是为了社会的人员分层，其实团队学习也是。你不能指望你组织团队学习每个人都会很认真的去执行，都提升很大，毕竟这些不是本职工作，但是如果你通过这种方式可以激发几个同学找到学习的方向，激发他的自驱力去学习就已经够了。更重要的是你可以通过这样的方式可以筛选出团队中真正更有发展潜力的同学是哪些，更好的对团队进行分层。
当然不是说不学习的同学不行要淘汰，毕竟团队中总有一些脏活累活需要没那么优秀的同学去做。

coding 测试脚本和开发自动化框架根本不是一回事，说实话，如果一个业务测试人员了解测试模块的系统架构，数据链路，看得懂开发的代码。我觉得他比不接触业务只会 coding 自动化脚本的人强多了。换句话说测试是用来找 bug 的，如何高效和高质量的找 bug 需要你对你测试的产品内部实现有深入的理解，而只会 coding 测试脚本的测试价值有那么大吗？

好的，多谢了