不上不下的“中型”公司如何解决没有测试问题？

[zzNaLOGIC]

公司目前到了发展瓶颈期，不算小但也算不上“大”，更奇葩的是每年营收倒是不少，但至今没有测试部门，点点功能的黑盒测试都没有，一度令我震惊。现在每次上线就靠自测和最终产品点点验收一下，约束基本靠出问题之后写事故报告扣钱（虽然目前很少真的扣钱）。
也跟老板反馈过很多次加测试，但是阻力一直如下：
1.没有正儿八经的测试流程，对应的招点测试来也基本没有上升渠道，基本招不到测试。
2.招一个没用，招一堆开个部门成本太高，舍不得。

现在业务量越来越多，再加上我们是一周发一次版，出事故的概率越来越高。而且因为系统比较老，牵一发动全身，没有测试开发的也测不到哪里会有影响，不少人觉得事故报告写的很冤。

不知道有没有类似情况的公司，你们是怎么解决测试和验收问题的？

[aiwoshishen]

这是要找个测试背锅啊

[tomczhen]

君子不立于危墙之下。

[NathanInMac]

自动化测试呗，自己写自己测

[dode]

开发写单元测试

[guguji5]

@NathanInMac 写自动化测试肯定会拖慢开发节奏啊。小公司一般不会给这个时间

[zzNaLOGIC]

@aiwoshishen #1 过于阴暗了。。。

[xuanbg]

自己写自己测啊，这一点我们和微软已经在同一个高度了。哈哈哈哈

[zzNaLOGIC]

@NathanInMac #3 一周发一次版，而且期间的工作量也不少，要是愿意给时间早就不纠结测试的事了

[charlie21]

鉴于软件复杂度本身 (v2ex.com/t/975722?p=1)，系统设计水平如何？是否能很快定位到 bug 在哪，并且通过解耦来降低 “牵一发而动全身” 的情况

[qooweds]

解决质量问题本身就很贵
如果你可以接受 50%的情况没问题,可以自测
如果你可以接受 70%的情况没问题,可以招一个测试随便测测
如果你可以接受 90%的情况没问题,可以组一个黑盒测试小团队
如果你要求 99.99%的情况没问题,成本更是天价
相对于流程优化,单元测试,codereview 这些性价比相对更低的方式,还是招黑盒测试更加便宜
连招黑盒测试这点成本都不愿意掏,其他的就更别谈了
如果老板认识不到这个问题,这种测试都不愿意招还要罚款的公司,还是早点跑吧

[juzzle]

招俩，够用就行

[43n5Z6GyW39943pj]

开发自测太累了,都没心情写代码

[lxcForPHP]

我们小作坊，五个人的团队都有测试，没有经过测试就发版，真是的提心吊胆的。

[errZX]

一天发一版，只要心够大，甲方就是测试

[Bingchunmoli]

简单，直到一次亏了几十万，老板就不省了，， 朋友公司就是这样

[pelloz]

小团队就让 ui 和产品搞测试，他们给开发提供输入，还能给结果做验收

[grissom]

Test Driven Development

[grissom]

Consumer Driven Contract (CDC)

[grissom]

但问题不一定出在没有测试人员上，需要调查或者评估大部分的 bug 通常出在什么地方，比如产品规则定义细不细，流程是否清晰，开发理解的是否准确，产品验收工作是否到位，在这些有实际的岗位上做一些工作观察一下，可以把研发成本分摊到各个团队，在前期适当增加一些成本。不然即使招测试团队，根本问题并没有解决，只是转移其他团队身上，而且测出问题一样是需要花时间成本修改和复测。

[IvanLi127]

既然要扣钱，那顺理成章的就是追加工期，开发自己写测试用例呗。。。不然也就剩下摆烂这条路走了。

[zyxbcde]

甲方就是测试，一天发 5 个版，别说测试了，连测试环境都没有，连生产库开发。毕竟一个人月只要 15000 。

[smlcgx]

用户就是测试，一个 bug10 块钱

[msg7086]

@guguji5 只有我觉得写自动化测试可以提高开发速度吗。

[Terminl]

