軟件質(zhì)量問題很大程度上可以從其開發(fā)過程上表現(xiàn)出來。具體地說，軟件質(zhì)量是軟件符合明確敘述的功能和性能需求、文檔中明確描述的開發(fā)標準、以及所有專業(yè)開發(fā)的軟件都應具有的隱含特征的程度。概括地說，軟件質(zhì)量就是“軟件與明確的和隱含的定義的需求相一致的程度”。在缺乏有效項目管理的團隊中，下面的現(xiàn)象我相信是典型的。
一個功能第一次轉(zhuǎn)測的時候，測試人員能夠發(fā)現(xiàn)N個低級錯誤型的Bug。接著開發(fā)人員”改完”代碼后，測試人員進行回歸測試繼續(xù)發(fā)現(xiàn)N個Bug。這些Bug有些是第一輪測試中發(fā)現(xiàn)的Bug沒有修復正確或者完全的，而很大一部分可能是因修改之前的Bug而引入的新Bug。于是，這種現(xiàn)象不斷得在第三次、第四次……回歸測試中出現(xiàn)。
上面的現(xiàn)象就是典型的返工。返工不僅浪費了時間和人力，也是質(zhì)量問題的標志。而最后交付的功能還有若干Bug被發(fā)現(xiàn)。因為，測試人員漏測試了。
質(zhì)量問題的產(chǎn)生原因主要有兩個因素:個人的因素和項目管理的因素。人的因素主要有開發(fā)人員、測試人員的知識、能力和經(jīng)驗以及工作習慣。
比如，雖然敏捷開發(fā)一直強調(diào)測試先行。但是，仍然有很多開發(fā)人員習慣于先編碼后測試。更為不好的是，很多開發(fā)人員習慣于把所有代碼都”寫好”，然后集中對這些代碼進行測試。這樣做的結(jié)果往往是一個地方發(fā)現(xiàn)的問題往往在其它地方也存在。于是，他不得不重復得修改這些問題。這種情形不僅浪費了他們的寶貴時間。也往往使問題沒有被徹底修正。另外，很多沒有計算機專業(yè)背景的人被培訓機構以高薪為誘惑被培訓為測試人員。對于這些測試人員，當被測試的對象的技術性比較鮮明的時候，他們往往不知怎么測試。
但是，人的因素往往很難短期內(nèi)有所改善。所以，我將重點從項目管理的角度來分析。
返工和漏測試是軟件質(zhì)量的兩大問題。返工從項目管理的角度看，很大程度上是因為缺乏有效的流程控制。即，在一個功能轉(zhuǎn)測試人員進行測試前，沒有檢查其質(zhì)量是否滿足一定的要求——最低質(zhì)量要求。這一點，其實可以借鑒建筑工程中的材料驗收。比如，建設一棟大樓，其所需的鋼筋水泥等材料如果我們不在使用它們前檢查其質(zhì)量是否符合要求。那么，后面才發(fā)現(xiàn)它們的質(zhì)量問題則必然要返工。關于如何進行流程控制，以使被轉(zhuǎn)測的功能符合最低質(zhì)量要求，可以借鑒下Story演示這個具體實踐。感興趣的讀者可以借鑒下IBM developerWorks網(wǎng)站上的文章:
管理不是照著菜譜做菜。管理者必須要掌握一套質(zhì)量管理的方法，而非”拷貝”所謂優(yōu)秀實踐。學習優(yōu)秀實踐的意義在于掌握其背后所體現(xiàn)的方法與思想。文章中以這樣的一種思路分享了基于“經(jīng)驗過程控制”的質(zhì)量管理思想，并以作者的項目管理經(jīng)驗為基礎分享了另外一些提升項目質(zhì)量的一些具體實踐。當然，質(zhì)量問題是一個系統(tǒng)性的問題。那么，解決這個問題的方法也必然是要系統(tǒng)性。