关于开发:关于开发把时间都花在编码上还要写测试么的讨论-IDCF

前 言

“如何保障在开发进度很缓和的状况下，开发人员投入足够的工夫写测试用例，而不是把工夫都花在编码上呢？” 这个问题是一位共事问的。

我一开始的反馈如同注释中某位小伙伴的答复一样“你怎么晓得是在编码，还是在写 BUG？”。然而认真想想，这应该属于比拟广泛的问题，所以拿进去发在 IDCF 的群以及朋友圈。一时引发了泛滥探讨，看来这也是大家比拟关注的共性问题。

探讨很冷落，内容也都特地好，根本各类型各方面的观点也都比拟全了，简略整顿总结如下，咱们先看小伙伴们的探讨，而后再发表本人的认识。

这不是单点的问题，有必要急躁的把各方面的论点都看一下。同样的，每个单点的回复都不会残缺，也没必要针对个别论点纠缠。

自己就不做过多评论了，欢送大家留言进一步探讨~

从开发测试分工动手

（按开发做测试的水平排序）

• 开发进度很缓和，不把工夫用在代码上，还思考测试的工作，是不是不太好？开发把测试活儿干了，那测试干啥？写代码么？
• 测试负责品质监查。
• 为啥肯定要开发写测试用例呢？
• 先人工自测下，后补 doc 不行么？

• 不论进度是否缓和，开发都须要调试代码，都须要花工夫定位缺点，以及修复缺点，和验证缺点是否真的修复了。失当的单元测试，能够很大水平上改善以上的工夫。
• 单元测试就是开发的一部分，排除进去算进度自身就是谬误的。
• 开发先自测，写不完换测试。
• 聪慧的孩子都会把编程的一部分工夫用来做单元测试。
• 测试用例要看是什么测试用例吧，例如单元测试就是开发写的，其余则是由测试人员编写的。
• 单元测试不是开发写谁写，让测试把开发代码看完了解了再写么？

• “据书上说，测试前移能极大缩短修复 BUG 工夫，要不咱试试？”
• TDD 不是标准答案吗？
• 结对编程，一个写性能，一个写测试。
• 测试笼罩不到，CI 挂掉，提不了 PR。
• 代码评审的时候必须提供对应的测试用例，否则代码不予合并到公布分支。

• 没有测试用例，如何及时反馈代码的正确性？代码要的是数量，还是品质？
• 如何保障开发人员投入足够的工夫写性能，而不是把工夫花在写 BUG 上呢？
• 这样不可能做到高质量，这种问题，发问的人本人也很分明，不用搭理。

以上倡议很多都与测试的实际相干，包含门禁等，不过执行的是否到位，放一张茹炳晟老师分享的资料供自检~

从组织和流程动手

• 产品生命周期阶段而定，如果晚期，或者产品自身生命周期就很短的，其实是不是不肯定要写那么多单测。开发能保障冒烟测试全通过，我感觉就 OK；能够考核开发的一次性提测通过率。冒烟之后，就是提测，测试同学测出 bug，开发修！如果 Bug 可控，其实 ok；如果 Bug 太多，减少冒烟比例。
• 如何在业务和工夫缓和的状况下，进行测试的安顿。要分两个维度来看，第一个是看产品的性质。如果产品自身是疾速迭代的例如 2C 端的，那么咱们就做疾速交付，能够通过灰度来做。换句话讲，让客户帮咱们做 2C 端的测试，就算有问题，对整个的影响和危险是可控范畴的；如果有问题，能够通过疾速上线新版本进行修复的。还有一种，是相似金融、航空航天、医疗等，对人的生命安全或金融平安有重大影响的，这种就不实用了，尽可能在研发环境里把问题找进去，要把资源和工夫做一个均衡。如果有危险，要在产品、测试、研发以及老板之间把这个危险裸露进去，发版的责任大家共担。
• 工夫紧是伪命题，不信你看看大家每天仍旧有工夫聊微信、刷微博。所以问题的外围在于：开发人员为什么非要写测试用例？对他们有什么益处？不写有什么损失？大家有这样的痛点和诉求吗？如果不能解答这个问题，那就没必要写，即便以政治工作强压，只能让大家怨气加深，各种糊弄，当形式主义去实现。
• 鸡贼点：或者能够在 DevOps 平台上减少一个相似门限提交的卡点，去尝试用工具扭转一下大家的行为作为尝试，看看成果再做决定。把怨气引到工具上，让工具唱红脸，人唱白脸，加以疏导，去摸索适宜的“平衡点”。
• 如果存在甩锅，阐明动到一方的利益了，那么就要反诘施行方，你晓得大家的外围 KPI 是什么么？各方做此事的利益共同点在哪里？不然为什么大家“浪费时间”陪你玩？搞不定这个问题，最初实施者本人就会变成“人心所向”的瓶颈点。
• 什么工具都打不通“部门墙”，唯有“人”！这个“人”要有足够的信息量，理解各角色、各部门的外围 KPI，当然获取信息的路径能够多方面，比方在酒桌、闲聊、八卦等各种形式。用“信息差”发明“影响力”，谁信息多，谁有主导权，而后找大家“利益共同点”去疏导大家共识，让做这件事的每个人都能从中播种实打实的益处，如此能力跨角色或跨 BU 的把大家凝聚在一起。

