你怎麼測試一個產品

記得以前有部電影，描述要測試保全系統，於是請來過去曾有偷竊經驗的人來檢驗其保全夠不夠縝密。

想想看，如果你自己做了一把菜刀，你要怎麼測試他？

首先，假定這把是切菜的刀，拿在手上試試重量以及重心、比例；接著，找來看是高麗菜、大白菜等青菜切切看；再來，找來一把蔥，切看看，看這把刀快不快........喔我掰不下去了，因為我不會做菜。實際上切蔥是不是用更輕巧的快刀呢？

是了，你要測試一個產品，你首先必須熟悉這個產品或是熟悉對應的需求（做菜、切菜）。
以我來看，熟悉產品，比較偏向於設計面，比較會是設計者的角度，或是專家角度；實際需求則是偏向消費者、使用者。

如果你設計了一把菜刀，你除了自己測試完畢以外，最好找來專家與一班使用者，來幫你進行測試。

換個例子，如果你設計了一個高科技產品，例如你開發了一款高規格的行車紀錄器，你除了在你的實驗室測試所有功能以外，你應該要做路測。而且，最好不是你或你的同事測，因為也許你們是該產品的專家，但你們可能不是開車的專家，也可能不了解路上跑的車有什麼樣的狀況。

結果，當你沒有作好路測時，產品在上市後，才發現機體過熱導致異常。當你百思不解，想說你在實驗室已做過壓力測試 - 連續錄影 24 小時都正常，為什麼爆出那麼多過熱異常的狀況！這就是你不了解原來上路後，太陽晒下來，車子會有多熱；原來開進雪隧，隧道內那麼熱；原來很多消費者，下車後不會把機子拔下來放陰涼處，所以就放在車子裡晒太陽，而原來車子裡的溫度會高到 50~70 度，遠高於機器正常工作溫度！

但是如果你還是沒辦法找來使用者幫你測試，你怎麼辦？
我會建議，測試時，你要假想你是一個找碴的人，你就是一心一意要證明該產品不能正常運作，所以你就得要試著在各種邊界點去驗證他。邊界點就好比機器工作溫度，他就是一個邊界點，雖然你說這機器正常工作溫度是 0~50 度，但實際上，在路上就是會遇上溫度高過 50 度，那怎麼辦？

找碴並試圖證明產品不能運作的模擬方式，是一個比較快速協助開發人員自己檢驗產品完整性的方式之一。

如何清楚的陳述問題

如果是在專門的測試專案裡工作，多半會學到一些測試方法與規範。這裡先保留不提工作上的測試相關工作。先來談平常生活中所遇到的問題。

試想，如果說你上週買了一台冷氣，用了不到一週，今天他突然不會運轉了，於是你撥電話給該公司客服，你會怎麼陳述問題？
「我的冷氣不會動了！」
是這樣的嗎？

其實有這樣客服與顧客之間的對話實際發生過：
「我的電視不能看了，我上週才剛買的！」顧客反應這麼說著
『昨天還能看嗎？』客服問道
「昨天還能看，今天就突然不能看了」
『可以說明一下是怎樣不能看嗎？』
「就我拿遙控器對著電視按電源鍵，但電視就沒反應啊！」
『可以確認一下遙控器是不是還有電嗎？或是你換一組新的電池看看，按遙控器時看上面的發送燈號有沒有亮。』
「我試過了，換新電池後，按遙控器時確認發送燈有亮，但電視就是沒反應！」
『不知道遙控器會不會摔壞了，這樣好了，你走到電視前，從電視的面板上按電源鍵看看！』
「等我一下喔....還是沒反應耶！」
『嗯....可以麻煩你看一下電視的插座有插上嗎？』
「我看看喔....啊沒有插上....」

