打字猴:1.704233956e+09
1704233956 ► Less Testing: 减少测试,或者不重视测试。听到一个很搞笑的故事,某位技术同学写完代码做单元测试,第一次没过,百思不得其解,于是再测一次看看,结果过了,再测,又过了。于是,就认为第一次是幻觉。
1704233957
1704233958 ► Skip Error Handling: 不考虑异常情况,直接假设用户都是正常使用(当然,在业务方认可时确实可以这样做)。举一个最简单的例子,输入框没有做安全上限的长度控制,用户可以通过输入过长的内容来直接使网站挂掉。
1704233959
1704233960 ► Descope: 偷摸减需求,只做主流程,不做分支流程。不用举例,真的会有,验收时产品经理发现了还好,但只验收主要场景是发现不了的。
1704233961
1704233962 ► Less Review: 减少设计评审、代码Review等。强技术的确可以少评审,但会动用Secret Toolbox的同学往往并不是很厉害的人。
1704233963
1704233964 ► No Autotest: 不提供测试自动化。工欲善其事,必先利其器,一直不磨刀,整体效率就一直上不去。
1704233965
1704233966 如果对技术缺少敬畏,就会在不知不觉中背上沉重的技术债务。一次交付最终完成,当你看到需求都已满足,心里甚至还会暗爽:就是要逼吧,你看,逼一逼都做出来了,下次继续……但这种理想状况不会持续太久,总有一天你会发现,整个技术团队越来越不愿意承诺,即使承诺也越来越难履行,效率好像越来越低。要么任务经常延期,要么出活越来越少。这些现象表明,用来填坑的时间越来越多。
1704233967
1704233968 直到有一天,技术Leader面露难色地找到你,说:
1704233969
1704233970 “兄弟,业务发展太快了,技术架构跟不上,要重构了。”
1704233971
1704233972 “啊,要多久?”
1704233973
1704233974 “两个月,一大半的兄弟都要参与。”
1704233975
1704233976 “不可能,因为……”
1704233977
1704233978 “必须重构了,不然说不准什么时候就挂了。”
1704233979
1704233980 以上就是技术负债前后生动的一幕。
1704233981
1704233982 测试是个专业活
1704233983
1704233984 测试工程师也是技术人员的一种,他们与产品经理做事的思路有明显差异。产品是把握大方向,而测试是专盯细节。有一次我在知乎上看到一个很有趣的问题,通过这个问题,正好能把一些常见的测试概念科普一遍。
1704233985
1704233986 问: 为什么互联网公司开除测试,转而让大众来测,找到一个Bug给100元?
1704233987
1704233988 答: 大家的讨论很有意思,不少都是围绕100块够不够、给不给、怎么给来说的。我的角度是,测试是产品团队里一个重要的角色(团队早期可能由产品经理来兼任这个角色),没了他们还真的不行。
1704233989
1704233990 00. 默认前提是,开发已经做了单元测试 和冒烟测试 (原则上冒烟测试应该测试来做,但人家都被你们开除了啊,只好让开发来做了,至少要保证交给大众的是一个能跑起来的产品),这两项总不至于期望大众来帮忙做吧。
1704233991
1704233992 01. 很多Bug其实并不是非黑即白,也许产品就是这么设计的。这些内部的测试知道,但外部的大众不知道,他们用起来觉得不爽,当Bug提了,这钱是给还是不给?哪怕公司内部,当测试发现此类问题(比如为了安全考虑,第二次输入密码的确认框不允许复制粘贴),开发说这是一个需求/特性 ,还得再把产品经理叫过来一起讨论,外部可做不到。
1704233993
1704233994 02. 专业的测试需要测试用例 (Test Case),但常见的测试用例(临界值相关、内存会不会泄漏、特殊字符……专业测试人员玩起来一套一套的,分分钟把开发认为没问题的程序挂掉)在大众那里可做不到,更不要说TC评审 了。或者说,大众永远是知其然不知其所以然,所以只能做黑盒测试 ,没有办法做白盒测试 。
1704233995
1704233996 03. 专业测试提的Bug是分级 的(成熟的产品应该有Bug分级标准和规范)。研发流程里应该有相应规定,几级以上的Bug必须全部close才能发布;开发也会按照级别来确定修复顺序,并不是所有的Bug都需要马上修复。而大众提交上来的Bug,还得额外安排人去做分级Review。
1704233997
1704233998 04. 专业测试会把Bug指定给特定的开发或产品经理,背后的逻辑是这些特定人员知道技术角度的模块划分,以及对应的负责人,只有这样才能方便流程向下执行。而大众提交上来的Bug,还得安排人去做assign to这个动作。
1704233999
1704234000 05. 专业测试懂得用开发明白的语言描述Bug,能说清楚是什么机器、什么系统、什么版本,特别是能说清楚“如何重现”。而大众提上来的Bug,出错环境不明确,Bug重现 不了,急死你。
1704234001
1704234002 06. 内部经常有针对Bug的讨论,部分Bug可以defer或reject。那么问题来了,谁来牵头组织讨论,以确定Bug状态 的流转与控制?可不要指望大众会“跟进”自己提交的Bug。
1704234003
1704234004 07. 如果开发比较牛,能理解大众提的Bug,但改完后谁来确认是否修复,谁来close这个Bug,整体的回归测试[8] 谁来做?
1704234005
[ 上一页 ]  [ :1.704233956e+09 ]  [ 下一页 ]