David Ko的學習之旅

http://www.iiiedu.org.tw/ites/TCD.htm

對企業來說，軟體測試往往是軟體開發過程中，最繁瑣也是最重要的工作之一。其中測試個案開立技巧，更是決定的測試結果的成敗。因為好的測試個案能夠找出更 多錯誤，並且能以最小集合，來涵蓋最多範圍，以達到最佳投資報酬率。

何時測試可以停止

每次新版本要出貨時, 常常被詢問是否測試結束了? 品質是否有信心? 你依據的標準是甚麼? 

我想很多人都會覺得很難回答這個問題. 基本上, 可以根據以下五種狀況, 來決定是否測試可以結束.

1. 老闆說了算

Cross Browser Testing Tools 的介紹

Cross Browser Testing Tools–Reduce Browser Compatibility Testing Effort
http://www.softwaretestingstuff.com/2011/09/cross-browser-testing-toolsreduce.html

1. IE Tab:

自動化回歸測試的目的

回歸測試(regression testing)的目的, 是當程式有修改後, 檢查之前能運作的功能, 是否仍能無誤地被執行.

那自動化回歸測試的目的又是甚麼呢?

很多人覺得也是要確保之前的修改, 不會影響到原先的功能. 若是我們能將所有測試個案都自動化, 那就不用太多測試人員了, 因為之後都是測試程式在run, 測試人員就都可以休息了

根據殺蟲劑謬論(pesticide paradox), 你若是一再使用相同的殺蟲劑, 來消滅家中的害蟲. 時間一久, 蟲子就會有抗藥性, 之後對它們再也沒有用處了.

如何安排測試的優先順序

Tips to Prioritizing the tests | A way to achieve Time-boxing in testing
http://www.softwaretestingtimes.com/2010/05/tips-to-prioritizing-tests-way-to.html

一般測試人員最常遇到的問題, 就是要測試的東西太多, 但是時間太少. 作者在這這介紹一些經驗法則, 來處理這樣的狀況.

首先, 他提到要使用timebox的技巧, 他說這是可以使用在測試上面.

各種測試方法的問題

在 Exploratory Software Testig 一書中, James Whittaker在第二章中, 提到各種測試方法的不足:

Defect Preventation
從開發人員的角度來說, 他們希望藉由 design review, code review, static analysis tool, 和 unit test, 來增加軟體的品質.

但是作者覺得這些方法都有些根本的問題:
(1) 開發人員通常不是個好的測試人員

為什麼要記錄 bug 到 bug tracking system

最近有個新人, 我和他檢視完受測系統之後, 發現了一些問題. 這些問題有些很嚴重(功能尚未完成), 有些很單純(像是畫面上 layout 的問題, 或是錯誤訊息不是很正式). 因此我請這位新人去 submit bug.

隔了一天之後, 我雖然已經催促了好幾次, 可是新人都還沒有動作. 於是和他聊了一下, 他說他已經和開發人員談過了, 他已經知道了有這些問題, 所以不用再 submit 這些 bug 給他.

問他為什麼呢? 他說他已經跟他談過了, 如果再 submit bug 給他, 似乎是給他找麻煩, 給他增加不好的紀錄, 破壞了彼此之間的默契和情誼.

到此我開始明白了, 新人用的是開發人員的角度在思考, 這也是一般人不容易了解測試人員在甚麼的正常現象. 認為找 bug 是在給專案找麻煩, 是在挑開發人員的毛病, 有些事情大家講好就好, 幹嘛要記錄下來呢?

事實上, 紀錄 bug 到 bug tracking system是有些目的和幫助的:

如何當一個好的測試人員

8 Ways to be a Good Software Tester
http://www.testandtry.com/2009/04/14/8-ways-to-be-a-good-software-tester/

作者根據他七年測試人員的經驗, 給了我們以下的建議

1. 閱讀些有關軟體測試的東西
基本上, 這部分我覺得所有QA都缺乏的, 因為大部台灣的工程師都不懂測試, 身為測試人員需要更加強這方面的認識 

在測試人員心中, 何謂好的開發人員

7 Ways To Be Good Developer From Tester Point of View
http://www.testandtry.com/2009/04/29/7-ways-to-be-good-developer-from-tester-point-of-view/

作者在這篇文章中, 列出了七個項目, 指出怎樣的開發人員, 才是測試人員心中的好的RD.

1. 不要考驗你的測試人員
即使你和測試人員的關係不好, 也不要故意製造bug, 來考驗你測試人員的程度.

QA 該具備什麼要的能力? (3)

QA需要具備的第三個能力, 是需求分析.

需知道RD的工作通常是研究某種技術, 並且負責實作某些module or 功能.

