依據下載檔案-軟體測試原理,PDF檔第七頁上方投影片,建議缺陷改善能提前,最好是一邊開發功能的同時,一邊進行缺陷的改善以降低風險。

個人依實際測試專案,寫出若產品邊開發邊進行測試所會造成的影響,提供參考!
(1)一邊開發一邊測試,會導致工程師仍將焦點專注在改功能上,而delay fix defects時間
(2)fix defects時間一旦被delay,會導致測試員老是看到相同的問題,而沒測試價值
(3)有些未顯現的defects是隱含在尚未fix defects裡
(4)由於以上因素,會導致整個測試時程拉長

故建議最好將功能完成或者重要功能先完成再進測試,若功能實在太龐大,真的無法如期完成,則QA這裡可先安排單項個別測試,比方先進行相容性測試->重要功能測試->Performance測試->stress測試->規格及品質測試->功能測試->其它測試...,也就是個個擊破法,目的都是希望能省下測試期盤旋在某功能或等待的時間

在 RD 跟 QA 討論 : "只剩 20% 功能未完成, 能否開始進入測試階段, 先測那已完成的 80% 功能" 時, 其評估標準不在於 QA 認為對未完成的產品所做的測試是否有效, 而在於開始測試, defects 開始累積後, RD 是否有時間跟著即時修復 defect.

若答案是 "否", RD 因為必須繼續完成那 20% 的功能, 而不能即時跟著修復 defects 的話, 則不能先進入測試階段, 否則 defects 數量一但累積到某個程度都不能去修復, 對整個測試期間將產生巨大的影響.

　　對於這個問題的看法，我基本上是支持Soyasu的說法。但是我是從工程管理的角度來看這件事。未完成的功能，後續再加進來，對已經測試後的functions會不會有影響，其實是很難說的，就算是區分成數個builds的漸增式開發方法，其實還是免不了要做regression test，當然，如果迴歸測試的流程自動化了，可能另當別論，但這個成本是非常高的，因為，當迴歸測試發生問題時，可能又要想之前的測試到底對不對，是不是有必要修改自動化的測試程序，或是重新思考測試個案規格或測試設計規格。

　　基本上，很多軟體問題不見得只是個bug而已，有些部分可能得追溯到分析階段重做，更何況，以嚴謹的工程方法而言，就算是修bugs，在進入測試階段之前還有許多reviews工作要配合實施，所以期程會拖得很長，很少有發展團隊可以一邊發展一邊修bugs，然後還把專案期程趕上的，因為這可是高難度且高風險的，其產品的品質非常難控管。當然，這也就是美國伊利諾理工學院發展之SW-TMM測試成熟度模型，第一個要求(Level 2)，就是要把測試與發展的階段確實分清楚的原因之一。

　　如果開發時程很趕，而剩下的20%功能來不及開發的話，倒不如考慮將之獨立出來，把這20%的功能當作是下一個版本的新增軟體特徵(features)。這或許是另一種思考方法，但總結一句話，目標軟體沒有完成發展或告一段落，最好還是不要進行測試。否則，工程管理的成本會非常的高的。

----------------
引文:

一邊發展一邊測試，正如同林秘書長所說的，這是一個“高難度且高風險的”方式(approach)，正因如此，也確實“很少有發展團隊可以做到”。但是，正如同任何其它高風險的事一樣，其中隱藏著高利潤，具有成熟(技術)能力的人或組織，就可以降低其風險，而取得其高利潤。

其高難度在於它需要成熟的管理能力，再說的明白一點就是：第一要有定義良好的生命週期過程；第二要有週詳的計畫(專案計畫、品質保證計畫、型態管理計畫、測試計畫…)，測試計畫包含明確的測試策略；再來，最重要的是要有“良好的工作紀律”，就是一切按計畫行事。維持工作紀律最重要的機制，就是型態管理。倘若以上三件事沒有做好，就算您有很好的自動化工具也是枉然。如果能夠做到這三件事，再加上良好的工具，您就有能力去博這個高風險背後的高利潤。

這個高利潤就是：在生命週期的早期階段，發現設計上的重大缺陷(defect)，使您能用相對上極少的成本來改正這樣的缺陷。這相對的成本可能是1:100或者更高的支出(如果，在產品已完整開發出來之後才發現的話)。

這樣的利潤值不值得您來博，要靠您主觀的判斷。您有沒有能力博，要看您組織能力的成熟度。要如何改善您組織的成熟度，別無它途，就是確實的依照CMMI指出來的明路，一步一脚印的爬上它的階梯。注意，不是拿到它的證照，其實，它也沒什麼證照可拿。祝福您，早日學會『一邊發展一邊測試』這樣的方式。

