關於「開發把時間都花在編碼上，還要寫測試麼？」的討論 | IDCF

前 言

「如何保證在開發進度很緊張的狀況下，開發人員投入足夠的時間寫測試用例，而不是把時間都花在編碼上呢？」 這個問題是一位同事問的。編程

我一開始的反應如同正文中某位小夥伴的回答同樣「你怎麼知道是在編碼，仍是在寫BUG？」。可是仔細想一想，這應該屬於比較廣泛的問題，因此拿出來發在IDCF的羣以及朋友圈。一時引起了衆多討論，看來這也是你們比較關注的共性問題。segmentfault

討論很熱鬧，內容也都特別好，基本各種型各方面的觀點也都比較全了，簡單整理總結以下，咱們先看小夥伴們的討論，而後再發表本身的見解。安全

這不是單點的問題，有必要耐心的把各方面的論點都看一下。一樣的，每一個單點的回覆都不會完整，也不必針對個別論點糾纏。微信

本人就不作過多評論了，歡迎你們留言進一步探討~架構

從開發測試分工入手

（按開發作測試的程度排序）工具

• 開發進度很緊張，不把時間用在代碼上，還考慮測試的工做，是否是不太好？開發把測試活兒幹了，那測試幹啥？寫代碼麼？
• 測試負責質量監查。
• 爲啥必定要開發寫測試用例呢？
• 先人工自測下，後補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社區 冬哥