上周四，不得不對客戶新啟用的bug管理工具Redmine中的bug狀態進行驗證。當然Redmine其實是一個項目管理工具，bug管理只是它的一部分功能而已。我在驗證之前，是讓一個經驗不多的同事去驗證的，主要是因為Redmine是客戶的testmanager自定義了，我們發現之前的配置下某些狀態下不能修改bug的狀態了，或者說bug可選的狀態不對。所有有必要在客戶又重新調整后驗證一下，是否符合我們一般的要求。同事的工作經驗不多，估計又是忙著下班，著急的看了就畫了個流程圖，用郵件發給我且沒有標題。收到以后，我自己也看了看，自己創建了一個testbug，發現流程圖中出現的一個reopen狀態，在現在的配置下根本就沒有，我就不知道他是怎么畫的了，我知道的是之前有reopen的，但最新的是沒有的嘛。因此，我不得不重新研究。
說實話，我被氣的夠嗆。如果簡單的一個任務，作為測試每天都要接觸的問題，怎么就不能研究好了，我自己也畫了一個，發了郵件，發之前為了驗證我畫的流程圖是不是，找了一個開發來幫我一起看看，讓他看看在我不解釋的情況下能不能理解。其實工作很簡單，根據現有的配置，檢查在各個狀態下是否能流轉到想要的狀態去，不對的地方就提出來。為什么會做不好呢？同樣一個任務，我和他做的效果就完全不一樣。這個應該有那位同事去思考，而我卻得到了一個新的面試題。
面試題：
1、請列出你說知道的bug的狀態一般有哪些？
2、請根據你列出的狀態，畫出bug狀態的轉換流程圖？
3、請根據上述的流程圖，寫出或列出對該流程圖的用例
我覺得這是一個不錯的面試題。第一個問題比較基礎，但不容易答全了，bug的狀態很多，并且各個公司對狀態的定義可能會存在差別，但這種差別不影響回答這個問題。特別想提的是客戶在bug狀態中加了一個monitoring，我覺得很好，這是用來監控哪些不易產生，但有時常產生的bug，開發說改了，這樣的bug測試人員就很糾結，驗證的時候是沒有出現，但這能代表問題真的修改好了。所以在一定時間內做監控，是有必要的。
第二個問題能考察應聘者的綜合能力。是否仔細想過各狀態之間轉換的關系。是否能夠將理解的內容轉換成圖形。是否有足夠的耐心去做好事情。這基本和測試技能沒什么關系，重點在其他基本素質。
第三個題目，考測試用例編寫的思想。對于狀態轉換如何測試。這就是一個狀態機的測試。也可以用場景法（路徑法）測試。