继续浏览精彩内容
慕课网APP
程序员的梦工厂
打开
继续
感谢您的支持,我会继续努力的
赞赏金额会直接到老师账户
将二维码发送给自己后长按识别
微信支付
支付宝支付

月薪50K的测试,背锅的姿势比你优雅(2) No.164

一名叫大蕉的程序员
关注TA
已关注
手记 101
粉丝 118
获赞 464

稍微复习一下核心要点。

对于软件的质量保证这件事情有三个原则是可以遵循的。

一件事情越早介入,发现问题和解决问题的成本越低

在成本可控的情况下,对测试目标进行高频次高强度的测试

永远有 Plan B

软件工程作为一项系统工程,缺陷并不是在测试阶段产生的,只能说是在测试阶段才被发现出来。但是历史证明,一个缺陷的出现,常常在设计、编码阶段,甚至在需求阶段就已经显露了必然故障的影子。但是产品经理不关注,开发人员不关注,把这一切都堆积到测试阶段,软件质量可想而知,数据必然是没那么好看的。从FB、Goolge 各个厂的质量保证体系的先进经验来看,其实各个阶段测试同学都可以介入,介入的阶段以及手段,也是很讲究。

需求阶段评估需求可测试性。

设计阶段评估架构可测试性。

编码阶段要求开发自测。

测试阶段进行工具化和平台化。

上线阶段进行预案和监控梳理。

日常阶段进行故障梳理和演练。

那么问题来了,什么样的需求才是可测试的?怎么权衡在需求阶段对于测试资源的投入?开发究竟要交付什么东西,才能让开发和测试都比较开心?

简单来说,我就是不想要bug,而且还要轻松。

我先说说结论,不想要bug而且要轻松的唯一途径,就是把不必要以及优先级不高以及描述不清晰的需求砍掉,需求寻找其他非软件方式的解法。

对于测试来说,开发交付的东西越全面越好,越清晰越好。能用图描述的就不要用文字了。能用结构化的文字描述的就别只写在注释里。能解耦开的东西就不要写在一起了。能使用现有成熟方案的,就使用现有成熟方案不需要投入大量测试了。

对于开发来说,无论其他人要求开发交付什么东西,开发都不会开心。毕竟开发除了代码其他都不想交付。(代码都写不完了还要其他?想啥呢)

但毕竟嘛,需求该做还得做,上线了出问题,大家都得背锅。需求阶段把这几个问题抛给你的产品经理,自己多想想,多问几个为什么,可以减少你非常多的扯皮时间。

这个一个面向用户还是面向汇报还是面向kpi项目?

这个需求背后的用户真正诉求是什么?

如果我是用户,我希望这个产品的形态是怎样的?

不做系统能不能有现成的方案解决用户的诉求?

这个需求真正实现需要怎样的成本?

这个需求是不是一定要现在做?

如果一定要现在做,还有哪些点是需要确定的?如何评估阶段性成果。

需求是不是已经比较明确了?包括需求的边界,产品的流程,系统的输入,系统的逻辑,系统的输出,团队的合作模式,已有技术或产品的可行性评估。

多想一下,你会有自己的判断,当然产品经理会非常讨厌你这样杠他,所以如果一旦有真正需要表达出你自己观点的场合,请务必带着你的思考和方案去 diss ,而不要只是笼统的我就觉得这玩意不行,还不够细,这不是用户的需求。也就是说,发言之前请掂量掂量自己的份量。

面向用户,精细做。

面向汇报,漂亮做,好看能跑就行。

面向kpi,砍到极致,能用就行。

至于开发同学应该交付什么东西,其实也是有一定的标准的。首先开发同学要保证自己接到来自产品经理的需求,是明确不含糊的,而且技术理论上也是可以实现的,才可以把任务迁移到自己身上。如果存在不明确的,请务必留时间让产品经理继续打磨再交付。如果技术还没有被证明可行的,请务必留时间让自己做好技术预研。

这个阶段应该要互相合作,开发做了一个demo,请马上联系产品经理验收和确认,多聊聊。产品经理有一个不得不改的需求,请马上联系开发稍微评估一下可行性和变动成本,如果确实紧急,马上按照需求变更规范进行变更。麻烦不要出现这种情况,开发永远只说这个需求做不了,产品永远只说这个需求很紧急。

这里有个 check list,开发同学在开发设计阶段必须要清清楚楚在自己电脑上写明白的,共不共享看测试同学的诉求。

1、细化到模块的产品流程文档

2、核心模块设计和系统架构图和业务模型设计。

3、核心系统交互流程图。

4、产品异常流程图以及对应的系统交互图。

5、外部接口对接文档的详细解读。

6、所提供服务的接口文档。

7、模块测试用例(测试同学帮忙)

8、数据库设计详细ER图。

9、系统水位预估,是否需要缓存、限流、降级。

10、上线 check list 梳理,部署顺序、数据库、回滚等

能做到这些的,说明你对于稳定服务的意识已经很强了,这时候交付给测试同学的代码内容,也是比较可信的内容。这么梳理除了质量会比较高之外,对于开发同学的开发效率其实也是一个非常高的提升,上面这些内容可能只会花掉你一到两天的时间,这比你将来花更长的时间定位问题处理故障,要好得多得多得多。

当然,如果是面向汇报和面向kpi编程,怎么快怎么来,反正项目死的可能性非常大,你别还没做出来项目就凉了,那就本末倒置了。



打开App,阅读手记
0人推荐
发表评论
随时随地看视频慕课网APP