類似這樣的交談流程會分常冗長，有些公司就會開始利用一些方法教導顧客先做基本的障礙排除，然後在顧客找客服支援前，會再適度的教導顧客要準備哪些資料，例如在產品說明書上就印好一個空白表單，讓顧客準備好問題的背景資訊，以便跟客服接洽時可以較有條理的反應問題。
以上面的例子，在說明書上的基本障礙排除就會先列上諸多檢查項目，諸如檢查電源插座、遙控器、電池等等。針對問題的描述則會請顧客描述故障的種類與細節，例如是開啟電源畫面完全是黑的，還是呈現雪花狀畫面。如果是呈現雪花狀畫面，是不是每個頻道都是如此，有無事先詢問有線電視業者訊號是否正常等等。

在開放的論壇上，也時常有網友詢問問題，類似那種「我的車子突然發不動了」、「我玩遊戲時感覺很卡」、「我的手機執行xx程式就會當掉」等等，千百種的問題，但很常見沒頭沒尾就冒出來一個問題，即使其他網友要協助也完全找不到下手處。

回過頭來看測試領域，通常在規範撰寫軟體錯誤報告時，會要求類似如下的資訊

作業系統版本與語言：
安裝的軟體清單與版本：
問題的重製步驟：
1.
2.
3.

產生的錯誤結果描述：
預期的正確結果描述：

其他附註：

但這是錯誤報告，如果現在是要與其他人溝通一個問題呢？其實我覺得原則是一樣的，當要反應一個問題，事先先要做背景的描述，然後針對問題儘可能的加以剖析，清楚的描述所發現的問題現象，以及敘述預期的正常結果。

好比說如果我想要對台北市政府反應交通問題，那麼也許我可以這麼說：

基隆路與忠孝東路交叉口，在路口西東南側，也就是沿基隆路往北然後右轉東向的忠孝東路這個方向，在上午九點半至十點之間，通常因為已過交通尖峰期，交通警察多半已在九點半之前便已撤離。因此這段時間便開始有很多計程車司機開始違規在路口紅線上，以及公車停靠區域，違規排班，導致公車進站、出站困難，進而造成交通堵塞。建議交警能夠加強此區段的違規取締，以改善交通紊亂狀況。

背景資訊是路段地點，重製步驟是地點加上時間，發現的問題是違規排班，預期的正常結果是加強取締並使交通紊亂獲得改善。

我發現有時有些人在溝通一個問題時，問題被轉了很多手，然後已我旁觀者來看我覺得問題已經失焦了，大概因為在轉手時，收到問題的人往往只花很短的時間看「重點」，然後又轉給下一個人，經常只附帶「客戶反應這個問題，麻煩你看一下」這類的訊息，這時這個信件本身已經很冗長了，如果加上處理人員沒有認真追蹤問題，或是反應問題時沒有提供足夠資訊，往往處理問題的人因為無法重製問題而草率結案。但問題並沒有解決，於是問題又再度透過層層關卡反應，到了最後處理的人員，這時可能已經過了一個月，他大概只有些許的印象，覺得這麼問題又來了，上次不是試過沒問題嗎，然後簡單試一下發現還是不能重製問題，又打了回票。

這樣的溝通就會顯得相當的浪費時間。我通常會建議當發現問題逐漸失焦時，最好是把問題的前因後果等細節重新描述一次，不花多少時間，卻可能讓問題可以快速回到焦點上並在短時間內獲得解決。

一個重點是，通常問題在被轉送時，訊息會逐步被短縮，所以有必要的話，最好每遇上一個新的處理人員，就跟他再描述一次問題。

V-Model 與軟體測試

且看軟體工程的其中一種開發模型 V-Model 各個開發階段與對應的測試工作的對應。

我覺得這個軟工模型還挺淺顯易懂的，特別是針對開發與測試的對應關係來看。

由 V-Model 的左半部來看，軟體的開發流程應當歷經需求分析、系統設計、架構設計、模組設計、然後進入軟體程式碼的撰寫。搭配右半部來看，當需求被進行分析並確認之後，緊接著應當要設計接受度測試。當系統設計確立後，應當進行系統測試設計，依此類推。