不要担心，移动算是大企业了吧，他们自己的业务也没有测试。都让老百姓投诉找

[qeqv]

好像我之前一家公司，当时我是把我负责的部份，自己写一个测试流程，每次开发完手动执行一下。
然后仍然是产品和运营人员点点验收一下

[lsk569937453]

有没有可能技术根本不重要，项目只要能跑就行。。。

很多 TOB 的公司都是靠销售/渠道吃饭的，只要能把合同谈下来，项目的主流程走通就行了。技术真没那么重要。

[codeself]

如果老板认识不到这个问题,这种测试都不愿意招还要罚款的公司,还是早点跑吧

[Vindroid]

那就说明你们公司的客户对于质量要求并不高，只要出问题能有人来救火就好。现在不都流行付费测试吗？

[qb20150806]

@lsk569937453 确实，我们也没测试，东西卖出去后软件算是赠送的，能用就行，有问题让他们刷新一下解决大部分 bug

[MrSheng]

可以考虑下外包测试人员

[helloworldgo]

出一次大事故、丢两个大客户，马上就给安排了

[8355]

当事故损失严重影响到收益你就会醒悟，招测试有这么大阻力，狠难想象开发人员是什么水平，对这个事情本身认知有问题。
测试是减少严重事故发生的主要手段，要么开发自己写单元测试，要么招测试来写，但是测试的过程是不能少的，这么多问题都出现了还感觉好像挺无所谓的。。。可能是因为钱赚的太轻松了吧。

[yazoox]

更好奇的是，你们公司做啥产品？客户都是什么类型的？居然业务还能够蒸蒸日上。
真心请教，求分享更多的能分享的细节。

[BeyondBouds]

一样，公司就我开发时测一下，上线前产品点几下，完事...
刚开始我还写下关键部分的单元测试，后来，去特么的吧，写不写一个样...
app 日活 1w5 浮动，bugly 统计日崩溃率在 0.01%～ 0.05%之间，就这样吧....
也有过疏忽导致必崩的 bug ，紧急发版完事，公司也挺宽容，不追究

[wzy44944]

感觉两条阻力都不成立，可以继续说服老板，先招一个测试开发，算开发序列，梳理测试流程，前期可以招几个外包测试，然后逐渐扩招正式员工或者开发转测开，组建测试部，一般公司的测试部都是这样开始的吧

[wdold]

说明你司有一颗向行业龙头看齐的心，学习微软谷歌去测试化，开发自测安排上

[Nich0la5]

一周发一次版这个大前提不改，怎么测都覆盖不全的

[iyobucuo]

https://www.cnblogs.com/wangcp-2014/p/11697850.html

[iyobucuo]

@iyobucuo #37 我公司的测试用这个测

[victorc]

经费不足，测试组给两个人的编制，1 个 leader ，1 个员工，把测试流程的框架搭起来

[saulshao]

我觉得第一步是要招一个测试进来，最好是比较资深的测试人员。
先把测试搞起来，如果不能全搞，就先搞一部分。
完全没有测试的软件，是会让所有人提心吊胆的。

[54xavier]

我们也没测试，都是开发自测，上线 bug 如果没造成损失就没问题，如果造成损失，需要签事故单，还好一般开发只用承担部分，并且一般都不多。入职半年多还没签过，希望别签。

[customer]

@qooweds 中肯的回答，第一次看到有人把白盒测试跟黑盒测试的成本放在明面上比较的

我们都明白问题丢给黑盒不合理，但是人力实在太便宜了

[yule111222]

开发自己测，测试驱动开发
不过，你得真学会了 TDD 再大规模推广，不要为了测试而测试，不然测试代码反而容易变成技术债

[Kumo31]

作为程序员，从技术角度来说，大家都希望有一个完善的流程和做出稳定的软件。但实际上，公司在测试上投入多少主要是看解决质量问题的成本和质量问题带来的损失之间如何平衡。当你们发现质量问题带来的损失远高于组建一个测试部门或改进流程的成本时，自然就会推进这个事情，就像 IC 设计中甚至还要做形式化验证一样

