Tester vs. SQA - 2/5 QI、QC與Tester

前一篇文章，我們透過以下這張「品質的發展與演進趨勢」來介紹品質的定義、和品質的演進。


在這一篇文章中，我們將進一步說明QI、QC，以及QI、QC在軟體業內應用QI、QC的情形。

我也將說明，為什麼我會說「僅執行軟體測試的水準，充其量只有40~50年代的水準」？

QI

是建立在「品質是檢查出來的」的精神上。QI又可分成兩個時期：生產者檢驗與檢驗員檢驗兩個時期。

一開始生產者除了要生產之外，還要負責檢驗。等到泰勒的科學管理理論興起，強調專業分功能之重要性和優點，檢驗工作就交給專業檢驗員。

換言之，生產者和檢查者是兩個不同的單位，由檢查者根據品質檢查標準的方法檢驗產品品質，然後將檢驗結果與品質標準加以比較，藉以判定產品是否為良品、或是否合格。

如果是良品，就在檢驗單上簽名，然後讓產品流到下一站去出貨；如果是不良品，就在異常單上簽名，不讓產品出貨，再通知生產部處理這些不良品。

當時的產品相對現在是簡單許多，因此只對成品進行檢驗，但檢驗有一些缺點：

1. 時間上太晚了。
   因為發現完成時，表示已經生產完成了，錯也錯了，只能選擇重新修改或是廢棄不用。
2. 浪廢物料。
   除了生產不合格的產品，某些檢驗係屬破壞性檢驗，當檢驗結束，產品也被破壞無法再使用，因此無法全數檢驗。
3. 浪廢時間。
   對低單價高數量的產品，每個產品都檢驗實在太不經濟了。

基於以上原因，為了能提前掌握品質，並以更經濟之方式瞭解品質現況，就促成統計在製程上之應用，進入統計品管階段。

QC

1924 年五月美國貝爾實驗室舒華特（Walter A. Shewhart）博士首先將統計應用在品管上，也發展出管制圖技術，但這些技術並未受到工業界廣泛地重視，究其原因有二：

一、工業界缺乏精通統計之人才，因為無法理解產業內所使用的統計方法，自然無法善加利用統計工具解決問題。二、當時的品質管理的觀念認為品質問題在工程（製程）上、而非管理上，因此認為只要改善生產技術，就能解決產品品質變異之問題。

一直到1939年，二戰開打，美國雖然宣布中立，但她深知總有一天也得加入歐洲或亞洲戰場，因此開始加緊武器及物資的生產，統計品管方法才獲得重視。美國國防部有感抽樣驗收之必要，遂邀集貝爾實驗室之專家訂定抽樣檢驗表，並訓練政府相關官員熟悉該表之使用方法。

1940 年12月，為了進一步推廣抽驗技術，美國國家標準學會（ANSI）提出「品質管制及管制圖資料分析指南」，作為美國作戰初期的產品抽樣標準，並推廣民間廠商也學習統計品管，統計品管這時才開始在全美各地普遍使用。

到了1945年，美國軍用標準MIL-STD-105D公佈，它是由哥倫比亞大學統計研究小組為美國海軍制定的抽樣檢驗表，除了是較早使用的調整型抽樣標準，也是應用最為廣泛的調整型抽樣標準。

1950 年夏，二次大戰結束後，美國品管專家戴明（Deming），應日本科技連盟（JUSE）之邀，赴日本講述統計品管，引起巨大迴響。

統計品管雖然對產品之品管助益甚大，但其應用範圍僅限於生產系統內部，即自進料檢驗起、至成品出廠檢驗止。雖已可達到部份事前管制之效果，但主要內容仍偏重檢驗，對於愈來愈精密的產品、與顧客要求愈來愈嚴苛之生產條件，逐漸無法應付，品質保証階段於焉興起。

品質系統和軟體測試

在看完前面的QI、QC的介紹後，我們回過頭來看軟體業的「測試員（Tester）」制度。

從實務上來看，軟體業界廣泛使用的「測試員（Tester）」制度，與品質系統內所使用的「QI和QC」（統稱為「檢驗」）極為類似：

1. 以測試的階段來看，測試和檢驗都是在生產階段後驗證生產階段的作業品質。
2. 以測試的方法來看，測試和檢驗都是用已知的方法來對某項標準進行確認。

所以，我們通常會看到Tester會在軟體完成後、出貨前，依照Testcase去測試軟體品質，以了解軟體的品質。如果沒有問題就決定出貨；有問題則把問題交由研發單位解決，解決後再次經過測試，就決定是否可以出貨。

在這個過程中，統計的作用只為了追蹤這些被發現的問題的數量以確認問題是否被解決，至於解決的方法則由研發單位負責，Tester本身並不參與解決的過程，這是Tester運作方式的特徵。

比較之後

就會發現，軟體業界行之有年的「軟體測試」（Testing）觀念-「在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟體品質，並對其是否能滿足設計要求進行評估的過程。」只達到「品質是製造出來的」的QC階段。

換句話說，僅執行「軟體測試」充其量只有40~50年代的品質觀念水準。

關於Testing

它的一般作法是藉由設計使用/測試個案的方式來測試，而個案的來源通常來自於軟體（系統）開發的每個階段：

• 在客戶提出需求時
  確認客戶的特定需求
• 在分析客戶需求後
  確認客戶需求的Use Case
  
• 在設計軟體的過程
  確認程式已正確被Coding的單元測試
• 在測試過程中
  可能會發現Test Case以外的Bug
• 在客戶使用的過程中
  會發現一些Test Case以外的Bug，這些Bug會回頭成為開發和驗證過程中驗證的手段。

在以上說明的各個階段中，的確能透過Testing獲知研發完成的軟體（系統）的部份品質資訊。

單靠Testing

雖然能知道軟體品質，但卻無法保證軟體（系統）沒有軟體缺陷的，可是軟體業界卻不這麼認為！

如果不信？你可以從104人力銀行，用「Tester」作關鍵字，看看這些僱主（軟體開發業者）對Tester的工作要求，就能發現Tester的工作包含了那些項目。

以下是其中一個僱主對Tester的要求：

1. To test software releases during the product development.
   在開發階段測試發佈（Release）的軟體
2. To understand customer requirements and test plan from the test lead.
   從測試主管了解客戶需求和測試計畫
3. To use the test tools or scripts to execute the test plan per software/hardware release schedule.
   在每個軟體/硬體的發佈時程使用測試工具或scripts來執行測試計畫
4. To configure necessary hardware and operating environments as？needed to complete assigned testing. ？
   設定必要的硬體和作業環境，完成被分派的測試。
5. To prepare the test result and feedback to the test lead or software development team and submit bugs.
   準備測試結果和回饋給測試主管或軟體開發團隊和提出軟體缺陷（Bug）
6. To assist software/hardware development team to analyze bugs by collecting the debug information or log.
   藉由蒐集除錯資訊或記錄協助軟體/硬體開發團隊分析軟體缺陷

如果以品質觀念進一步檢視上述的工作項目，就會發現這個職務仍然維持傳統對QI、QC的要求，尚未進入下一個品質階段-品保（QA）。

小結

由上述對Tester的工作項目要求可知，目前台灣軟體業界對於「品質」還不夠進步。

那麼，到了下一個品質階段-品保（QA）時，SQA的工作又該如何進行？

下一篇文章我們將進一步的說明。

1. 晨晰統計部落格（問卷與統計的討論園地） - 《品質階段-品保（QA）》。