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 ]
[
下一页 ]