是啊，干测试都 6 年了，一些表结构设计 + 设计方案 + 设计思维 + 底层逻辑 + 数据流转，都是当时测试项目时，虚心请教开发，才有现在的经验。

我平时都会自己开发点工具，以便于在测试工作中使用，主要是为了装逼和提现自身价值

可以问下楼主是在哪里接单的？

我也在找兼职，但是测试的兼职 = 0，投了快 1 个半月了，回复的很少，一听要线上兼职，再回复的约等于 0 了

楼主是测试自学开发吗，计算机专业吗？

第一，眼缘
第二，看他干活的态度如何
第三，看我想不想招他

大环境真的这么差了么，最近在投简历，石沉大海

刷课系统，前端 vue3 + element-plus，后端 fastapi + mysql + redis + celery

可以问下这个是接的什么单子吗？
——————————————————————————————
5、6 月接的单，收获了 5K

是测试不想专精一门吗？是测试到处学一点吗？不都是跟着公司走，公司需要你啥都会一点，又不要求你精通。

反问一下，问什么问题才是正常的？

我成了守旧派？

具体看了什么内容，花了多少时间看了哪些章节？有什么收获跟感触可以分享一下呢？还是单纯的为了回答这个问题胡诌的，如果是这样那我会合理的怀疑你的诚信。你可以拿历史的书籍来忽悠我，但是不能拿假的内容来欺骗我。

哪个问题奇葩了？

你最近在看什么书？
答：《中华人名共和国劳动法》

纯个人想法，欢迎探讨。我的想法是软硬兼施：

硬：
1、结合需求文档等资料，明确和预期结果不符，说明是缺陷
2、拉上产品经理一起，从业务角度确认这个不符合预期，不满足实际业务需要，是缺陷
3、还是不行，但认为这个缺陷很重要的，继续上升到 leader 级别，由 Leader 级别确认解决

软：
1、日常和研发多吃饭聊天，打好关系，促进两边在这些事情上多配合，少扯皮
2、不要只提 bug，bug 少的时候也多夸一下研发质量好，绩效 360 评估的时候说说好话

最关键的：定好规则，把缺陷定义和原则明确清楚。
一般出现这种扯皮，说明大家对缺陷的定义理解不大一致，规则机制上不够完善。可以定期收集一些存在分歧的 bad case，一起对齐下，并持续完善相关的规则机制。用机制来明确缺陷定义和识别，减少扯皮。

首先，假设背景是我去面试别人。其次，我知道自己是什么水平。基于当前业务需要的各项能力以及对方的简历问问题。
简单区分：不如我的/跟我差不多的/比我厉害的。

看来我挺奇葩的，我就每次都会问最近在看什么书或者涉猎什么新的知识

这不都是正常的问题吗？不问这些问啥

穷则变，变则通，通则久

为什么要看？

《小米创业思考》
《以奋斗者为本》

这些问题都很常规吧。。

中华人民共和国劳动法

那什么问题不奇葩？