先稳定落地,再考虑其他
优点:从不说谎
缺点:除了面试
一个建议:只陈述不评价
一个想法:不去做所谓的统计分析报告,将一个测试周期内的工作日志发出来看,粒度达到半小时,大家一起来看看测试在测试阶段都做了什么、遇到了什么,让观众去自己去思考测试阶段的问题情况吧
留白是种美德,如果他们很蠢,那就留的浅点
你说质量问题是指背景内描述的问题吗?
背景:该类问题的出现可以从系统的软硬件依赖出发,确定各依赖件的版本等情况。
正向出发:确定系统的配套情况,在安装时使用配套软硬件,即可避免大部分部署问题的出现
反向出发:统计已发现问题,分析问题原因,据此提前准备解决方案或规避措施
问题:质量变化无外乎高低好坏,原因无外乎问题多少及分布,优化无外乎针对性处理 (参考上一段)
听君一些话,胜读十年贴!
此贴给我带来的只有深深的不适感,也可能是自身悟性不够,请看到此楼的大佬在楼下帮忙解读下
本质上是版本控制流程问题,所以来寻求解决方案。当时开发也确定了问题原因,但是并没有去思考解决方式,我就来找大佬们求援啦
感受就是你感受的太晚了,我都习惯了感受这种变化。
有时最怕的不是不会,是连吹都不会
“如果能够穿越到 10 年前,你会给年轻的自己什么建议?”
买房买地买币,收购 QQ 收购 ali,剩下的留给你们了
真实
多谢大佬的建议
其实这个事情在我发现这种问题出现的时候就多次找开发 leader 以及我们的产品 leader 进行过沟通,也说明了这种事情所带来的风险,可惜所处位置的话语权不够以及产品整体的重心还是交付向,后面就不了了之了。
这次来请教各位同行大佬也是想确定下自己的认知是否正确,以及准备一套较为可行可信的改造方案,后面再就此事进行更好的推动
我这都不知道该找哪个了,天天换组织架构。。
这就加上
多谢大佬回复
现在主要是开发拍脑袋定流程,一切质量由 bug 来保证,就导致了这种现象。
这就来向大佬求经,等后面有机会或推动力的时候就从流程入手,参考恒捷大佬的建议,先加入单需求分支测试,再进行两次单需求/主线合入回归,需求分析时也会适时提出需求拆解的建议
懂了,这就去搂平台
这就去加班!!!!!
是的大佬,两个分支,一个开发共用,一个测试用
1.在有多需求改动时,可能会存在多人在同一代码文件内进行不同位置的更改,进而对非需求涉及范围的代码产生了影响。这是我咨询开发后的理解
2.大佬说的很贴切,只是因人力和环境限制,暂时只有两个分支,或者从 CI 角度来说只有 dev 一个分支,test 只要合代码就会变成与 deb 一致的状态。期间没有什么专项性测试或者单需求分支的环节,这可能就是问题点,没有进行
单需求测试 ok》合入总线测试 Ok
多谢回复,后面看看有没有机会推动这个环节
为啥不先提一提涨薪试试,不行再说离职的事呢
普遍性平台的话大概都是以下功能,接口平台为例:
接口管理、用例管理、在线调试、Mock、抓包 + 转换、报告管理、参数管理、设备/项目管理、并发操作等
怎么提啊,找到领导对他说:领导,我要涨工资!?
频率怎么样啊,一年一次还是如何啊大佬
是的,就是不知道该怎么去避免这种负面影响
可能我表达的不清楚,这里的问题更多的是本地提交到 dev 导致无关功能受影响,是否有流程上的优化方案,这里在我理解应该不在测试负责的范围内
因为功能模块较多且需求改动较为小而频繁,所以每次改动的主流程验证目前看来不好实现,而且开发自测质量也比较一般。所以想从流程上请教下有没有优化方式
正在紧张审核中...
骑驴找马,方得安心
还在等下月不知道有没有的年终奖。。。二线城市感觉还行,没多大压力