我在原始的 V-Model 概念圖上加上了對應的角色，例如需求分析應該是由系統分析師來進行，架構設計應該由架構設計師進行，依此類推。

相對應的，軟體模組的單元測試，應該是由軟體開發者進行，整合測試應該是由內部的 QA 進行，依此類推。

在這樣的流程與設計之下，每個階段會有不同的角色來進行測試、驗收，包含到了最後一個階段的接受度測試，通常是由客戶來進行最後的驗收，而其所應對照的是左半邊初期的需求規劃，逐一驗證交付的產品是否符合所有需求。

大體上 V-Model 雖是瀑布式模型的一種改進，但其實改的並不太多，而且以開發對應測試來說很清楚明暸。

過去我曾說我反對開發團隊必須遵照測試團隊的測試案例來進行交付前的測試，在 V-Model 裡可以有很好的解釋。開發團隊應該是在初期的單元/模組測試著手；有些大的開發團隊會另有專人負責測試，撰寫一些測試程式來輔助測試整合後的模組或系統，有些公司則是由開發團隊協助專責的測試團隊撰寫測試程式，然後交由測試團隊來進行；到了系統測試階段，原則上產品已經至少到了 beta 或是 RC 階段，此時有別於開發團隊中的測試組以外的專責測試團隊應該要對產品進行全功能測試。在上圖我暫時把這樣的團隊列為 B Team ，以有別於可能是隸屬於開發團隊之中的測試組。

讓開發部門參照與測試部門相同的測試案例進行品質測試

最近一個專案大概因為我們交付的成品送測後收到太多的錯誤回報，經分析後，有很多錯誤是顯而易見不應該發生的錯誤。原本 Lead Engineer 一再囑咐我們交付送測前必須參照測試部門使用的測試案例來確保交付品質，但是結果兩個開發團隊皆沒有完全施行。

實際上我認為讓開發團隊參照或是逐一依照與測試團隊相同的測試案例來進行交付品質的確認，基本上是本末導致的行為。原本開發團隊對於產品的架構、功能的侷限、不同功能之間的參數呼叫等有較多的資訊，開發團隊自有另外一套測試方法，好比說針對單一目的的程式碼或是函式進行單元測試、邊界值測試等等；測試團隊則是在產品成熟後，針對產品的各項功能 (features) 與各項界面進行測試，包含是以使用者的角度來進行測試，其測試的出發點與思考點是與開發團隊不一樣的，而為了有效的確保測試品質與測試涵蓋率，於是藉由撰寫明確的測試案例來加以輔助，因此這份測試案例使給測試團隊使用的。

實務上，有時某些測試項目需要重複性的建立相似的資料後才能加以測試，例如需要事先建立十筆甚至百筆用戶資料，然後進行搜尋測試，測試團隊會與開發團隊合作另行開發小的程式以匯入背景資料，來輔助實際想測試的搜尋功能。類似這樣的例子，在開發團隊身上的應用更多，例如要進行某項單元測試，於是另行編寫某小程式來加以輔助。

又或者舉例開發團隊要確保某日文化產品有確實日文化，沒有亂碼產生，則可能另行編寫小程式來掃描產品裡出現的所有字串其字元所屬的編碼區段，來加以判斷。

如今，如果要開發者照著測試團的的測試案例進行測試，例如要安裝好產品，開啟產品，然後逐一操作每一項功能、輸入資料、搜尋資料、刪除資料等等步驟，以確保產品的品質，這是說不過去的，不是不能做，而是搞錯各自應有的焦點了。理論上如果開發團隊果真把測試案例完整跑完，並且修正了所有發現的錯誤，然後交付測試團隊進行測試，那麼我們每次都可以得到零缺陷的測試報告，看似產品品質相當優良，但 stakeholders 大概沒多久之後就會考慮裁撤測試部門了。

