• 好哒,亲分享的经验很有用。我记下了。感谢你💕 💐

    今天跟领导聊了哈,细节。大体上就是这些东西。很细致了,但,上线标准哪里还是没有定。我也没整明白,这个东西该怎么弄。
    说明,红色字体部分是确认了的。

  • 嗯嗯,是的,测试报告只能出具自己经手后的。UI这个领导已经拍板了,没得反驳余地,我也只能从旁协助,尽力。 上线标准,还未敲定,但我已经搁置和领导谈这个了。主要也没想明白。

    最后,谢谢你,感谢分享经验和看法给我。

  • 嗯嗯,谢谢你,分享经验和看法给我。 我已经搁置和领导谈这个事情了,主要我也没有想的很明白。

  • 喔喔,好的呐,谢谢你分享经验给我。

  • 嗯嗯是的,做决策的自然是要承担对应责任的。还有是,我们这边测试要是做决策,相对应的制度规范从上到下都应该是有测试来定,这样才能全面提高项目质量,如果只是这一个‘上线否决策’由测试定,那也是无法保障的。再说,我们测试这边暂时做不了这些的制度规范,经验不够眼界不够,再是公司层也不会允许的。

    最后,感谢你的回复和经验分享!谢谢!

  • 嗯嗯,是的呢,不太理解在项目这个阶段为啥要来做这个。因为是领导要开始做制度规范嘛,我觉得既然要做制度那就不能模糊,不然实施起来就会有很多问题,还是尽量清楚。

  • 先感谢亲的长篇回复。我觉得你一定是个很温暖的人,愿意分享经验给我。所以,再次‘万分感谢您的指教,感谢’!!!💐 💕

    我们是自研业务项目,测试用例是用的Excel表格来做。测试计划倒是提醒了我,我之前是没有进行过书面的文档计划制定,都是靠经验来的,现在看来很不靠谱,我会提上日程,感谢亲!

    我不接这个决策权是实力不允许,无法达成此项成就。按之前经验,我的确是在每次迭代过程中是做上线决定的那个人(这也是领导想让测试做决策的原因之一),但是是有前置条件的,就是时间节点已经非常明确,是非上不可的那种。这时我能把控的是说上线内容不会出现大问题,而且我能把控的只是研发完成进度和修复bug进度情况。相对于亲你的实际情况哈,我们公司1是没有做微服务化才分,2是模式还是传统的开发模式,3是产品总监也干预不了老板要求。大概就是每次干扰上线节奏的,是排期功能巨多完全不看实力,还有研发实际技术能力和公司穿插的业务支持工作。这不是测试做制定就能够干预的,1是无法干预公司高层觉得和技术实力,2是无法跟公司高层或业务层进行时时共享,协调支持时间或提早干预。 当然,亲的建议我还是觉得很合理,如果是专业的互联网公司,这样子的权限下放我还是很乐意接受的,但是,具体情况具体分析晒!

    关于上线标准,前面有位同学的建议,我觉得是可以有,这个DI阈值确实只能保证实现质量,但是能否上线,应该还是需要一个业务标准来 参考哈。然后是具体情况具体分析,跟领导前两天的沟通力,我公司是允许带小瑕疵上线,而我是觉得的:有时候小瑕疵可能会影响业务但不影响功能。

    UI测试这个问题是在争执,UI组去测试之后给的问题反馈是测试去回测还是UI自己去。然后就说到界定UI测试的范围,比如说样式布局算UI的还是测试的。领导给了个很有意思的界定,即:“测试组在测试过程中,如果能不去跟UI组确定核实的,就不是UI校验的东西”。emmm...诶,反正讨论已经结束了。现在正在执行中,UI组一直喊我们去给他造数据,因为有些页面,有些小功能都出不来,我们又比较忙没时间造的很细致,就一直跟UI皮,磨....

    就我自己来讲,我是不介意多做事情,因为我自己对这个是抱着学习态度的,做的越多知道的越多经验越多,往后越轻松,路越宽。

    但就这个公司这个领导来讲,如果领导坚持界定职责范围,流程规范,我会坚持,定义就要去定义得清楚明白的。

    最后,再次感谢你,谢谢你,分享经验给我。

  • 嗯嗯,是的。 测试产出是需要做好对应记录。
    能力强多做点是关系的,多学习总是好的。
    就我坚持的是:如果是在界定职责范围,那就是需要明确的定出来。

    感谢亲的,指教啦~谢谢你。

  • 今天依然是跟领导继续讨论的一天,但是还没有最终定义的。今天没有进行电话会议了,昨天电话了一天没有实质性进展而且耽误工作,所有改变策略,用微信群远程,而且,我觉得,文字在一个字一个字敲出来之后,也会再次思考一次是否合适。所以,今天经过上午的沟通,有进展,但还没有结束。

    如,上午跟领导已经有共识。测试不做上线决策。出具的测试报告中不含UI/验收部分,如果涵盖那么就是另一个意义上的报告了,跟测试脱出来。

    我有做的不对的地方,再次请‘亲们’指教哈。

  • 嗯嗯,谢谢指教。

    是的,不同的职能,要求和承担的责任就会不一样。