关于“开发把时间都花在编码上,还要写测试么?”的讨论 | IDCF

image.png

前 言

“如何保证在开发进度很紧张的状况下,开发人员投入足够的时间写测试用例,而不是把时间都花在编码上呢?” 这个问题是一位同事问的。编程

我一开始的反应如同正文中某位小伙伴的回答同样“你怎么知道是在编码,仍是在写BUG?”。可是仔细想一想,这应该属于比较广泛的问题,因此拿出来发在IDCF的群以及朋友圈。一时引起了众多讨论,看来这也是你们比较关注的共性问题。segmentfault

讨论很热闹,内容也都特别好,基本各种型各方面的观点也都比较全了,简单整理总结以下,咱们先看小伙伴们的讨论,而后再发表本身的见解。安全

这不是单点的问题,有必要耐心的把各方面的论点都看一下。一样的,每一个单点的回复都不会完整,也不必针对个别论点纠缠。微信

本人就不作过多评论了,欢迎你们留言进一步探讨~架构

从开发测试分工入手

(按开发作测试的程度排序)工具

  • 开发进度很紧张,不把时间用在代码上,还考虑测试的工做,是否是不太好?开发把测试活儿干了,那测试干啥?写代码么?
  • 测试负责质量监查。
  • 为啥必定要开发写测试用例呢?
  • 先人工自测下,后补doc不行么?
  • 无论进度是否紧张,开发都须要调试代码,都须要花时间定位缺陷,以及修复缺陷,和验证缺陷是否真的修复了。恰当的单元测试,能够很大程度上改善以上的时间。
  • 单元测试就是开发的一部分,排除出来算进度自己就是错误的。
  • 开发先自测,写不完换测试。
  • 聪明的孩子都会把编程的一部分时间用来作单元测试。
  • 测试用例要看是什么测试用例吧,例如单元测试就是开发写的,其余则是由测试人员编写的。
  • 单元测试不是开发写谁写,让测试把开发代码看完理解了再写么?
  • “据书上说,测试前移能极大缩短修复BUG时间,要不咱试试?”
  • TDD不是标准答案吗?
  • 结对编程,一个写功能,一个写测试。
  • 测试覆盖不到,CI挂掉,提不了PR。
  • 代码评审的时候必须提供对应的测试用例,不然代码不予合并到发布分支。
  • 没有测试用例,如何及时反馈代码的正确性?代码要的是数量,仍是质量?
  • 如何保证开发人员投入足够的时间写功能,而不是把时间花在写BUG上呢?
  • 这样不可能作到高质量,这种问题,提问的人本身也很清楚,没必要搭理。

以上建议不少都与测试的实践相关,包括门禁等,不过执行的是否到位,放一张茹炳晟老师分享的材料供自检~单元测试

image.png

从组织和流程入手

  • 产品生命周期阶段而定,若是早期,或者产品自己生命周期就很短的,实际上是不是不必定要写那么多单测。开发能保证冒烟测试全经过,我以为就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年,咱们一同精进。

image

做者:IDCF社区 冬哥
相关文章
相关标签/搜索