總之，開發團隊交付的成品，其品質過低，所要採取的是不一樣的手段，該手段也許不會完美，但那也是為什麼我們需要將產品的品質把關交給最後一線的專業測試團隊為之的道理。

對台灣廠商產品品管的一些想法

沒有想要一竿子打翻一船人，僅僅是針對某些廠商、某些產品的品管的一些個人淺見。
最近換了一隻 PDA 手機，算是興奮吧，也算是啟用手機以來花最多錢入手的一次。該手機價格與功能比還算是相當不錯的，可惜的是總是有不少小瑕疵，例如某些狀況下效能低落、某些功能在某些組合下導致當機、某些功能在某些狀況下未如預期表現等等。

我不禁想到幾年前我到某大國際性軟體公司應徵產品品管工程師時，我曾很自豪很有自信的對面試官說了我對產品測試的其中一個看法，也許是略帶戲言，我說「產品測試者要本著我就是要驗證這個產品（軟體）不 work 的心態來進行測試」，背後的意義有很多層，諸如：

不要只用正常的方式去測試產品，例如帳號欄位只接受英文字母 12 個字元之內，你就偏要驗證非英文字母且超過 12 個字元會發生什麼事情

你永遠不知道真正的使用者可能會如何的「不正常」操作該軟體

你是在幫產品把關，不是對開發人員找碴

由於要證實這個產品或功能不 work ，你非得想盡各種可能的正常與不正常的操作方式來去驗證這個產品

舉個例子來說，如果有個功能就是做加法器，他可以做到 1 + 1 = 2 ，你不僅要測試輸入 1 + 1 ，你還得測試 0 + 1 ; 1 + 0 ; 0 + 0 ; 1 + (-1).......，而不是只驗證完 1+1 確實等於 2 就收工了。

不過很可惜的最後我並沒有進入那家公司，因素可能有很多，但真正的因素是什麼我就不得而知了。

我這隻 PDA 手機，製造商犯了個相當嚴重的疏失，在其新推出的 ROM 當中，原定是要修正某些軟體錯誤的，但是與那些錯誤無關的其他軟體功能，原本在前一版的 ROM 當中是可以正常運作的，到了新版的 ROM 當中卻相繼不能正常運作了。這是品管上的相當大疏失，為此不禁感到惋惜，諾大的公司，難道這樣的錯誤不打緊嗎，不影響公司聲譽嗎，不影響未來市場上對其產品的信賴度嗎？

只有一階段的測試，但沒有驗證測試的專案

原則上我認為這是個專案團隊在專案初始規劃時的一個嚴重錯誤。規劃人員礙於經費相當有限，於是只安排一個階段的測試工作，並未安排第二階段的驗證、回歸測試。

其實原本開發人員本來就應該針對自己交付的成品的品質負責（程式開發階段的單元測試，以及錯誤改正的基本驗證），例如嘗試重製該錯誤，確認錯誤不會再發生，才能結束該項錯誤修正的工作。但品管人員應再一次的為之前所記錄的產品瑕疵再次驗證，做最後把關動作。

當第二次的回歸測試被取消了，其實即使開發人員有做基本的驗證，但畢竟開發人員不是專業的品管測試人員，產品經理或是產品團隊甚至是開發人員在最後要將成品交付客戶時，為了為品管把關，結果還是要多花一些時間再次驗證產品品質，那麼事實上不做第二次的回歸測試，只是把成本轉嫁到產品團隊身上，而當產品團隊本身不具備品管與測試專業時，可能會花更多時間在做最後把關，這樣弄到最後，看似成本省了，但實際上團隊超時工作的成本卻被忽略了。

各行各業都有各自的專精，開發人員善於開發，不見得善於測試；同樣的，有擅長於測試的人員與團隊，通常當開發流程成熟後，將測試工作轉交給專業的測試團隊，對於整個專案來說是最省開銷的做法，同時又可兼顧品管。試想，讓你做你所不熟悉的領域的工作，例如讓一個程式開發人員來作測試，是不是通常會花費更多的時間，甚或是得不到理想預期的結果？

