當選擇一個商品的時候,我們常掛在嘴邊的一個詞就是“質量”,這是影響我們選擇的一個很重要的指標。這一篇我們就來探討一下什么是軟件的質量。當然,都是個人的一些觀點,不同意可以拍磚或者來探討。
質量這個詞用得太普遍以至于混亂,有時候它表示質量這個指標,有時候它隱含質量好的意思。而且不可避免的,好的質量常常和它的反面聯系在一起,就好像以前的“質量萬里行”,或者現在的3.15,列出的都是質量方面的問題,好像很少宣揚質量好的產品。所以很多時候,我們看質量是從反面(缺陷,或者質量不好的地方)來看的。在下面討論的時候我們也會用或正或反的例子來看。雖然是在探討軟件的質量,但是為了便于理解,可能也會舉別的產品的例子。
前一篇里面也提到,在傳統的關于軟件缺陷的定義中,是看實際做出來的產品是否和規格說明書(spec)一致,如果不一致那就是defect或者俗稱bug。如果只是從這個范圍來看,這個定義本身沒有問題,因為如果做出來的東西不是我們想要的,那當然不對。所以下面我們得出質量的第一個方面。
Quality scope #1: 實現了說明書上的功能
比如你下載了一個電影播放器,它宣稱可以支持MP4, MOV, RMVB, AVI格式,那么它必須可以正確播放這些格式的文件。這是一個很基本的要求,就像洗衣機要能洗衣服。如果實現這樣的基本功能出現的問題,那么用戶會非常生氣,覺得質量太差,根本不能用,直接卸載掉,或者要求退貨(商業產品)。
正因為這樣的后果很嚴重,所以在測試中,對于這樣的基本功能我們都會反復驗證。
OK, 如果說明書上說的功能都實現了,那么就是一款質量很好的產品了嗎? 實際上可能并非如此。那么差別在哪里呢?
Quality scope #2: 一些不言自明的要求
為什么說是不言自明呢。舉個例子, 還是洗衣機,客戶可能會說“我想買一臺洗衣機”。然后他買回去一臺,價格也還不錯?;厝ズ蟀l現確實能洗衣服(上面提到的基本功能實現了),但是有個問題,這個洗衣機洗一次衣服需要3個小時,而且洗的時候噪音很大。
洗衣機是很普遍的一個商品,用戶在一開始買的時候可能也不會問洗一次要多長時間或者噪音多少分貝。這并不代表他沒有這方面的標準,而是“不言自明”。 如果事先沒有說明,這可能會帶來一些糾紛,但是最終生產這樣的洗衣機的廠家一定是這些問題的受害者。因為大家都會知道這個牌子的洗衣服超慢,而且噪音大。而如果只按照第一個scope的要求,它可能是一個很合格的產品,而且或許衣服還洗得挺干凈的,通過了QA的測試。
我相信這一類的例子還可以舉出很多
筆記本: 發熱量比較小,不會太燙
殺毒軟件:占用系統資源不要太多,機器啟動也不會變得很慢
網上購物系統:響應時間不能太長
這方面的要求有很多,比如包括safety, performance,stability,impact to other software...
也正因為這一類的要求是“不言自明”的,所以開發的時候反倒容易被忽視。當然也可能是故意被忽視,因為技術和成本的原因,很多山寨產品就是如此吧。
比較好的做法是我們把這些方面的需求明確的列出來,并盡可能的進行量化。比如前面例子中涉及的時間和噪音問題,如果在內部的設計文檔中就有明確的要求,最終出來的產品就不會有這么大的問題。
關于這一類的需求,還有幾個特點。
1. 這方面的要求不容易確定,也不容易評估或者驗證。
比如performance,比單純的某個功能點,要復雜很多,有時候甚至什么是performance夠好或者很好都難以界定。所以這也要求產品的設計和開發人員對產品和用戶的需求有更輸入的理解,而不只是照著做。
2. 這方面的產品特性是難以被抄襲的。
國內的山寨能力想必大家都見識過,很多產品出來后很快就有了功能十分相近的仿制品。小到手機,大到汽車。iphone的山寨版長得很像哦,而且也可以全屏觸摸,multi-touch,而且不到1千塊。還有雙環的SUV,遠一點看就是BMW X5,之前一位美國同事來出差看到一輛還特意掏出手機拍照留戀,因為他是X5車主?,F實中,iphone在國內依然火爆,X5也還是很多人的dream car。因為有很多看不見的特性(比如performance)在它們和抄襲者之間劃清了明確的界限,質量高下立現。當然,差別也不只是這么提到的這些,還有其他,比如branding。
好吧,如果我們的產品連這些不言自明的要求也考慮到了,那么是不是就會被認為質量很好呢? 不一定。
Quality scope #3: 設計符合用戶的需求
在scope #1中,我們提到好的質量的最起碼的條件就是實現了宣稱的功能。那么引伸出另一個問題是,設計本身是合理的嗎?
如果我們把developer定位成實現所需要的功能的人,把QA定位成驗證這些功能是否正確實現了的人,那么這一部門的質量我們就沒有辦法覆蓋到。因為如果是這樣的定位,大家就不會去想,這樣做合理嗎?是用戶想要的嗎?做出來用戶會喜歡嗎? 反正我們只要按著spec做出來就好了。
這樣的例子其實也有很多,比如
1. by design,我們只支持IE瀏覽器。但是我們發現很多用戶都在使用Firefox和Chrome。
2. 我們的郵件歷史查找只支持按收件人,現實中有很多用戶也需要按發件人來查找
3. 如果用戶重裝系統的話,需要把曾經在老系統上配置的policy一條條重新配置,包括white list和black list。
4. 如果中途網絡斷掉了,用戶前面輸進去的東西下次聯網后要重新輸入。
類似的例子我們還可以舉出很多。這些問題有什么共同點呢,那就是用戶會抱怨我們的系統質量不夠好,會給售后服務部門提一個case過來,提出他們的合理(從他們的角度確實是)要求。
如果我們的軟件測試只停留在驗證功能的角度,這些問題都不是問題,因為直接被我們排除在工作范圍以外。但是最終這些問題都會被用戶遇到,而且形成一種印象,那就是我們的產品質量不夠好,特別是當競爭對手能夠做到的時候。這就會形成一個gap,我們內部測試的時候覺得質量很好很穩定,但是用戶還是不滿意。