我们是做 infrastructure 的小公司，产品上跑着客户的上层应用和数据，小到几百 TB ，上到数十 PB 。对我们来说稳定性就是高于一切的，在开发之初会花费大精力先实现测试框架和模拟器，流程上也有很多的混沌测试。但对不少互联网业务的公司来说，几次质量问题带来的损失并不高，甚至解决质量问题的时间成本还会导致无法快速上线而损失大量收益，也就认为测试无关紧要了

[recot]

@iyobucuo 这是测试报告，还需要写自动化测试代码。

[GuLuDaDuiZhang]

老板觉得没必要，当前质量 ok 不影响营收，那质量这块保障就只好苦一苦研发了

或者找些理由继续劝说老板，让老板相信有测试可以直接或间接的给公司营收带来提升，前期可以小成本先找外包验证效果

我所知有正规测试流程的基本都是 toB 的业务，而且这类业务测试团队规模还都挺大的，主要原因就是这类产品定制版本多迭代多，问题也就多了，光靠研发人力兜不住，而且客户对稳定性要求高，中标签单前客户老是刷到问题没服务好就会丢客户，toB 丢一个客户潜在损失可能就是百万甚至千万，出一次重大事故要赔钱还会把名声搞臭了，所以 toB 业务会倾向建立测试团队，把质量风险降低。

[HappyFox]

个人观点：老板自己搞不清对质量的要求，加再多测试也没用


以下是我个人在不熟悉你们公司业务和人员的情况下，建议的一些通用手段，排序是以少量测试、测试人效高、省钱这仨要求的综合以后的推荐程度，从高到低排的，仅供参考。

0 、流程分割
把提出需求、开发、发布这三部分拆开，保证开发阶段不会出现需求变更。
这个对你们产品和研发的老大要求挺高的，至少需求开发排期这种东西得合理，手底下多少人力心里有数。否则老板基础不牢，小兵地动山摇。
1 、代码门禁
保证代码合并主分支、上线这两个操作可感知、可复现、可优化。拒绝随意上线、夹带上线等事故高发操作。
可感知，指的是运维和研发组长知道手底下的人上了什么需求。
可复现，指的是上线脚本 or 流水线，这个对你们运维要求比较高，至少堡垒机、流水线、上线自动化脚本、回归脚本这些东西都得有。大公司有的自建、有的采购；小公司用云的话可以用配套的流水线；如果是自有服务器，推荐抽时间把脚本写好了一劳永逸。
可优化，指的是后续如果加了别的自动化流程，能结合到这两个流程中，通过代码门禁强制进行一些自动化检查
说句难听的，60%以上的问题都是那种“就稍微改了改”然后随意上线导致的。
2 、静态检查
规则在精不在多，保证每一条规则都执行。代码规则找公司中技术老板出(根据公司平均水平来吧)，直接封禁一些代码里的骚操作（ java 的话推荐阿里的那个规范挑点重点的），编写规则后放到代码门禁里。上线前检查出来问题，代码门禁怼回去不让上（当然，肯定要开发的时候自己多跑几次，千万不能上线的时候才跑第一遍！！！）。
3 、监控
找个时序数据库，代码里关键指标打点，然后自建个 grafana 监控大盘。根据你们的指标特点，最大、最小、波动率，这些基础的报警规则都配置上。平时大家轮流值班，值班的人业务需求少点，但得随时响应这些报警。上线的业务对应开发+值班同学一起跟，等指标平稳以后才算上线结束。
4 、测试+自动化
不同业务天差地别，自动化测试的效果也不一样。确认你们业务的特点
比如滴滴打车这种用户操作空间极少的，流量录制回放效益最高。用户操作界面复杂且经常变的，黑盒测试+操作录制工具效果更好。

[fantathat]

一周一迭代，而且还要改动老旧系统，我感觉是很容易出问题的。但是老板竟然不在乎，这说明一切都尽在他掌握之中。

[ruanimal]

没啥啊，招点贵的人，让他们自测。毕竟鹅厂也没有测试[doge]

[slert]

不用提老板操心，老板觉得靠用户测可以那就这样。