他鑽的很深, 但是全面性可能不夠. 所謂全面性, 是指對於產品整體功能的了解度. 通常他只熟悉他所負責的部分, 其他部份的操作可能不太熟悉. 就算即使是他的部分, 若是加上對於環境的影響, 或是使用者可能遭遇的問題, 他可能也不見得很熟.

可是QA不同, 他需要測試大部分的功能, 或者說他需要組合不同功能來做測試. 並且他需要針對不同環境, 或是模擬使用者的環境或是行為. 因此他被要求的是廣度, 是全面性的了解.

因此QA會對於受測系統功能的了解度, 應用程度, 操控程度, 會比RD還要熟悉的多.

QA 該具備什麼要的能力? (2)

第二個我要提的是程式開發的能力.

有人會很好奇, 為何QA需要懂開發呢? 其實不然, 對於你要測試的東西, 你怎麼能不懂它怎麼做出來的呢?

若是你能懂軟體開發, 你會有以下好處:
1. 你可以用RD聽得懂的話, 來跟RD溝通. 不會讓RD你在是講哪國的外星文

QA 該具備什麼要的能力? (1)

每次在面試QA時, 很多人都不知道QA是什麼, 它需要什麼樣的能力. 所以每次我都要很多時間來一一解釋.

其實這也不能怪面試者, 軟體測試本來在台灣就不是顯學, 學校根本就不會教, 並且說不定連軟體工程的課都沒有開, 所以大家都不會.

其實這另一方面也顯示了台灣軟體界落後, 大多人只知道軟體開發裡, 只有寫程式和專案經理兩種角色, 事實上台灣業界大多也只有這兩種.

讓我們回歸正題, 首先, 對於QA所要具備的能力, 我第一要提當然是軟體測試.

很多人覺得測試很簡單, 人人可以做好軟體測試. 是這樣嗎? 撇開複雜的測試理論不說, 讓我們來看看一個簡單的範例, 看看是否測試向你說的這麼簡單.

Tester和Developer的比例應該要多少?

這個問題常常在我們公司被提起, 答案有很多1:1, 1:3, 可是都沒有明確的根據, 為什麼會得到這個答案

最近剛好隨手找到這份資料, 不但有文件還有投影片, 大家可以看一下
 
Estimating Tester to Developer Ratios (or Not), Kathy Iberle

五種方法來徹底改革QA(5)

5 ways to revolutionize your QA, Dr. James Whittaker
http://www.utest.com/webinars/5-ways-revolutionize-your-qa

Insight 5: Testing without innovation is a great way to lose talent

很多人認為測試就是一直反覆執行測試個案, 然後期望能找到bug. 把它想成很煩悶, 重複性很高的一種工作. 所以怪不得很少有人會想從事測試的工作, 這是因為大家都對測試的工作內容有錯誤的認知.

事實上, 作者認為測試有趣的地方是在於測試的戰略, 也就是決定什麼東西需要去測試, 以及如何組合不同功能和相關聯的環境狀況到測試個案中. 至於戰術部分, 像是執行測試個案, 記錄所找到的bug, 則算是比較沒那麼有趣的部份.

前100大的軟體測試Blog

Top 100 Software Testing Blogs
http://www.testingminded.com/2010/04/top-100-software-testing-blogs.html

作者整理了100個有名的software testing blog. 雖然我自認為看了很多blog, 不過前20名中的blog, 還是有1~2我從來沒看過.
# Site 
1 James Bach's Blog

五種方法來徹底改革QA(4)

5 ways to revolutionize your QA, Dr. James Whittaker
http://www.utest.com/webinars/5-ways-revolutionize-your-qa

Insight 4: Improving development is your top priority

作者在微軟工作時, 他會鼓勵測試人員要深入參與開發的過程. 像是找出程式碼中有問題的地方, 建議新的design patter或是code construct的方法.

他認為測試的目的是find and remove bugs. 所以不是只限去執行測試個案去找出bug, 來增加受測軟體的品質. 測試人員也要能利用別種方式來達到改進品質的目的.

五種方法來徹底改革QA(2)

5 ways to revolutionize your QA, Dr. James Whittaker
http://www.utest.com/webinars/5-ways-revolutionize-your-qa

Insight 2: Take your testing down a level from features to capabilities

在這段insight中, 我個人覺得作者所提的capability是這樣的觀念:

五種方法來徹底改革QA(1)

5 ways to revolutionize your QA, Dr. James Whittaker
http://www.utest.com/webinars/5-ways-revolutionize-your-qa

Insight 1: There are two types of code and they require different types of tests

通常測試自動化找不到bug時, 會做出一個誘人的結論: 這個產品的品質非常好

事實上是這樣嗎? 作者認為這是一個假象, Widnows Vista團隊就是這個假象的受害者