軟體品質協會管理師 周茂松

轉貼公司TL 的心聲：(From A 同事)

這在我們公司,很難吧!

我也贊成開發完再進測試,不過很難,其實在K專案就是個例子,花費的成本實在很高,有的時候我都覺得,改一改,又會引發更多的bug,但是QA很難發現。所以,就有一種bug層出不窮的情況,蠻無力的!

個人認為Albert Chou所提到的三點成熟管理能力,的確是改善之道!

以下回應 A 同事:

如 F 所言:開發團隊與測試團隊應有Team Work的感覺,故您擔心改bug,QA很難發現,是否往後可以更明確告知QA,您改的bug大概會牽動哪些地方,若牽扯到Spec.改變,則可再另提測試重點。故改善方式便是:每週的測試會議,應是開發團隊與測試團隊要去互動,達成共識的會議! 辛苦您們了!

　　個人認為AlbertChou所提到的，是一個廣義的測試，也就是包括了靜態測試的部分，它包括了分析、審查等工作。而Soyasu所提到的「一邊開發一邊進行測試」則指的是動態測試的部分，也就是把軟體放在測試環境中執行，輸入一些測試個案，看軟體的實際行為及展現是否符合需求。所以兩者所談到的是不同的概念。

　　我們在談所謂將測試與發展階段明確地劃分，所指的其實就是進入動態測試前，應該將先前的設計實作工作完成，其意義在於發現錯誤時，能夠有效地分析問題之所在，這有助於問題的解決。

　　至於AlbertChou所提到的，我認為是另外一個層次的問題，當然其重點就在於業界最佳常規的導入，讓驗證與確認的工作協助開發人員在開發的前期就找出問題來、修改之，以降低專案的風險。當然，這個所謂的「高利潤」是值得去爭取的，因為，從整個品質成本的角度來看，在發展階段適度地實施驗證與確認的工作，絕對必要，而且是低成本的，因為它可以有效地降低後續可能發生的更大成本(去除Bugs、修改功能、修改流程、因為軟體錯誤可能對於開發商的商譽及商機造成的負面影響.....)。

　　軟體專案或產品開發真正的大風險，來自於不做驗證、確認、不做測試，或者這些工作做得不夠確實。但是，是否真的能為組織帶來「高利潤」？這是非常非常少見的，至少我還沒有看過有任何沒有做測試或測試不確實的產品，可以帶來高利潤的！因為，拜現在科技之賜，客戶都會運用網路論壇來做討論的，或者發表自己對特定產品的看法，藉此可以讓自己更了解產品的相關問題，因此，品質不好的產品，很容易就惡名傳千里了。

----------------
引文:

感謝Tyrone對於以上的討論更清楚的界定出靜態測試及動態測試,通常在靜態測試上,若產品規模太大,而又沒有使用自動化測試工具,往往PM對於Maintain文件會很頭痛,因為只要修改一個小小功能,任何一份文件可能牽涉到數十頁,甚至數百頁,而導致靜態測試後繼無力,繼而也關連到測試員的測試依循文件無參考價值。

另外,Tyrone在後一段所提及"沒有做測試或測試不確實產品"會籍由現在科技更加速透明公司不好的形象,這真是提醒大家一定要嚴格注重產品品質,共同維護公司形象,尤其是針對要走國際化的公司。

故產品若出問題,不單僅是QA的責任,應從需求開始,可依每個階段的輸出來知道哪個環節出問題,責任歸屬於誰,因為沒有任何一個人敢擔保"這個產品是零缺點",而QA只能用盡各種有效率、有計畫的方法,且在有限的資源下,替產品做最後把關!

故結論:產品品質不光僅是QA的責任。

再補充:測試員也不可以以測試數量的多寡來滿足自己工作成就感,成就感的來源應該來自團隊產品的優良產品品質。故測試很忌諱單打獨鬥。 與大家一起共勉之 ~

(感謝CSQA多位講師的協助觀念建立)

各位，我說的測試是包含靜態與動態測試兩部份，甚至可以說特別是在動態測試部份。其它的我先不談，就以工作紀律來說，它是絶對的前提。我只問：工作的順序是由管理層級(不論是專案經理或品質保證或任何其它管理層級)的人決定，還是任由RD的工程師決定？如果是由管理層級的人決定，那麼，怎麼會容許己經知道含有BUG的元件，不先立即移除那個(些)BUG，而讓RD的工程師繼續新增功能而放大那個(些)BUG的負面效果？難道這些管理層級的人員不知道那些BUG會被放大嗎？當然，這還是要看專案使用的生命週期模式與BUG的嚴重性而定。

