我现在在的公司需要每个人每个月都要进行技术分享，这样持续已经快有大半年了。
我现在已经完全不知道要分享啥，能分享的东西已经全部分享完了，网上也都搜了一个遍，也和领导反馈过，但是没有反应...
我们测试组基本接的是别的平台项目，实际与本平台项目不搭边，所以感觉部门经理也不是很重视。
现在有点不知道分享的意义在哪里，还有就是不知道去分享啥，迷茫。（领导有时候也逛这个论坛，所以有些东西不能说。）
简单 做成系列就行，比如 Junit5 源码解读系列一~十二，可以搞一年。
然后再选个开源项目进行源码解读，再搞一年。
有用没？肯定有用，对自己有很好的提升。对别人来说，愿意听的也有收获，不愿意听的那就更无所谓了。
首先说下我的个人观点哈；
1、一个月一次，说实话并不频繁；
2、而且没东西分享更多的话找一下自己的个人原因吧，是不是自己太懒了？
3、我们之前的分享是一周一次，一直持续了快 2 年，每周三下午时候会花半小时到最多两小时的分享；
基本雷打不动，整个部门都会去，除非真的项目紧张，一点时间抽不出，会延期或跳过。全公司面我们也会分享；
分享的内容基础到进阶或者以前在其他公司的项目应用或实践，来着不拒；
docker 基本使用，git 基本使用及进阶使用，devops 项目实践，工具使用一大堆，脚本实践一大堆，业务测的分享完，分享理论测的，混沌初想，工程思维，应用数学项目实践，基础算法等这些都可以分享，软件分享完，分享游戏，游戏分享完，分享上游业务，花时间了解一下我觉得都可以拿来培养。
我个人认为分享的意义在于：
1、个人的横向驱动；
2、沟通，表达的锻炼；
3、横向面培养补偿自己的垂度领域；
不要把分享当压力，除非真的就是 Leader 无脑定，这样的话请把我的话当放屁，现在太多 QA 的小伙伴输在表达还有业务还有技术广度上了，面试，开会，说话紧张，手抖，嘴抖，脑袋空白，明明线下像个王者，上去以后像个巨婴。
我觉得大部分人应该是被迫分享，无非是因为绩效要求、晋升要求、领导强制要求，极少是真的氛围好在互相分享。强制就特别恶心，前面几次还好有东西分享，后面反而要因为分享什么而焦虑，费心费力，变得为了分享而分享，质量也差，毕竟不是每个人都是精英。
在日常测试工作中，如果能够发现一些，细节问题，然后自己是如何去处理的，提升自己的测试效率，甚至是，是如何解决问题的，分享自己的思路，其实这种也算是技术分享，技术分享，不一定非得是技术，也可以是技巧，思路，想法。
我们的分享坚持了很长时间，每周都有人分享，每个人三周轮一次，一般来说会选择极客时间的某一门自己感兴趣的课程，学习并在组内讲出来，不局限于形式，PPT，markdown，xmind 均可，关键在于讲出来，可以不是完整的知识体系，哪怕只是其中一个小的点，小的启发，都可以，平均每次分享的准备时间一般来说需要 1-5 个小时不等，实际分享时间在 15-60 分钟，取决于内容多少，这个模式我们团队已经运行了五年多了，除了节假日从未中断。（有惩罚措施，如果本周轮到你了但是没有分享，则可以按照 300 标准请大家吃个饭，多的部分 AA，正好也有理由聚餐了，这个请吃饭只能延后一周，并不能免除本次分享）。
每月一次，还只能是技术。。。这频率确实有点高。
1、是不是可以把整块的技术拆成点，也能借此机会把细节想明白；
2、不光可以分享，也可以问，痛点或者是项目应用方面的问题，也可以提出来，引导一下领导去推动解决；
测试可以分享的东西很多啊，如果我们公司开发测试多几次分享会，我能把所有人都洗脑了，我要让测试部门变成整个公司最核心最重要的部门
内容很多，看你想分享什么，不要怕别人已经知道
很简单的一件事，主要是你看的太高了，分享些基础的知识也是很好的，立足于自我知识巩固，而不是为了分享而分享
小狄子
回复
只有罚没有奖？这么高频率的分享，除非给出准备的时间，不然还是蛮有负担的。再有，请客 300 的标准。。。我辛苦上班才赚几个钱。目的是好的，只是这个形式值得商榷
必要的分享，有好处，但是做成了一种形式，那纯粹是在浪费大家的时间，特别是开发测试一起开的分享会，真正听的有几个，哪些人听得懂，依我经验来看，相当一部分搞技术的还是相对比较内敛的，
并不觉得测试可以分享的东西很多 再多的东西 一个组一个月 10 人的标准来算 一年也有 120 个分享了 更别说，主管的要求是：结合实际业务测试（别分享没用的）形式主义真的很烦！ 每季度一次 + 内容不限的话感觉还 ok
小狄子
回复
有惩罚措施，如果本周轮到你了但是没有分享，则可以按照 300 标准请大家吃个饭，多的部分 AA，正好也有理由聚餐了
好恶心的聚餐理由。
卡丁车卡丁丁
回复
不打算解释说明什么，也没必要。我们团队内部觉得这并没有啥，而且一般很少出现延期，大家都很遵守约定，也很乐意去聚餐（纯吃纯玩，完全没有应酬啥的）。
5t5
回复
我感觉分享是一个非常好的做法，我现在的 QA 团队分享都是基于业务测试，技术分享挺少的，大家除了业务测试就是业务测试，感觉不到个人能力上的提升，更别提做什么技术 topic，如果自己一个人去做，进度、成果会很慢，没有被其他人认同，甚至过段时间就觉得做的东西没什么意义，所以个人感觉持续的技术分享可以积累大家对技术的兴趣，然后吸引有兴趣想做的同事一起做有业务价值的技术 topic。
之前业务繁茂的时候，相应的需求要求都高，那时候不用人管，你都会自觉学习，因为你要胜任这份测试的工作，不至于天天被骂，现在好了，业务缩减，需求要求都降了，不止是后方降，前方也降，那还要你学习、加班、分享啥鬼东西的，就好比，实际我全司业务日 PV 就只不过 200 万而已，你硬是要我加班学习来应付日 PV2000 万的量甚者更高。
分享是个很好的做法，但是实施起来总会有各种各样的问题，落地的情况总会和预想有些出入，但是个人觉得初心是最重要的，那就是保持持续学习的习惯，以及对未知的好奇。
可以分享，重点在于有没有给时间准备
so~ 以前也有过技术分享的会议习惯，其实主要在于你们有没有注意行业技术动向，当然测试确实分享的技术有限，不过可以分享一些若干的工具例如一些产品的便携共同修改、兼容性工具、性能工具、类似按键精灵工具等等……每次体验完都可以在分享会里共享，相当于介绍一种你觉得很有趣的技术工具，之前海外的 pm 介绍了 jmeter，是的没错，这东西在测试面前分享作为 tester 本身觉得会很没意思，但对于他而言是他探索的一部分，这不就是分享会的意义嘛？加上现在 chatgpt 的出现，确实可以问到很多我们测试没体验过的工具
每个人每月一次，这也太夸张了，那确实会待着比较难受，我再上家公司待了三年就分享了两次
分享本身更多是对于分享者的锻炼，因为你分享的东西一定要是自己经历过，总结过，有体会的产物。说白了是你已经懂的东西，而参与分享的人只是通过短短 1 小时听一下，除非他也有相似经历，否则吸收程度应该很低。
所以其实不需要太纠结，当作一个机会，做自己技术领域的定期总结 + 演讲能力锻炼就好了。
确实没什么分享的，在网上找与测试相关的就分享吧
这个定期分享的规则 对你领导有效吗？他分享吗
都需要分享什么，随便分享，找一个技术，如 UI 自动化，接口自动化，测试平台，jenkins，CICD，多得是可以分享的内容
分享这个事情，一旦强制频率，确实会很难受。而且固定每个人每个月 1 次，这频率确实有点高。。。
制度无法改变，就只能适应。如果实在没啥好分享的，直接分享这个月的日常工作和背后自己的一些思路呗。
主要是分享还没人去这才是尴尬的