从需要和工夫动手

• 把测试也写在需要外面。
• 应该要解决需求方的焦虑，老板也有压力。如果工具、资源、流程不行那还好说，减少资源、改良工具和流程。作为执行方要管制老板的预期。
• 如果不能 delay 的话，就减 scope。
• 凭什么啊！减需要啊！
• 让开发进度别那么缓和。
• 我始终感觉麻利就是用来治理一些过于贪婪的老板或甲方的好工具。
• 双周迭代的话，开发编码工夫都紧凑，没工夫写用例，除非人员很短缺。
• 进度缓和，又要有足够工夫写测试？自身两个就是相悖的，看写代码人的集体能力了。
• 如果不能为开发团队争取来足够的工夫，又不违心砍性能，那就做完我的项目优先级最高，性能交付了再说。
• 需要人员说：啊，都急着要产量了，还测什么~

从零碎和绩效动手

• 我司没有测试人员，在麻利的模式下 BA 能及时赶出下个冲刺的需要就很 nice 了，开发人员须要承当测试的工作，然而没写测试用例，会先对着需要验收规范写开发思路，而后开发本人冒烟后让 BA 进入测试，BA 会小本本记录 SIT 阶段有多少 bug，UAT 阶段有多少 bug，以及上线后是否呈现生产环境 bug。考核的时候，以单个冲刺间开发人员的 bug 率进行交付品质打分。“打分是矮子里选高个儿么”？有一个红线 SIT：多少个 bug 以内，UAT 多少个 bug 以内。触碰红线的绩效就别想多好啦。
• 被其他人测出千行代码的 BUG 数目，间接和开发的奖金成反比，有点邪恶~
• 如果工夫线往前延长，计划多。如果只是基于以后工夫点，这个好难，放弃在测试用例上投过多工夫是一种抉择，只关注外围、频发业务。另外，尝试把测试引入救急，转变下原有形式。这样不是最佳计划，只是应急措施。
• 拉长工夫线，把上线回滚危险和单位上线时长做个回归剖析，应该能够算进去花多少精力实现测试 AI 化。
• 领会过单元测试的会被动去写，但也是笼罩局部要害办法；晋升覆盖率还是要靠绩效辅助。
• 如果一个公司始终属于紧急状态。那这个公司预计也活不短暂了。
• 向领导反馈，如果说现阶段软件品质要求不太高，反而交付工夫是最重要的状况下，能够暂且就义品质，前面再还债。
• 如果测试用例是交付物中必须的，那会有人写，毕竟是上线必须的条件，加班也得写啊。往往就是因为可有可无，反正不写也不影响零碎上线，那必定先紧着上线要做的事件实现啊，其余等当前再做，而后上线后感觉反正都上完了，其余做不做都一样。
• 就是纯正为了让开发写的话，不如就成心找他们麻烦，开发完代码之后鸡蛋挑骨头全算 BUG，博弈一下很快预计就写了 … 这个开发写，实质上相似编写实现的定义。
• 讲个故事，没过生产跳伞包的厂家合格率永远无奈到 100%，起初每次跳伞都带上几个厂家生产人员，而后，后果大家都晓得了，合格率马上 100%。
• 架构足够优良，这测试代码的工夫就不会花太多。业务代码也是一样，花太多工夫写业务代码，阐明架构优化还不够。
• 性能精简，构思好代码逻辑再入手。

从能力和认知动手

• 如果大家都认可写测试用例的价值，工夫缓和的时候，问题就变为如何高效写测试用例，否则是不是不宜在进度缓和的时候做强要求？
• 不是不给写测试的工夫，而是不给学习测试的工夫。
• 从后续发现的缺点看他们交给测试人员时的代码品质，怎么保证质量他们本人决定。个性团队外部小范畴沟通，应该还好，比拟真正的指标就在眼么前儿。另外，判断什么时候该写，该怎么写测试用例，这个能力自身的造就也很重要。有些时候感觉没用所以不违心写，其实是因为不会写胡写才没用。

总 结

这是一个系统性问题，任何单点的优化，都无奈解决全局的问题。

“如何保障在开发进度很缓和的状况下，开发人员投入足够的工夫写测试用例，而不是把工夫都花在编码上呢？”的问题，提问者也未必是不提倡开发写测试用例，问题所处的背景须要进一步探讨，才有可能给出相干倡议。

• “开发进度很缓和”：为什么会缓和？哪些时候不缓和？如何能够不缓和？
• “投入足够的工夫写测试用例”：目前投入多少工夫？都写哪些测试用例？你认为多少是正当的足够工夫？如果有足够的工夫，你感觉开发人员写哪些测试用例？为什么？
• “把工夫都花在编码上”：代码品质如何？如何掂量？呈现过哪些品质问题？回溯来看能够做哪些改良？
• 其余相干的问题：零碎是什么类型？缺点目前如何散布的？上线呈现缺点如何修复？会有哪些影响？

如此相干的问题之后，联合大伙的探讨，大略答案也就跃然纸上了。

你有什么话题特地想探讨的？留言给冬哥，2021 年，咱们一起精进。

作者：IDCF 社区 冬哥