David Ko的學習之旅

Google, 相信大家都知道的軟體公司, 他的能力是有目共睹的. 可是你知道他們推廣測試自動化嗎?
 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

因為極限編程 (eXtreme Programming) 和 DevOps 的出現, 測試自動化越來越受到大家的重視, 但是很多人雖然知道要做, 但是卻做不到. 常見的原因如下
 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

很多組織有分成手動測試人員和自動化測試人員.
 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(2) 人氣()

自動化測試要做到以下這樣是有點難度的
 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

前一陣子在 Facebook 上的 Test Corner 和 Scrum Community in Taiwan po 文, 想知道大家的想法為何.
 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(1) 人氣()

測試金字塔這個概念是由 Mike Cohn 所提出, 在敏捷測試圈很流行, 不過大家不太清楚他是什麼, 並且對它有很多誤解. 因此, 簡單整理了一下他的想法, 希望能對大家有幫助.
 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

   
Gojko Adzic 是眾所皆知的名作者. 他所撰寫的 impact mapping, specification by example (有中譯本), Fifty Quick Ideas To Improve Your Tests, 和 Fifty Quick Ideas To Improve Your User Stories, 在市場上很受到歡迎. 這次他在 Agile Singapore 2016 介紹測試自動化的未來, 真的很值得一聽. 

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

在 agile tour Taipei 2014 中, 我們花了很大的篇幅, 安排了兩個 Coding Dojo, 讓大家瞭解如何來學習 TDD 的方法. 雖然 coding dojo 是個有效的方法, 但是並不是每個團隊能這麼幸運, 能夠來參加這樣的訓練.
 
   

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(1) 人氣()

在敏捷開發中, 我們都知道要將功能切割, 每次做些小功能, 然後持續交付價值給客戶. 
因此當你在開發每個小功能時, 你會不斷進行以下事情:
1. 從主幹 check out 程式碼到分支
2. 開發團隊在分支進行開發
3. 小功能開發完後, 將分支程式, merge 回主幹
4. 在主幹進行測試
可是通常這樣在第四步時, 就會遇到一堆錯誤. 這是因為小功能還沒確認是否正確, 就和整個系統和起來測試, 將導致問題多多. 如果有很多小功能要放進來時, 這種情況就會更惡化. 
因此有些團隊可能會這樣做:
1. 從主幹 check out 程式碼到分支
2. 開發團隊在分支進行開發
3. 開發完畢在分支進行測試
4. 在分支測試通過, 將分支程式, merge 回主幹
5. 在主幹再進行測試
這樣做之後, 可以讓小功能測試比較穩定後, 再放到主幹來. 可是遇到多個小功能同時開發時, 還是會遇到你進來的東西會跟別人不和, 導致整個系統無法運作.
所以下一步你會在這樣改進:
1. 從主幹 check out 程式碼到分支
2. 開發團隊在分支進行開發
3. 開發完畢在分支進行測試
4. 把主幹的程式 merge 到分支
5. 把 merge 完後的分支程式進行測試
6. 將 merge 完後的分支程式, 再 merge 回主幹
7. 在主幹再進行測試
因此你先確認小功能是否運作正常; 然後將主幹的程式合併到分支後, 再確認是否正確; 最後合併到主幹後, 在做一次確認是否都正常. 
看起來到目前為止, 應該考慮的很周到. 
可是... 有多少人這樣做呢? 似乎很少, 為什麼正確的事情, 大家都不做呢? 因為這樣反覆進行的測試工作, 如果你沒有自動化, 你就會沒有空, 或者討厭去做這樣的事情, 導致大家就很少去做. 
有些人說沒問題, 我們會把測試自動化搞好, 這是小事. 於是他們就開始處理測試自動化的問題, 接著你又會發現到:
要能自動產生 build, 否則每次手動要花多時間
測試環境要自動準備好, 沒有乾淨的環境, 測試結果可能會有影響
每個小功能整合到主幹後, 有可能之後出問題, 要重新回上個版本, 這個事情若是手動做, 也是件崩潰的事情 
……
所以再做下去, 你會發現整件事情沒有你想像的單純, 若是沒有落實 continuous integration 或是 continuous delivery, 你永遠沒有機會達到 agile 所說的, 每個 iteration 持續交付價值給客戶. 你所有的, 將會是至少落後一個 iteration 的交付. 因為在 agile 中, 每個 iteration 測試和開發要花的代價不同, 測試的代價是隨著 iteration 的進行, 逐漸高升.

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(1) 人氣()

kojenchieh 發表在 痞客邦 留言(0) 人氣()

測試個案 80 % 被自動化? 續篇
有人問我, 如果這個 team 是一個模組的開發團隊, 是否和有 UI 的產品,對這句話有著不同的解釋.
是的, 兩者有著不同性質, 因此會有不同處理方式.
如果你是有 UI 的產品, 那 "80% 測試個案被自動化", 其實代表只是你有 80% 的case 被自動化, 跟品質好不好, 以及你是否涵蓋大多 scenario 沒有關係.
如果你是開發沒有 UI 的模組, 那你只有一種方式測試受測軟體: 寫測試程式. 在這種狀況下"測試個案 80 % 被自動化", 個人認為是
1. 以測試自動化為主力去做測試, 有少部分需要手動測試
2. 應該不只只有主要功能是自動化, 有些細部應該也是自動化測試
但 是要記得殺蟲劑謬論(pesticide paradox), 你若是一再使用相同的殺蟲劑, 來消滅家中的害蟲. 時間一久, 蟲子就會有抗藥性, 之後對它們再也沒有用處了. 測試也是這樣, 如果一直執行相同的個案, 你會誤以為程式都沒有 bug, 一切都很完美.
其實不管是 自動化或手動, 殺蟲劑謬論都是要注意的狀況. 這也是為什麼會有 exploratory testing的出現, 當你執行完自動化測試後, 快速利用exploratory testing 來補足前者的不足. 千萬不要認為測試自動化是萬能的, 否則你只是自己欺騙自己

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

測試個案 80 % 被自動化?
最近有位經理跟我提說, 某個團隊自動化做得很好, 有 80% 被自動化, 所以一下就可以確認產品有沒有問題, 測試完之後就可以出貨了
這是值得恭喜的一件事情. 他們做了不少自動化, 可以很快地確認某些功能是否正常.
但是讓我們進一步思考一下, "80% 被自動化" 這句話代表甚麼意思呢? 我個人認為應該是這樣:
1. 80% 測試個案被自動化
註: 如果你開的個案越少, 那代表其實也沒多少東西被自動化
2. 有些test scenario 有被測過
但是他並不代表
1. 他建立很超多測試個案, 並且有80 % 測試個案
2. 所有鉅細靡遺的 scenario 都被測到
3. 這 80% 的測試個案目前都可以運作(如果沒有天天執行的話)
4. 受測產品的品質很好
所以聽到 80 % 被自動化, 不用想得太多, 並且太多意義在這件事情上面.
註: 我並不否定開發這些測試自動化的辛苦, 這些都要花很多時間和精力去做. 只是經理們不要把這句話想得太多

(繼續閱讀...)

kojenchieh 發表在 痞客邦 留言(0) 人氣()