這個問題很複雜，不是三言兩語就可以講清楚的。在此我要強調的只是：要能『一邊開發一邊做動態測試』，有其先決條件，不是測試人員想要這樣做，就能做到的。其實不管是不是『一邊開發一邊做動態測試』，其實動態測試要能有效地執行，其先決條件就是基本的管理工作要能有效地執行(也就是已建立起專案中的工作秩序)。個人以為，這也就是為什麼CMMI要把驗證與確認這兩個PA放在Level 3，而Level 2裡面的PA都是與管理有關的項目。

願我這樣的說明，能對您們有幫助。

　　我覺得這個部分可能真的要界定得很清楚才行，因為軟體測試的層次愈高時，想要做到一邊開發一邊做動態測試，其可能性應該是愈小的。所謂的測試層次，指的是愈趨近驗收測試(單元測試->整合測試->系統測試->驗收測試)。從V-Model的角度來看，在系統測試層次發現的問題可能是要回到需求分析階段去檢討與研析的，因為可能問題就是在需求分析階段INJECT到產品中的。

　　當然，我可以了解AlbertChou的想法，那應該說是一種境界，達到這個界境時，其實，根本不需要動態測試，軟體實作結束，就可以交付驗收了，曾經也有人這麼期待，但那真的是很難的！

----------------
引文:

軟體品質, 不是要求完美, 而是符合需求.

軟體公司大致上分三種業務型態, 第一種是客戶會直接要求須符合品質標準的, 例如承接政府/軍方標案, 或是像高鐵, 捷運局, 銀行, ...等等, 屬於大型資訊系統的案子, 這些案子, 營運後如果出錯, 常常會造成重大損失. 這些案子有特定客戶, 且客戶會在合約內要求品質標準, 所以軟體公司必須去做 ISO, CMMI 等, 才能符合投標的資格.

第二種是承接政府或民間機構的小型專案, 這些機構客戶並不會要求品質標準, 只要時間到了能交貨, 客戶願意驗收就好, 這種案子從 Sales, PM, RD, Artist, 到裝機人員, 通常幾個人就搞定.

第三種是沒有特定客戶的, 他的客戶是一般社會大眾, 生產的軟體是 On-The-Shelf 軟體, 放在通路架上, 靠行銷的方式, 吸引 End User 來購買. 因為沒有特定客戶, 沒有合約的束縛, 當然一切以搶上市時機為優先.

在所有的軟體公司裡面, 第二種跟第三種公司所佔的比例應該是比較多的. 而不論哪一種軟體公司, 從公司成立, 到達到相當程度的品質水準之間, 開發的成熟度是慢慢提升的, 如果是從中小型公司起家的話, 這個過程通常會長達數年以上.

對第一種公司來說, 有良好的開發及品質制度, 例如 ISO, CMMI 等, 以及確實按照制度實行, 是有必要的. 故他們不但管理層級重視品質制度, 連一般開發人員也都訓練成必須遵守品質標準. 但對第二種跟第三種公司來說, 這就不是必要的了. 他們的產品, 就算有 bug, 也不容易對客戶造成什麼實質損失, 大部分會反應成情緒問題. 而他們為了生存, 一切必須以成本作為優先考量, 所開發出來的東西, 只要能達到市場能接受的品質水準就可以了. 例如 Microsoft, 就提倡 Good enough software, 而不要求自己去開發 Perfect software.

但這也不是說第二三種公司, 就不會去重視品質. 就如同 tyrone 先生所說, 現在這個時代, 品質不好的軟體, 是不可能生存的. 所以這些公司的開發成熟度雖然還不到 CMMI 較高 Level 的程度, 但也都必須在求生存的過程中, 一步一步的覺醒, 漸漸提高開發品質.

在這些公司裡面, 為了搶交貨期限或上市時機, 到了開發後期, 一邊開發一邊測試的情形可能比比皆是, 雖然大多數情形可能最後不一定真的省到時間, 但這種情況仍然會持續發生, 原因無他, 因為他們公司的市場條件, 市場需求, 財力, 組織力, 人員素質等因素, 對應到軟體工程上的能力, 還沒有到達能夠避免這種情況發生的成熟度.

以 Soyasu 小姐在第一篇中所提的例子, 假設前一個案子因為一邊開發一邊測試, 而導致後期專案失控的話, QA 此時需要做的是, 一方面分析找出失控的原因, 提出具體的證據, 讓包含管理層級及開發人員都瞭解 "一邊開發一邊測試" 及 "開發完成再進入測試" 的利弊得失, 讓大家都能認同應該要開發完成再進入測試是比較好的, 並且進而推動落實開發前/中期的管理活動, 讓下一個專案不再發生必須一邊開發一邊測試的情況. 另一方面同時要找出目前測試流程中哪些地方可以改變, 以因應下一個專案如果因為時間壓力, 到後期仍然必須一邊開發一邊測試的話, 能夠減輕甚至避免失控的狀況再度發生.

