關于軟件質量的思考 - 什么是質量(2)

　　好吧，如果我們的產品連這些不言自明的要求也考慮到了，那么是不是就會被認為質量很好呢? 不一定。

　　Quality scope #3： 設計符合用戶的需求

　　在scope #1中，我們提到好的質量的最起碼的條件就是實現了宣稱的功能。那么引伸出另一個問題是，設計本身是合理的嗎?

　　如果我們把developer定位成實現所需要的功能的人，把QA定位成驗證這些功能是否正確實現了的人，那么這一部門的質量我們就沒有辦法覆蓋到。因為如果是這樣的定位，大家就不會去想，這樣做合理嗎?是用戶想要的嗎?做出來用戶會喜歡嗎? 反正我們只要按著spec做出來就好了。

　　這樣的例子其實也有很多，比如

　　1. by design，我們只支持IE瀏覽器。但是我們發現很多用戶都在使用Firefox和Chrome。

　　2. 我們的郵件歷史查找只支持按收件人，現實中有很多用戶也需要按發件人來查找

　　3. 如果用戶重裝系統的話，需要把曾經在老系統上配置的policy一條條重新配置，包括white list和black list。

　　4. 如果中途網絡斷掉了，用戶前面輸進去的東西下次聯網后要重新輸入。

　　類似的例子我們還可以舉出很多。這些問題有什么共同點呢，那就是用戶會抱怨我們的系統質量不夠好，會給售后服務部門提一個case過來，提出他們的合理(從他們的角度確實是)要求。

　　如果我們的軟件測試只停留在驗證功能的角度，這些問題都不是問題，因為直接被我們排除在工作范圍以外。但是最終這些問題都會被用戶遇到，而且形成一種印象，那就是我們的產品質量不夠好，特別是當競爭對手能夠做到的時候。這就會形成一個gap，我們內部測試的時候覺得質量很好很穩定，但是用戶還是不滿意。

　　要解決這樣的問題，可能有兩個方面的要求

　　1. 測試人員(其實也包括開發人員)應該更多的從用戶的角度來考慮問題。也就是常說的customer insight，從這個角度我們不是完全被動的按著spec走，而是可以challenge它，為什么做成這樣，至少要知道為什么。

　　2. 測試人員要往開發流程的更前面走，而不只是等到產品做出來了之后去裝起來驗證。那樣太晚了，而且修改的成本比早期要高很多。測試人員一開始就應該參與到產品的設計中，并且從用戶的角度給出自己的意見。當然，這一部分也依賴于domain knowledge和個人的經驗。

　　以上兩個方面，對測試人員來講，是挑戰，因為要求更高了，也是機會，因為工作更有value了。

　　到目前為止，看起來我們的質量范圍已經比較完整了? not yet。

　　Quality scope #4： 處理異常情況的能力

　　說到這個問題，還是舉個例子吧。很多人可能對nokia手機的抗摔能力印象深刻，自己遇到的或者聽朋友說的。常見的情節是這樣的，一不小心從桌子上，或者從樓梯上把手機摔了下來，然后蓋子摔開了，甚至電池也掉出來了，這時候心里拔涼的，但是抱著僥幸心理把它們重新裝到一起，按下開機鍵，everything is OK，然后很happy。這種故事的后續是很多人因此第二次，第三次稱為諾記的用戶。因為覺得他們的手機質量很好。

　　這個故事有趣的地方在于說明書上從來不會寫我們的手機從樓梯上摔下來不會有問題，廠家估計一般也不敢寫。從樓梯上把手機摔下來絕對是一個異常的情況，也不是產品針對的場景，嚴格來說摔了之后壞了也屬正常。但是反過來，如果這種異常的情況下，都沒有問題，就會讓人覺得質量很好。所以是一個質量加分的地方，也是branding build up的地方。比如你可以(以前?)不小心把水倒在Thinkpad的鍵盤上，也可以踢到macbook的電源線。

　　從軟件的角度，異常的情況也有很多，比如

　　1. 突然停電

　　2. 硬件故障

　　3. 操作系統故障

　　4. 網絡連接意外中斷

　　5. 系統資源(內存，硬盤，網絡端口等)耗盡

　　6. 用戶的誤操作

　　通常情況下，這些情況都不會發生，但是還是會發生(墨菲法則)的。如果只是一個PC上播放MP3的軟件，遇到上面的情況就出問題了，甚至不能恢復需要重裝，也許還是可以接受的，畢竟不是很重要的任務，而且也不常發生。但是如果是很重要的軟件系統，而且有著重要的數據，不能恢復就問題大了。

　　對于這一部分，我們都應該考慮到，不管是開發還是測試。在測試的過程中，我們也要盡量的去驗證。

原文轉自：http://blog.csdn.net/superqa/article/details/5672522