【code review V.S. pair programming】
網頁好讀版：https://tdd.best/blog/code-review-vs-pair-programming/
昨天大女兒早上去學校、下午去上美語、晚上去游泳，回來已經很累很晚了，一直猛打哈欠。在去游泳之前，已經讓她把學校作業先寫完了。
睡覺前收拾書包，太太檢查她新的國字（硬體字筆畫）作業寫得怎樣，因為是第一次練，當時寫作業又蠻趕時間的，又沒大人在旁一起看，所以蠻多內容寫得只是有形狀，但很多細節都不對。
我癱在按摩椅上，聽著太太跟女兒隔著餐桌坐在對面的對話。
—
太太：「你覺得你寫得跟上面的字有一樣嗎？」
女兒：「一樣啊！」
太太：「有嗎？你仔細看看」
女兒：「一樣啊...」
太太：「你那個字最後那邊勾了起來，上面的字有勾起來嗎？」
女兒：「我沒有勾起來啊...」
聽著這段對話，讓我想到一些軟體開發過程常見的場景....所以我正瞅著何時去摻一腳。
接著大概連續10次，女兒寫了字，太太只說著問題在哪，女兒擦掉，再寫一次，還是一樣的問題，不斷 repeat。
她一直在打哈欠，因為一天上三種課，從早到晚真的很累，之前有約定過要避免這樣上課，為了避免她在根本不知道怎麼寫才會「對」的無限循環中崩潰，我決定起身。
「將她們從 code review 的形式改成 pair programming」
—
我：「怎麼啦，唷，你開始練習寫國字啦」
女兒：（嘟著嘴巴，含著眼淚，沒力氣跟心情多說一句話，繼續把她寫的字擦掉）
我走到她的身後，伸出兩隻手環著她。
我：「我來看看是哪個字，哇，這筆畫也太特別了點，你這後面好像往上翹了」（我刻意不用勾的字眼，因為他們剛剛才吵過這件事）
我：「要不爸爸幫你用橡皮擦，你再寫一次我看看會不會就好了。」
擦掉之後，她再寫了一次，還是歪歪的。
我問她：「嗯，這邊還是有點問題，你覺得呢？要不要爸爸再幫你擦掉？」
她仍然沒講話的點點頭。（她處女座的完美主義）
我再擦掉之後，跟她說，爸爸握著你的手一起寫。
接著我就在後面握著她的手，告訴她另一隻手壓著本子，我們一起寫了那個字。（估計此時對面的老婆應該要很羨慕嫉妒渴望才是，但我無暇理會她的眼神，我現在要專心跟女兒寫作業）
結果我們一起寫的字還是歪七扭八。
我告訴她：「這真的不簡單，要不換爸爸試試寫寫看。」
我把字擦掉，寫了一遍。醜醜的，再擦掉，再寫一遍，還是不到位。我笑了笑：「這真的要寫漂亮沒那麼容易。」
女兒聽了，說著她要自己練習寫。我幫她擦掉之後，她照著上面的字描了一遍，再到格子裡練習一遍，終於通過媽媽的標準了。
昨晚的例子就到這邊終了。
—
很多目前軟體產品開發還蠻上軌道的客戶，他們現在的瓶頸都是在 code review. 要嘛 review 容易變成瓶頸、要嘛因為瓶頸導致時間緊迫而淪為橡皮圖章的形式，又或者只是看看 code diff 之間的差異、寫法有沒問題，只能指出寫得好不好，而無法確認寫得對不對。
「先落實 code review, 形成瓶頸之後 試著用 pair programming 解決」我經常這樣建議那些覺得該 code review 但覺得 pair 不實際或是有抗拒的團隊。
code review 就像稽核，常見有幾個特點：
1）稽核沒過，代表沒完成，不給過關的。
2）稽核人員跟開發人員的目標不完全一致，稽核人員更偏重於把關，尤其是品質。而開發人員最大壓力來自於時程。
3）稽核是落後指標，發現問題時間點越晚，修復成本越高。加上責任落在要扛時程的開發人員，往往來來回回壓力會越來越重，要嘛心情受影響，要嘛放掉品質受影響。
4）離線（非面對面）斷點式的往返（context switch)，大部分工程師傾向在線上留下 review comments, 而不是坐在一起面對面溝通，哪邊寫法有問題，了解作者的考量是什麼，我們怎麼達成一致的共識後交付。
對雙方來說，這樣多次斷點式往返，只依賴 comments 上的文字描述，會有許多誤解、中斷、等待的浪費。
這很像甲乙方的驗收方式，只是都是團隊內的工程師罷了。
我們整體最終目標（也該是共同目標）應該是：「在時程內有品質地交付我們兩有共識的程式碼。」
所以建議大家從這種傳統的線上 code diff review, 線上 comments, 來來回回後允許 merge 的形式，改成 reviewer 要 review 時跟作者約個時間，帶著電腦坐在一起，照著 reviewer 對需求的瞭解，以及他自己的思路，去看跟作者設計、寫法不一致的地方（經過了共同的 refinement, 驗收情境, planning part2，再從 test case 出發來看整體產品程式碼的設計），進行瞭解與討論，雙方持續有共識地一起修改調整，最後兩人一起完成這段 feature final commit，merge 回 trunk。
By the way, 我通常建議 reviewer 主導這個過程，用她的思路往下推進，而不是讓作者自己先描述作法跟思路，一來避免錨定效應，二來實務上看code的人不會聽到作者解釋和說明，得試著在沒有作者解說下，讀者能用最短時間、最少腦力、正確地理解程式碼的意圖。
兩人一起承擔時間、品質、對程式碼有共同理解的責任，只是這次擔任的角色不同而已。當下雙方都專心的完成這個共同的任務與目標。
先從 review 練習 pair, 熟悉了之後他們就會覺得那一開始就pair不就可以更早發現問題了嗎？
再搭配 scrum 那種非派工而是value-first 領工作的方式，再配合 #向上pair 的原則，團隊內 pair programming 是一件再正常不過的事了，通常也是效果最好，產出最高，但也最累的開發方式。
更別說 as a team 學習型組織，互補、增加公車指數、避免破窗、共同制定/調整規範、避免盲點、避免過度設計等等好處。
code 只要是一個人寫，沒別人看，永遠都是自己會改的那種 #養code自重 的形式，裡面真的會比「長麵筋」還藏污納垢的....
搞產品的只要那種永遠特定模組都只有特定人維護，基本上死期不遠，腐敗發臭速度超乎想像，拖越久越沒辦法，慎之慎之。
#敏捷人生
test case怎麼寫 在 Re: [請益] 軟體測試出路? - 看板Soft_Job 的推薦與評價
※ 引述《msc0953 (殺菌)》之銘言：
:: 測試，可分成手動測試和自動化測試。簡單來說，自動化測試就是把手動測試可以用程
: 式來代替。基本上，自動化測試不一定要使用 C++ 或是 Java，也可以使用一些腳本語
: 言，例如: Python, Javascript, 主要是測試有的時候要跑很久，當測試案例失敗後，
: 改程式碼可以很快地再跑一次測試。
: 推自動化測試要有老闆的支持，還要整個團隊對於產品的品質要有一定的要求。因為除了
: RD 要寫 Unit Test, Integrate Test, 還要有自動化的建置系統, 另外, RD 要寫出可被
: 測試的程式，QA 需要設計模組去驅動測試案例測試 RD 寫的程式，如果只是會看著測試
: 案例去測試 RD 寫出來的軟體，那替代性真的很高。
: 但是如果你有辦法看出測試案例上沒有的Bug，甚至可以給予 RD 沒想到解決方案，或是
: 能夠寫自動化測試處理原本要由人跑得的測試，那這就不是免洗的。這種QA非常靠經驗和
: 個人風格，也不是一般QA可以馬上達到的目標。
: 你可以朝向 QA Leader 的方向去走，主要是安排要怎樣測試軟體，測試範圍要怎樣開，那
: 些測試要做，先訓練自己組織的能力，也許再補充自己的專案知識，接PM的工作，也許會
: 比較適合。
針對自動化測試分享一些東西 ..
自動化測試的目的有幾個:
- 減少人力成本, 資源有效利用
- 找出潛在性問題
- 找出效能問題
- 執行回歸測試, 特別是維護階段, 或者客製化 (Custom Build) 的維護
- 規劃的好, 有所謂認證的價值, 公信力.
不過大部分, 做到後來都不知道在幹嘛 ....
很多案子, 我看到的問題經常是:
- 通常找不到什麼問題, 因為整個自動化程式都是問題
- 自動化測試不是用來找測試的, 是用來維護的
- Bug 都是自動化程式自己的問題, 沒有業績, 只有黑箱
- 為了自動而自動
- 沒有規劃, 所以不同的 QA/Tester 會用不同方式寫,
C/Python/Perl/Java/Shell ... 大亂鬥, 接手的很過癮 ...
- Test case 相依性太高, case 1 跑完後, case 2 就不能跑了,
因為環境爛掉了, 偏偏後面還有 2000 個要跑,
結果你已經下班了, 明天早上要給報告. 發現時已經是隔天進辦公室的時候了.
- Test script 本身沒有 quality. 所以那 2000 個不知道怎麼來的.
- 幾個 cycle/stage 之後, 自動化測試能跑就不錯了
- 通常寫 autotest 的人, 不知道啥叫做 source control ....
- 自動化測試好不容易可以跑了, 結果忘了換 build, 發現時已經是隔天早上.
- Developer 通常不想因為需要配合自動化, 而幫 QA/Tester 在 Code 加東西/開洞,
因為自己的東西都做不完了, 搞不好幫到最後變成自己的 orz ..
- Developer 有時間/願意配合了, 不過找到可以開動的 lib 又是一個大問題
(沒人維護了)
- QA/Tester 通常也沒啥 Coding skill, 也不知道怎麼跟 Developer 提出需求
而且 PM 也不知道那是做啥的, 所以 QA 就是找一些工具 (ex: selenium),
錄一錄, 然後只能跑幾次 ... 或者常常不知道為啥突然不能動了.
- GUI automation 看看就好, 不管是 Web/Window App/Mobile,
因為那些重點都在 **自動**, 但不是在 **測試流程**,
也不是在找問題, 製造的問題不少
- 大部份的 test tools 都只是用來安裝用的
- 自動化程式通常換一個環境就毀了
- 沒有完整的報表/Log, 無法缺陷分析, 更別提和 Issue tracking system,
or test management system 整合
- 自動化測試工具本身的品質堪慮 ... .(ex: RFT, 我不知道現在有沒好一點)
- 自動化測試不只是 test script 而已, 還包含自動部署, flow control/timer,
rework/rerun mechanism, schedule and job contorl, status, report interface
不過九成能動就不錯了, 剩下的都不知道是啥鬼.
- 自動化測試仰賴 PM/Develoer 推動 CI 相關流程, 同時把產品界面定義清楚.
產品界面就是 product name, version, revision, build type .... etc.
一個還好, 當同時有十幾個時候, 就不好玩了.
- 大部分自動化 '程式' 不會當作正式的 '程式', 所以九成九都是垃圾 code ...,
放到 source control 會被排擠.
- .... 不想列了 ...... orz.
我想說的是, 要做軟體自動化, 從頭就要跟 developer 同步進行,
最好是 pair programming + TDD,
developer 提供對應的 config, component key,
然後能夠有不同的 build type (debug, release) ...
- config 是未來自動部署時才有辦法設定在不同的環境;
- component key 指的是自動化工具要取得 UI object 的識別,
html 就是 id, iOS 是 label, andorid ... 我不想說了.
不然自動化程式裡就是一堆 n 度空間的 array ....
然後 developer 隨便調一個 UI, 自動化程式從此自動消失.
- PM 把 version role 定義好, CI 那邊才好串.
阿不然今天 1.3.e-3425, 明天變成 0.1.ab0c-1 ... (不要懷疑, 我真的看過)
- debug 可以讓程式或者 QA/Tester 調整一些參數, 增加測試的廣度與深度
- developer 在 code 寫的 log = input of autotest,
所以不要亂寫一些沒用的東西, 很難趴
# 自動化測試導入
兩個時間點:
- 新的案子, 剛開始. 最好是 prototype 出來的時間
- 案子已經在維護了, 不會有新的需求進來, 但是會修 bug, 最重要是這個案子賺錢.
進行中的案子不要導入自動化, 除非時間很多.
# 開發自動化工具 or Framework 的重點
市面上有很多工具, 不過很多都太過強調 '錄' 一些東西, 特別是 GUI 的,
錄 Web/錄手機/Window App ... 錄下來都不能看 ...
我覺得那只是行銷手法.
以下是我覺得 survey 或者自行開發一套自動化工具時的重點:
- Config / Data-driven
- Report
- Log 分析 / Pattern
- 圖形分析
- Timing control
- 測試流程與文件產出器
- 找物件的 libraries 有完整的封裝 (GUI automation 常出現的問題)
- 資源利用 / 分散式執行 (趕流行)
- 提供 libraries 讓 QA/Tester 也可以參與寫 script / debug
- 提供詳細的 debug 流程方法
- 和 Issue Tracking System / Test Management 整合
- lib 擴充性和文件產生工具
- 工具自己要有品質 (某大公司的 RFT .... )
# 測試角色的定義
- SDET:
- 做過 developer 最好.
- 寫自動化測試 Framework 或者研究老闆指定的工具
- 寫 plugin (像是針對 JMeter 寫 plugin)
- 維護/針對新功能提供 Libraries
- Document / Sample Code
- QA:
- 寫 test spec
- 利用自動化測試框架寫 test script / debug
- 執行寫好的 test script, 跑 overnight
- 回報/驗證爸個
- Tester: 手動執行
- 根據 QA 寫的 test spec 跑測試
- 回報/驗證爸個
# 自動化測試在專案裡的執行注意事項
- 寫 test script 本身也是一件 Coding 的工作,
一樣要 design, coding, unit test, code review, source control ..
要 Q (誰來 Q?)
- 十個 test script 可以一個人執行, 不用 config 一樣可以正常上下班;
2000 個 test script, 怎麼執行? config?
維護? report? (400M 的 log 怎麼分析啊啊阿啊啊啊啊)
這 2000 個要跑 20 次 (因為有 20 個客戶 QQ) ...
其中一個客戶要求每個 case 再跑時, 同時要跑 db access, 增加 concurrent;
另一個客戶說, 某一些 case 參數要調成 0800956956 ...
去把 2000 test script 叫出來重寫嗎? 然後要 concurrent 咧 ... 連 DB ...
對了, 20 客戶有不同的 build, 要記得換 build.
然後下一個 phase 就剩下 20 個可以跑, 因為改爛了 ...
然後你就跑了.
所以 config 的設計與彈性, 比你想像的還重要.
鮮少 autotest tool 會加強這塊的.
- test script 的內容重點在測試流程, 不是一堆找物件的 function ...
那些東西應該是 lib 要寫好, SDET 要搞定的
test script 重點是: 流程 驗證 記錄
- 寫 test script 之前, 要充分了解 requirement / spec
不過大部分 requirement / spec 都不充分 XDD
- 自動化可以和手動測試同步進行最好.
- 以前嚴重的 bug 要盡可能的放到 bucket, 有機會就自動化.
- 如果有 TDD, 那麼就把自動化測試考慮進去吧 ~~
- 如果是自行開發 test framework, 最好用 framework test self.
保證 framework 本身以及 libaries 都是 qualify.
- 文件 文件 文件
- z>b
寫的有點怨念, 大概沒回到原 po 的問題 XDD
BTW: 有興趣去看看一本書叫做 How google tests software, 作者也有一些怨念 XD
--
::: 喝咖啡 聊音樂 :::
https://rickmidi.blogspot.com/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.105.25
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1399479677.A.60D.html
基本上 "自動化程式" 也是程式, 除了要有 Coding 能力,
更重要有 "分析能力", 因為往往 developer 產出的東西,
複雜度會比原本 requirement / spec 更複雜,
我的經驗, 做自動化程式最好就是 developer,
或者要 train developer 測試的基礎概念.
也不見得, DHH 說 TDD 已死 ...
see: https://www.ithome.com.tw/news/87245
TDD 表示: over my dead body
經驗告訴我, TDD 可以讓大家 (Developer/QA/PM) 思考,
產品的樣子應該是什麼, 但這不表示會抹煞工程師的創造力.
garbage code 有很多原因:
* 歷史因素: 交接很多次了, 有時候為了滿足上面的要求, "暫時" 改幾行.
這個 "暫時" 是怎麼一回事? 不要問, 很恐怖.
* 不知道 test framework life cycle: 把 code 裡的 init value
當 config 用, 所以也是 "暫時" ...
* 把 "暫時" 的 commit 了 ...
* 為了某個特別的目的, 改掉整個流程 ... (通常改的人不會知道影響有多大)
因為他自己可以跑就好, 這也是一種 "暫時" ...
有在用 framework 寫產品的常會遇到, 某些時候一些寫法就是不正確,
但是大部份的 developer 不會去改 framework 的 source code,
因為他知道應該是自己使用錯誤, 或者對於 life cycle 不了解.
不過接 auto test 很多時候會直接跑去改 framework 的 code ... 然後 ..
You know ....
... <看更多>