Doing L10N Testing, Asking If It's I18N Ready?

Still, some vendors are not aware of the localization industry, or maybe some vendors' employees are not actually familiar with that, but doing the tasks.

I saw some project team members including the PM and the testers are not aware what they are testing. They thought they are doing software L10N testing, but are they? And are they sure the software is I18N ready?

If you are doing L10N testing, please ask yourself first, do you think the software is I18N ready? Are you really very sure what you are asked to perform the testing is part of L10N testing?

Are you spending too much time on checking the functionalities are working fine or not in localized version? And do you discover many functional defects which are reproducible in more than one localized version or even the English version?

Testing all the possibilities?

4/26/2006

Have you ever planned to try to test all the possibilities and finally you surrendered?

When you are in high school, there is a lesson in mathematics class to teach you how to count the probability.
The lesson started with something like you need to pick up a red ball inside a black box.
The first thing you need to know is how many balls there, then you need to know how many red balls.
If there are 10 balls and only one red ball, then you will get the result that the probability to pick up a red ball is 1/10.

The lesson will then teach you how to count something more complex.
A similar example is to count the probability that you pick up a red ball and a blue ball from the black box.
If there is totally 10 balls inside the box, only 1 red ball and 1 blue ball. Then the probability is 1/10 * 1/9, which is 1/90.

In the real world, the reason it's so hard to list all the possibilities is due to we may not be able to find all the variables. In mathematics, you can, but in the real world, you can not.

A Sample Test Plan Structure

Below is a sample Test Plan structure which I created before for some project.

1. Background
2. Purpose of this Document
3. Reference
4. Features to be Tested
5. Features not to be Tested
6. Test Approach
7. Test Item Configurations
7.1 Rack Configuration
7.2 Platform Configurations for Each Testing Item
7.3 Environment Locale to be Tested
8. Resources
8.1 Human Resources
8.2 Hardware Resources
8.3 Software Resources
9. Test Cycle and Schedule
10. Risks
11. Assumptions
12. Test Entrance/Exit Criteria
12.1 Entrance Criteria
12.2 Exit Criteria
13. Defects Reporting
14. Contacts

What kinds of testing should be considered?

Type of Testing	Description
Black box testing	Not based on any knowledge of internal design or code. Tests are based on requirements and functionality.
White box testing	Based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions.
Unit testing	The most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.
Incremental integration testing	Continuous testing of an application as new functionality is added; requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers.
Integration testing	Testing of combined parts of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.
Functional testing	Black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.)
System testing	Black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.
End-to-end testing	similar to system testing; the 'macro' end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
Sanity testing or smoke testing	Typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or corrupting databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state. Smoke tests get their name from the electronics industry. The circuits are laid out on a bread board and power is applied. If anything starts smoking, there is a problem. In the software industry, smoke testing is a shallow and wide approach to the application. You test all areas of the application without getting too deep. This is also known as a Build Verification test or BVT.
Regression testing	Re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing.
Acceptance testing	Final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.
Load testing	Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.
Stress testing	Term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.
Performance testing	Term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.
Usability testing	Testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
Install/uninstall testing	Testing of full, partial, or upgrade install/uninstall processes.
Recovery testing	Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
Failover testing	typically used interchangeably with 'recovery testing'
Security testing	Testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.
Compatibility testing	Testing how well software performs in a particular hardware/software/operating system/network/etc. environment.
Exploratory testing	Often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.
Ad-hoc testing	Similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.
Context-driven testing	Testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life-critical medical equipment software would be completely different than that for a low-cost computer game.
User acceptance testing	Determining if software is satisfactory to an end-user or customer.
Comparison testing	Comparing software weaknesses and strengths to competing products.
Alpha testing	Testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.
Beta testing	Testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.
Mutation testing	a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources.