適用全公司的軟體品管品質政策
建立世界級的軟體品管制度與團隊
感謝讀者仔細的閱讀關於品質指標 “到底目前軟體品質的狀況如何? 軟體品質指標” 並且在專案上做一些實踐。
下一個問題是針對全公司的軟體專案來說，有沒有一個一致性的軟體品質制度呢?
筆者幸運的公司從13年前加入小公司到現在跨國亞洲最大的軟體公司，
如果公司要制訂一個軟體品質制度可以讓所有專案導入執行，有沒有什麼建議?
每個專案都不相同
由於專案的複雜度，時間周期、團隊大小、屬性，Cloud, Desktop, Mobile..等都不相同，
因此說要有一個全部適用的品質制度是有些難度，但是筆者列出”大部分” (不是全部)會執行的軟體品質制度與活動。
希望藉由這些比較一致性的做法提供讀者一些方向。
軟體品質政策
軟體品質政策包含三大部分：
- 測試環境 (公司品質政策、測試工具)
- 測試流程 (專案執行中的測試流程)
- 測試團隊 (QA工程師)
可另外參考這篇：建立世界級的測試環境與團隊
1. 出貨的品質條件: No P1/P2
到底怎樣定一個全公司適用的品質指標? 整體公司來說會定意產品出貨的條件，這些條件其實琳瑯滿目。
最直覺簡單的就是：出貨時所有的 open defects 是否還有 P1/P2?
如果有就不能夠出貨!
這樣簡單的結論，相信接下來衍生有許多的討論與爭議。筆者也遇過許多不同的狀況。
假設在原本預定要出貨日的那天，遇到下列這些狀況：
- 如果只有一個 P1。但是這個 defect 很難 reproduce or 不太嚴重?
- 只有一個 P1 defect 但是卻是一個明顯的拼字錯誤?
- 有 10 P1 還有 5 P2 defects
- 有 2 個 P1 雖然沒有解決，但是有 workaround
- 沒有 P1/P2 open。但是卻還有 100 testing cases 沒有測完
每一種狀況都沒有完美的答案。當然，也沒有所謂完美的產品。
畢竟產品出貨後客戶的使用與回報的問題，很有可能跟開發過程中這些找到的問題或是這些已知的 P1/P2差異很大。
因此，比較簡單的概念是整個團隊努力，至少在研發過程中已知的 P1/P2 盡量在出貨前解決。
這樣的目標也成為產品出貨的品質目標。相對直覺也簡單。
下一個問題誰定義 P1 or P2 呢?
2. 制定共通的 defect workflow
所有的專案依循一定 defect work 。除此之外，對於每個 defect 定義 severity 與 priority 的標準。
特別強調 Severity 與 Priority 十分重要。而且必須全公司一致!
不可以專案 A使用 P1, P2, P3。專案B使用 P0 P1 P2。
這樣整個公司的專案就會有相同的語言。出貨時，是否有 P1/P2? 大家就會有相同的共識了解品質的狀況。
定義完後，通常這部分會透過一些工具來執行。例如 JIRA 等。
3. 測試計畫範本
https://en.wikipedia.org/wiki/Test_plan
舉一個曾經筆者執行的專為為例。這樣的Agenda 就會適用在其他所有的專案。
可另外參考這篇文章：軟體測試計畫範本
建立一個可以讓所有專案使用的測試計畫範本。
4. 測試個案
每個功能的測試要包含哪些內容? 這部分也可以制定一定的範本。
| Item | Test Area | Description and example |
| 1 | Task Oriented Test | Including a test scenario to complete a user scenario |
| 2 | Force Error Test (FET) | Input information or the environment state is out of definition. It is to force some error conditions to input the system. For example, create the disk full condition. Input character strings, though by default. |
| 3 | Boundary Test | 1. Input information is just the boundary value of Definition. For example, to input the index of A[]/B[] to be the boundary value. 2. To make A, B, C to be the boundary value of A, B, and C’s definition. For example, A=Max Int. |
| 4 | Volume Test | To have a volume of traffic or a volume of running time. For example, to run A+B=C function many many times to see if it still works fine without any problem, no memory leak and no file corruption. |
| 5 | Stress Test | To test under limited system resources.For example,
To see how stressed conditions our Aps can stand. |
| 6 | Performance Test | |
| 7 | Security/Permission Test/Privilege | |
| 8 | Compatibility Test | 1. Compatibility with previous version of the products, or related products.2. Compatibility with other Aps3. Compatibility with different variances of used Aps.For example, IE is ok, but how about Netscape? IE 5.5 is ok, but how about IE 6.0? |
| 9 | Company Standard | Install path? Logo? Registry? Serial number? DLL load location in memory? Version or copyright? |
| 10 | Buffer Overflow | |
| 11 | Language | Including I18N and L10N for G11N |
| 12 | Documentation | Release documents including GSG/ReadMe/Online help/WebHelp |
| 13 | Timing/Race condition | Any write after write, read after write, write after read conditions, or any timing related issues, especially under multi-threaded or multi-process environment or mechanism. |
儘管測試計畫與測試個案的範圍會因為專案的屬性有些調整，但是整體的品質與做法會趨近於一致也會有一定的基礎。
建立 QA團隊專業領域
讓QA團隊專業有努力的方向。QA專業領域有哪些呢? 參考這幾篇文章：
結論
所以公司的出貨品質指標就定義為 no P1/P2 open defects 這樣就好了嗎?
真正這個的精隨是團隊、管理階層等對過程中的品質活動有一定的認知，出貨當天沒有 P1/P2 open defects 表示：
- 公司整體團隊對於品質的思維有一致的認知。品質的政策、環境 、 測試工具、品管團隊專業等。
- defects 全部被適當的處理與評審。即使最後有 P1 open 也因為大家討論嚴重性後後決定 close 。
- 整個開發過程中經過品管測試流程。包含白箱測試、黑箱測試、文件檢驗、錯誤測試、相容性測試等。
- 開發過程中有許多的測試與 defects 被發現並且解決。
- 這些測試計畫與每個功能的測試個案等，都經過一定的計畫、審查與執行。
所以最後產品出貨那天， No P1/P2 大家的認知為: 在經過這些軟體測試品管程序後，根據目前的測試計畫與範圍，已知的 p1/p2都已經被處理。
因此，根據這樣的資訊與已知風險，我們決定將產品出貨。
而不是倒果為因，為了 no P1/P2 defects ，而將所有的 defects 都調成 P3。
這樣一來，產品到市場上，客戶的眼睛是雪亮的。市場自然會淘汰品質不好的產品，間接對公司的商譽也會受到影響。