從測試人員的角度，通常會覺得測試很重要，但是你的管理者，或者是其他開發人員是否也這樣覺得呢？往往答案是否定的。他們否定的原因可能有很多，並且也可能都很合理。但是為了讓測試工作能夠順利進行，需要試圖讓其他人覺得這件事情很重要，需要有適當的投入。
那要怎麼說服老闆呢？Guerric de Ternay[1]提出了幾個思考面向，大家可以參考一下：
- (1) 將你的想法和決策者關心的事情結合起來
老闆會關心什麼呢？不外乎就是賺錢、準時交付、和不要出大包。如果真的出大包，是否有方法能夠快速解決，並且代價是負擔得起的。
一般狀況下，我們在乎的是我們的技術、成就感、工作是否輕鬆方便。這個就和老闆想的不太有交集，你從這樣的角度去思考，或是去說服老闆，自然失敗率就很高。
例如：我們在規劃測試時程時，很多人會想要進行哪些測試，才能讓產品品質沒問題，每個地方都有測到，都不太會遺漏細節。導致這樣的時程就會蠻長的。
老闆要你做的規劃，是如何在有限時間內，交付出品質還可以，即使出包也能很快處理的產品。為了達到這個目的，你可能需要對要測的事情排出優先順序，重要的先測。時間到了剩下不重要的部分，如果出包了，殺傷力也不會這麼大。此外，可能需要找開發人員聊聊，是否有機制可以快速且容易退版(Rollback)，或是可以不用重啟系統就更新修復的部分。
所以，你要做的就是說明，你的測試規劃如何達到老闆的期待，或是減緩他所擔心的風險，如果你有招，自然老闆就會支持你。
- (2) 成為管理者信任的關鍵人物
如果有個人努力工作；遇到事情時不起鬨，會幫忙想如何處理；交代事情給他辦，他都可以處理的讓你放心。如果你有這樣的工作夥伴，你就會很放心，很信任他。
當你是老闆的放心的人，是他的自己的人，這時候你再提出哪些地方要做什麼測試，他會根據之前的經驗，你提的建議比較可以包容和接受，這樣要進行一些測試也比較容易。
- (3) 讓管理者對不做會感到恐懼
如果有整理系統發佈後，產生的Bug所帶來的損失或影響，把這些資訊給你主管參考，相信你的主管應該會感到害怕，不至於會隨意就讓系統發佈。就算要發佈，他也會想好備案，或是要求團隊要先做到什麼測試。
國內對於系統錯誤產生的影響，通常比較不會被報導，網路上的資訊不多，並且很快就被其他訊息掩蓋。但是如果你在那個行業待比較久，相信也會略有所聞。一般來說，對於金融業，像是銀行、金控、保險、證卷或期貨等等，或是大型的零售業，像是網路購物平台等等，這些行業的系統會比較嚴謹一點，因為他們只要出包，公司就會上報就會賠很多錢，他們就比較就會把測試當一回事。
國內這邊就有個類似之前CrowdStrike的案例：趨勢科技[2]在2005年4月22日，趨勢在日本的用戶電腦全當機，日本鐵道公司(JR)自動售票機賣不出票，新聞通訊社發不出稿，工廠也出不了貨，狀況十分嚴重。
後來內部調查發現，原因是為了抓新病毒，寫了一個新的病毒碼(Virus Pattern)，但測試不完全，導致電腦更新病毒碼時癱瘓了系統網路。
為此，趨勢股價連續一週，市值在一週內跌掉600億，日圓股價則在一個半月內從4000日圓，溜滑梯到3200日圓，一共跌了20％。
為了避免這樣的事情再度發生，趨勢科技之後在一個月內，打造一個病毒碼更新的測試自動化系統，要求所以產品線，所有語系和版本，在病毒碼發佈前都需要通過這樣的測試。
- (4) 團結同事支持你的想法
有時候只有你一個人這樣說，老闆可能比較不會重視，但是如果大家都這樣說的，他便會好好思考要如何處理。另外，如果你連同事都無法說服，無法把他們拉成同一個陣營，那你想說服管理者應該也是很難。
- (5) 讓數據說話先建立共同的認知
為什麼傳統開會常常無法運作得很好呢？通常，老闆會希望你直接講出結論，或者是講出某些事情背後的原因。可是，當大家如果背景不同，又彼此不知道對方的假設這時候，大家所說出來的結論通常是會有所偏頗的。
那可以怎麼溝通呢？我們可以來嘗試一下焦點討論法。它是一個根據ORID理論，所產生的集體討論的方法。ORID是一個有層次的討論過程， 從現狀開始，然後分享你的感受，接著解釋你這些反應的意義和重要性，最後才來做出決定。
O(Objective)客觀性：發生的事實、資訊、資料
R(Reflective)反映性：產生的情緒、感覺
I(Interpretive)詮釋性：賦予的價值、意義、目的、觀點、或暗示
D(Decisional)決定性：得到新的了解、決心、行為轉變、提出的新的問題
例如，博愛座這件事情，有時候你看到一個年輕人，大辣辣地坐在博愛座上面，你若是直接認為背後的原因是他們家教，然後採取的行動是貼文上Facebook來指責，這時候有可能是一場災難。
如果是ORID的做法，可能是會這樣進行的：
(O) 你是先了解她發生了什麼事： 或許你可能會得到，他昨天加班通宵沒睡。
(R) 知道他當下心情如何：現在很累想休息。
(I) 這時候, 你可能會解釋說他不太舒服，精神不好，坐在博愛座上也是剛好。
(D) 所採取的行動是安慰他，拍拍他肩膀說辛苦了。
因此，如果我們能夠依ORID的思考順序，先利用O提出一些問題，來幫助團隊了解目前客觀事實是什麼。例如：總共找出多少Bug，集中在哪些模組或是開發人員的身上，哪些Bug的類別都是哪些種類。
先建立出大家都認同的共識，無法反駁或是可以充分理解的事實，接著再說出大家對這件事情的感受到，分析背後原因，然後再推敲出行動方案，這樣管理者買單的機會就會增高。
- (6) 讓做測試的風險降低
管理者不是不知道品質很重要，但是為了讓品質變好，重構或是測試所帶來的代價，會導致專案的時程變長。另外，即使你重構，撰寫了測試自動化，或是進行了程式碼檢視，也可能無法保證品質就一定很好。
對管理者來說，他們知道這是要做，但是是否有比較簡單，或是安全的方式來進行。並且花錢只畫在刀口上面，只針對高風險的地方去處理。
在軟體測試中主要的風險大致有以下幾類：
- 調度不正確
專案評估錯誤以為這很簡單，導致一開始沒有配置好足夠資源。
以為誰誰誰可以勝任這個測試工作，或是他來得及來加入這個專案。
認為某個測試工具或是測試環境不重要，或是不需要，導致後面測試時間無法控制或是變長。
- 不斷增加或變動的客戶需求
需求在專案工作期間不斷改變，並且缺乏文件，或是對需求內容有效溝通和解釋。
- 完成的定義沒有規範
不知道何謂測試通過可以發佈，通過標準沒有定義。
每個開發里程碑沒有說明要完成哪些功能，以及如何確認。
- 人員流失
重要技術人員離開，沒有足夠的時間來替代。
- 生產力低
團隊人員缺乏經驗，缺乏積極性等。
沒有領域相關知識，沒有測試相關知識，不知如何使用工具或是建置測試環境。
接下來你需要有個風險處理的流程：
- 風險識別：找出可能的風險。
- 風險分析：分析它是什麼，發生機率多高，發生後會產生什麼影響。
- 解法腦力風暴：事前如何預防，發生後如何減緩或是修復，是否有簡易的解法。
- 持續追蹤：週期性檢視風險是否已經減緩，或是處理掉，是否有新的風險出來。
| 編號 | 風險說明 | 發生可能性 | 影響程度 | 減緩方案和追蹤 |
| 1 | 測試手機不夠 | 高 | 高 | [2024/10/3] 先確認主要支援的手機種類為何 像專案A調借 5 隻 Android 手機 [2024/10/20] 已向專案A借到5 支手機 目前每位測試人員已有5 組不同平台或版本的手機 |
| 2 | 部分測試人員不熟悉測試自動化開發 有30%測試人員不會撰寫自動化，其他測試人員撰寫自動化能力普通 | 中 | 低 | [2024/10/12] 開發人員負責針對高風險模組撰寫單元測試 端到端測試由開發人員規劃測試程式架構，並對主要流程撰寫1-2個範例，讓其餘測試人員可以參考 |
| 3 | …… |
參考文獻
[1] Convince Your Boss: 11 Tips to Make Them Say “Yes!” (Updated 2024)
[2] 商業周刊／殺毒女王七天蒸發170億的失敗學https://finance.ettoday.net/news/312735
發表迴響