身為專業的 QA 人員, 學習了開發流程標準, 學習了品質標準, 身處於不同開發成熟度的公司中, 最重要的責任, 就是善用所學的知識, 融入公司文化, 利用一次又一次的開發過程, 不斷找出流程, 方法, 及素質上的缺失, 不斷推動及增加修正及改善的活動, 讓你公司的開發及品質水準逐步提升, 不但提高了組織競爭力, 也提高了產品競爭力, 你的公司才有機會成長, 這是 QA 最大的貢獻.

這篇回應真是落落長, 非常感謝各位耐心看完, 並請不吝賜教.

　　就個人的經驗與所知，Donnie所謂的第一種業務，會有品質的要求，其實是因為這類大型的專案均有外國公司或外國顧問的介入，例如中華衛星一號計畫、軍方的大型武器系統研發或採購案、高鐵......。這些外國顧問會就品質部分提出要求與指導。

　　但是其他的案子，案子的成立與發展，多半是由某位承辦人獨立作業的，由於多數政府部門的承辦人員沒有經驗或缺乏相關的工程發展背景，因此，只要功能可以接受，就可以驗收。他們不是不要求品質，而是不知道該要求或如何要求品質，更沒有不愉快之品質經驗的累積，因應經驗教訓而改善系統或產品的籌獲管理能力。這才是真正的大問題。但這個狀況長久以來造成很大的負面影響，讓我們的資訊產業一直抬不起頭來。個人之前在國防部帶領專案時，明明已經定下許多的軟體品質要求，但是，承包商還是沒有辦法達到......，就算已經指導，帶著做還是一樣。承包商人員的論點常是「追求品質會影響到專案期程，以及工作的成本」，因此執行工作的人(不見得是公司高層授意)會錯把毒藥當解藥，不以好的方法工作，而用自己最認為最省力的方式工作，這種自認為最省力的方式通常是犧牲了品質，當然也就會犧牲產品成功的機會。

　　至於微軟所倡good enough software，而不是perfect software，我認為那是它的包袱太大，所以，以這種說法來圓自己的問題，否則微軟不需要做到「一個開發人員配兩個測試人員」，因為他們還是想把軟體品質做好的。

----------------
引文:

關於 good enough software 的部分, 個人找到一些資料, 可來印證 tyrone 所說微軟的包袱有多大.

這裡找到一份資料, 出處是 Windows - A Software Engineering Odyssey: http://www.seanm.ca/nt-software-eng.html

裡面有從 NT 3.1 到 Win2000 的開發及測試人員的人數

Product Dev Team Size Test Team Size
NT 3.1 200 140
NT 3.5 300 230
NT 3.51 450 325
NT 4.0 800 700
Win2k 1400 1700

另外這裡有比較近的資料
Windows Server 2003: The Road To Gold
Part Two: Developing Windows
http://www.winsupersite.com/reviews/winserver2k3_gold2.asp

到了 Windows Server 2003, 整個 Developer 人數更達到了 5000 人, 有超過 5 千萬行程式碼. 這種極端高複雜度的專案, 其 Configuration management, 尤其是 Source code control, 可以想見是嚴格得不得了的. 同時每一個 programmer 所產生的程式碼, 也必然要經過極為嚴謹的測試後, 才能允許進入 build, 否則只要某段程式碼有一點問題, 整合起來後, 它的影響一定會被放大不只數十數百倍, 到時可能整個 5000 人都要因此停頓下來, 所用來 debug 的資源耗費也必然相當可觀.

微軟的軟體規模達到這樣的程度, 如果不相對投入這麼高的品質管理成本的話, 也許只要有一點點地方出錯, 就可能連 good enough software 都出不來了.

再補充說明一下，要做到這點其實並不難，它並不是高不可攀的境界。它是任何一個能夠落實軟體工程觀念的組織就可以做到的， CMMI Level 3 的程度是一定可以做到的。

首先，採用一個適當的生命週期模(譬如：RUP或UP)。其次，仔細地規劃，包括：專案中用幾個循環(Iteration)，四個階段中各佔幾個循環，每個循環的時間長度，系統要分幾個Build來建構，專案中對外做幾次發行(Release)，測試組與開發組之間的溝通方式與頻率… 等都要考慮清楚並記載於文件中，再來就是落實地去執行這個計畫。個人以為這樣就可以做到『一邊開發一邊測試』了。