我觉得是分阶段的，去不去听则需要自己的判断了。
1.小白阶段——可以去听一下 前提是自己有一定的认识，不然会听不明白
2.提升阶段——听一些最佳实践的案例。看别人是怎么解决问题的，对比一下自己实践方案，我想你会产生疑问并有所收获
3.重认识阶段——这个可能是圆桌会议的方式。

我建议你可以做一些自动化功能帮助自己减轻功能测试的工作量。后面由机会再申请资源来搞大的。

三国志 战略版？

我的做法是做个自动发版的功能，思路与 14 楼的类似，通过 commitize(提交代码规范) 来控制，然后在发版的时候，自动化为代码仓库打 tag，遍历提交信息与需求管理工具建立关系，生成发布日志。对比一下需求范围，一目了然。
PS：还可以用新的 tag 来构建服务，发布到预发布环境什么的。
在执行过程中，发现一定是以需求驱动才好做，比较合适敏捷开发的团队。

一转测试深如海，只能起辅助作用，功劳不大，背锅第一。

这个笔误有点大

个人建议选择 B

月薪 30+，30 岁的我 望尘莫及啊。。

触动心灵，说得太实在了。

盖楼灌水做分母
分享故事做分子