測試宣言與未來的目標
這篇文章主要說明用一個簡單的檢核表，評估目前測試的環境、文化與政策，必且可以用來決定下一步，應該可以導入或是採取的行動。
測試宣言 |
目前這樣 | 未來應該要這應做 |
| 測試應該要確定解決商業問題 | ||
| 測試工作的優先順序應該要根據風險來決定並且提早找出重大風險。 | ||
| 專案測試的文件應該適當保存與版本控管。 | ||
| 產品出貨前或是出貨後找的瑕疵所造成的成本都加以衡量與紀錄。 | ||
| 測試個案的測試與軟體測試相互獨立運作。 | ||
| 專案建置實作完成之後，定期做持續改善的檢討 | ||
| 每一個專案結束後，都會定期的持續改善檢討整個開發與測試的流程。 | ||
| 測試文件包含測試計畫、測試條件、測試個案規格 | ||
| 對於測試、開發與經理應該都接受相關的測試訓練。 | ||
| 所有被開發團隊 (非測試團隊)發現的瑕疵應該都要被記錄下來。這些發現包含 Unit Testing 所發現的瑕疵，並且將這樣的瑕疵與發現的過程交接與測試團隊。 | ||
| 定義測試的範圍與責任 | ||
| 每個測試的階段定義測試週期的初始與結束條件。例如，沒有 P1/P2 bugs | ||
| 測試團隊應該定義測試的目標。 |
| 所有計畫測試目標瑕疵(P1/P2)應該都被解決，沒有解決的問題會通知使用者或是客戶。(i.e. known issue or readme) | ||
| 對於測試團隊提供適當的專業發展職涯、訓練、獎勵與認可。 | ||
| 對於測試文件並須註明測試的 “假設前提”。例如：假設客戶環境不使用 Windows 2000。 | ||
| 使用測試工具進行相關的測試。例如：資訊安全測試、效能測試等。 | ||
| 測試應該在早期開發的階段被妥善的計畫 | ||
| 所有的產品文件應該被適當的檢核。 | ||
| 測試計畫應該包含 rework的時間、驗證與環境準備的時間。 | ||
| 測試所有相關的文件與紀錄應該有版本控管的機制 | ||
| 測試計畫應該說明哪些是功能性測試、非功能性測試、那些不會被測試。 | ||
| 當使用實際資料做測試時，應該注意相關法規與個人隱私法律的規範。 | ||
| 測試環境應該要與上限環境一致。 |
| 回歸測試應該要在整個開發的週期中被妥善的計畫、設計、執行與文件化。 | ||
| 每個milestone 應該都要經過適當的回歸測試. | ||
| 對於經常使用的測試工具與自動化測試，應該要計畫適當的人力來做開發。 | ||
| 測試團隊應該要持續的提升測試的專業與技能。 | ||
| 不同的測試類型應該被清楚的定義並且與團隊說明。 | ||
| 錯誤與瑕疵的分類，嚴重程度與緊急程度應該被清楚的定義與執行。 | ||
| 開發團隊也會計劃相關的工作支持測試相關工具。( 例如：邀請測試團隊 Design Review) | ||
| 對於測試所使用到的詞彙有相關的定義與說明 | ||
| 測試會提供即時的測試報告結果給整個團隊知道，並且說明使用的測試技巧與工具。 | ||
| 提供相關的測試環境 Lab讓測試團隊可以建立模擬客戶的各式各樣的網路、伺服器、線上環境。 | ||
| 測試找到瑕疵之後提供足夠的資訊供研發團隊解決該問題 | ||
| 研發團隊會測試之前發現的瑕疵而非等待測試團隊測試結果 | ||
| 專案開始時會根據測試的結果追蹤專案執行的風險 |
接著就可以根據這個宣言，計畫接下來軟體品管的目標與執行行動為何?
所有的都要達到才是世界級的團隊嗎? No.
取決於當下專案的需求與目標。
畢竟最後軟體品管是要以達成 Business Objective 為考量。