這篇文章介紹了我花 12 小時參加的 CTFL 培訓，如果你正在考慮參加 CTFL 培訓，那這篇文章會回答你的問題。包括上課的費用、上課的時間、是否值得。
整篇文章會依照最常被問的先後觀點，切成不同兩個部份：
．是否需要參加 ISTQB CTFL 培訓？
．如何通過 ISTQB CTFL 測驗？
這篇文章是第一個部份，主要說明我蒐集到 ISTQB CTFL 培訓的資訊，與個人觀察。希望能提供給讀者，做為考慮參加 CTFL 培訓的參考。如果你考慮後決定自己讀 CTFL 講義和考古題也很好，那就請直接看第二個部份：如何通過 ISTQB CTFL 測驗？
2018/04/12
Something new or same old way 回應讀者：我該轉換跑道嗎？
最近有個讀者，大概是用 SQA 的關鍵字找到了我的部落格和 FB。他問我 QA 工作的前景，以及是否該轉換跑道？
我是在 FB 訊息回覆讀者的，所以我利用這篇文章，詳細說明對於想轉換到 QA 領域工作時應注意的事項。
我是在 FB 訊息回覆讀者的，所以我利用這篇文章，詳細說明對於想轉換到 QA 領域工作時應注意的事項。
2017/09/27
How a SW Tester Self-help 軟體測試員該怎麼自救？
這篇文章原文是「Tester該怎麼自救？」全部都是以我以軟體測試員的角色親身經歷多間公司的不同狀況後，所提出試行有效的多種策略，希望能提供新進的軟體測試員參考。
想像一下自己是個浮潛愛好者。
趁著四月的好天氣，和七個浮潛同好去鵝鑾鼻南方七星岩浮潛，想要探尋海底沈船。
一潛下去先發現海面水流和海底水流相反，當你發現不對勁想上升減壓時，卻遭遇強勁的北上洋流。
你想往岸邊游，卻發現自己被夾在詭譎多變的沿岸流與黑潮強勁洋流間，只能隨波逐流。
這個時候，你會怎麼做呢？
2015/02/13
合格的 Qualified Software Tester
我的朋友 David Ko 在 FB 上轉貼了一篇 yunmu.wgl 寫的《新时代的测试工程师》，裏面說：
不過，我覺得 yunmu.wgl 的觀點不夠完整，所以寫這篇文章回應 David Ko。只是在寫的過程又找到 David Ko 寫的這篇《如何找好的測試人員》，裏面也寫到 David Ko 找 Tester 的思維，所以我在這篇文章一併回應自己的想法。
簡單地說，我認為可以用三個抽象的面向：觀念(Concept)、領域知識(Domain Knowledge)、工具(Tool)，來建構不同產業的不同職位。
這三個面向中，我認為以觀念(Concept)最重要。但這個部份，是 yunmu.wgl 的論述中所欠缺，但 David Ko 沒有直接提到的。
且聽我娓娓道來。
...重新树立新时达的测试工程师形象，个人认为得做到以下几点：
1.写得了代码
2.抓得住bug
3.看得了产品
4.懂得了用户
不過，我覺得 yunmu.wgl 的觀點不夠完整，所以寫這篇文章回應 David Ko。只是在寫的過程又找到 David Ko 寫的這篇《如何找好的測試人員》，裏面也寫到 David Ko 找 Tester 的思維，所以我在這篇文章一併回應自己的想法。
簡單地說，我認為可以用三個抽象的面向：觀念(Concept)、領域知識(Domain Knowledge)、工具(Tool)，來建構不同產業的不同職位。
這三個面向中，我認為以觀念(Concept)最重要。但這個部份，是 yunmu.wgl 的論述中所欠缺，但 David Ko 沒有直接提到的。
且聽我娓娓道來。
2014/12/24
貓在鋼琴上昏倒了 Cat collapsed on the piano
這篇文章是我 2011 年4月寫的文章，因為要重新改版，所以現在改寫文章，加圖後重新發表。
「貓在鋼琴上昏倒了」，是一句二十年前的廣告詞。
整個廣告開始，就是某一件事，經由大家交頭接耳的傳播下去，傳到最後竟變成「貓在鋼琴上昏倒了 」。我猜廣告製作人也許是希望傳達：傳言的變動與可怕。
不過，這句話對我有其他的用途，我先賣個關子。
Photo by: Father's Cat's Christmas Photo
「貓在鋼琴上昏倒了」，是一句二十年前的廣告詞。
整個廣告開始，就是某一件事，經由大家交頭接耳的傳播下去，傳到最後竟變成「貓在鋼琴上昏倒了 」。我猜廣告製作人也許是希望傳達：傳言的變動與可怕。
不過，這句話對我有其他的用途，我先賣個關子。
Photo by: Father's Cat's Christmas Photo
2013/06/26
通達人的「老軟體測試包袱」解法 Resolved Testing Burden
這一篇文章是我投稿到 ZDNet 的《通達人的「老軟體測試包袱」解法》一文的原稿、加上補充後的版本。
喲哪桑在《產品歷史愈悠久，測試工作也愈多？》一文中，試圖回答讀者老軟體測試包袱的問題。
我雖然認同喲哪桑的解法，因為他的解法確實具體可行也能解決問題，但我提出了與喲哪桑不同的解法-「測試最小化」。
喲哪桑在《產品歷史愈悠久，測試工作也愈多？》一文中，試圖回答讀者老軟體測試包袱的問題。
我雖然認同喲哪桑的解法，因為他的解法確實具體可行也能解決問題，但我提出了與喲哪桑不同的解法-「測試最小化」。
2011/10/26
Tester該怎麼自救？
想像一下，自己是個浮潛愛好者。
這個時候，你會怎麼做呢？
趁著四月的好天氣，和七個同好去鵝鑾鼻南方七星岩浮潛，想要探尋海底沈船。
一潛下去卻發現海面水流和海底水流相反，當你發現不對勁想上升減壓時，卻遭遇強勁的北上洋流，想往岸邊游，卻發現自己被夾在詭譎多變的沿岸流與黑潮強勁洋流間，只能隨波逐流。
這個時候，你會怎麼做呢？
2011/10/13
上Introduction to CMMI for Development V1.3 課程
上周一連三天都去上Introduction to CMMI for Development V1.3 課程。
2011/03/28
SQA的職涯規畫--回應讀者W先生
讀者W先生寫了一封信問我關於SQA的職涯規畫。
因為讀者敘述的問題，其實普遍發生在台灣的軟體公司內，所以在徵求讀者的同意後，以文章的方式回答。
不過，我得先向W先先說「對不起」。
因為在以下的文章中，除了引用自己的文章外，並沒有提任何一個網站、書。因為我相信讀者在Google 的過程中，可能找到的資料會比我所列的更新、更多，所以我將分享的是自己實作後被驗證有效的方法。
因為讀者敘述的問題，其實普遍發生在台灣的軟體公司內，所以在徵求讀者的同意後，以文章的方式回答。
不過，我得先向W先先說「對不起」。
因為在以下的文章中，除了引用自己的文章外，並沒有提任何一個網站、書。因為我相信讀者在Google 的過程中，可能找到的資料會比我所列的更新、更多，所以我將分享的是自己實作後被驗證有效的方法。
2010/10/20
Defect Pattern實作
這一篇文章是我投稿到ZDNet的《Defect Pattern的實作》一文的原稿、加上補充後的版本。
筆者在《Tester vs. SQA - 5/ SQA思維與活動》一文中介紹了SQA的一系列活動，也在《軟體開發的「已病」和「未病」》中介紹了「已病」和「 未病」的概念。
在這篇文章中，筆者將進一步介紹融合「已病」觀念的Defect管理手法，藉由藉由不斷重覆此一PDCA循環的手法，即可有效提昇軟體品質。
筆者在《Tester vs. SQA - 5/ SQA思維與活動》一文中介紹了SQA的一系列活動，也在《軟體開發的「已病」和「未病」》中介紹了「已病」和「 未病」的概念。
在這篇文章中，筆者將進一步介紹融合「已病」觀念的Defect管理手法，藉由藉由不斷重覆此一PDCA循環的手法，即可有效提昇軟體品質。
2010/10/15
Tester vs. SQA - 5/5 SQA思維與活動
Tester vs. SQA - 5/ 思維與活動
這一篇文章是我投稿到ZDNet的《SQA怎麼做的實戰教學（上）、（下）》的原稿，該文標題經編輯修正。
在這一篇文章中，我們將進一步從上篇文章《Tester vs. SQA - 4/ 關係與差異》中的差異處，繼續說明SQA在軟體開發過程中的工作。
這一篇文章是我投稿到ZDNet的《SQA怎麼做的實戰教學（上）、（下）》的原稿，該文標題經編輯修正。
在這一篇文章中，我們將進一步從上篇文章《Tester vs. SQA - 4/ 關係與差異》中的差異處，繼續說明SQA在軟體開發過程中的工作。
2010/08/09
軟體開發的「已病」和「未病」
這一篇文章是我投稿到ZDNet的《軟體開發專案 最怕錯估情勢》一文的原稿。
--東漢．扁鵲 《黃帝八十一難經-七十七難》上說：
--東漢．扁鵲 《黃帝八十一難經-七十七難》上說：
經言上工治未病，中工治已病者，何謂也?然。所謂治未病者，見肝之病，則知肝當傳之與脾，故先實其脾氣，無令得受肝之邪，故曰治未病焉。中工治已病者，見肝之病，不曉相傳，但一心治肝，故曰治已病也。中醫理論中肝膽屬木，脾胃屬土，木剋土，當肝膽發生病症時，和脾胃也會有一定的關係。上等的醫生不直接去治肝而是先顧脾胃，不讓脾胃受肝膽牽連，所以稱為治未病；但中等的醫生，不知道肝膽和脾胃互相連結的道理，一昧的治肝，所以稱為治已發生的病症。
2009/12/28
Tester vs. SQA - 4/5 關係與差異
這一篇文章是我投稿到ZDNet的《軟體測試不等於客戶滿意》的原文。
當顧客拿到經過軟體測試員(Tester)反覆測試過的軟體，顧客是否就會滿意這樣的軟體品質？
根據筆者的經驗，顧客通常不滿意這樣的品質。
當顧客拿到經過軟體測試員(Tester)反覆測試過的軟體，顧客是否就會滿意這樣的軟體品質？
根據筆者的經驗，顧客通常不滿意這樣的品質。
2009/07/21
Tester vs. SQA - 3/5 SQA
前一篇文章，我們透過以下這張「品質的發展與演進趨勢」來介紹QI和QC。
在這一篇文章中，我們繼續使用這一張圖將進一步介紹QA，以及在軟體業內對於QA的期望。
在這一篇文章中，我們繼續使用這一張圖將進一步介紹QA，以及在軟體業內對於QA的期望。
2009/06/23
Tester vs. SQA - 2/5 QI、QC與Tester
前一篇文章，我們透過以下這張「品質的發展與演進趨勢」來介紹品質的定義、和品質的演進。
在這一篇文章中，我們將進一步說明QI、QC，以及QI、QC在軟體業內應用QI、QC的情形。
我也將說明，為什麼我會說「僅執行軟體測試的水準，充其量只有40~50年代的水準」？
在這一篇文章中，我們將進一步說明QI、QC，以及QI、QC在軟體業內應用QI、QC的情形。
我也將說明，為什麼我會說「僅執行軟體測試的水準，充其量只有40~50年代的水準」？
2009/05/07
沒有紀律，何來執行力？-回應Arith的文章
網友Arith在他的部落格Thinking in Arithmandar Way寫了這篇文章《讓開發部門參照與測試部門相同的測試案例進行品質測試》，全文主旨在說明他完全不能認同「開發團隊參照測試團隊的測試案例來進行交付前的品質確認」這件事，甚至認為這是「本末導致的行為」。
我看了之後，由於自己不認同Arith的某些觀點，所以在自己的部落格留下我的看法。
我看了之後，由於自己不認同Arith的某些觀點，所以在自己的部落格留下我的看法。
2009/04/27
Tester v.s. SQA - 1/5 從品質觀念談起
自從看了喲哪桑 Speaking的《Review vs. Inspection -- 亂談軟體工程的正名運動》一文後就一直想學喲哪桑，也寫一篇辦別Tester 與 S.Q.A.(Software Quality Assurance, 以下將簡稱SQA)的文章。
2008/11/01
「研發記錄簿」的二、三事 - 2/2 為什麼工作還是接不起來？
這篇文章是要回應網友MaoYang的文章《您還在使用「研發記錄簿」嗎?》。
不過，為了回答MaoYang的問題，我將回應分成兩篇文章：
這是第二篇，我將分別回答說明MaoYang文章內的多個問題，其實和「研發記錄簿」一點關係也沒有。
不過，為了回答MaoYang的問題，我將回應分成兩篇文章：
- 關於「研發記錄簿」
- 為什麼工作還是接不起來？
這是第二篇，我將分別回答說明MaoYang文章內的多個問題，其實和「研發記錄簿」一點關係也沒有。
2008/10/24
「研發記錄簿」的二、三事 - 1/2 關於「研發記錄簿」
這篇文章是要回應網友MaoYang的文章《您還在使用「研發記錄簿」嗎?》。
不過，為了回答MaoYang的問題，我將回應分成兩篇文章：
這是第一篇，我將說明我所知道的「研發記錄簿」。
不過，為了回答MaoYang的問題，我將回應分成兩篇文章：
- 關於「研發記錄簿」
- 為什麼工作還是接不起來？
這是第一篇，我將說明我所知道的「研發記錄簿」。
2008/09/11
Code是寫給誰看的？-4/4關於「程式原理」
這篇文章是要回應網友MaoYang的文章《讓程式碼像閱讀故事一樣容易》。
我在上一篇《Code是寫給誰看的？-3/4關於「團隊合作」》中，提到「團隊合作」是不可見、或大家根本沒有發現的重要東西。
如果某些Programer不懂團隊合作的重要性了，那至少也應該寫出正確、可讀性高、易維護的Code吧？但從和我配合的軟體部門主管口中知道，那並非事實。這也是我個人認為MaoYang的文章中背後所隱藏的最主要問題。
我在上一篇《Code是寫給誰看的？-3/4關於「團隊合作」》中，提到「團隊合作」是不可見、或大家根本沒有發現的重要東西。
如果某些Programer不懂團隊合作的重要性了，那至少也應該寫出正確、可讀性高、易維護的Code吧？但從和我配合的軟體部門主管口中知道，那並非事實。這也是我個人認為MaoYang的文章中背後所隱藏的最主要問題。
訂閱：
文章 (Atom)