前言
鬼手系列文也許能提供適用 SaaS產品的 pre-sales, post-sales, FAE 的除錯情境。
軟硬體整合的解決方案在開發測試端面臨韌體/軟體/測試環境的排列組合問題，通常不會把主力放在所有的項目，只會針對新產品做單元測試，而整合性測試。即便產品推新版韌體，也可能導致公司軟體出包，原因是工程團隊通常針對單一產品單一功能做單元測試 (Unit test)，卻不會有團隊針對韌體版本與軟體版本做驗證。

"本文若有情節雷同，純屬巧合。"

Google SSO 的登入管道報錯

使用者在登入會遇到層層障礙，過程中 sign up, import users, SSO sign in, sign in as a guest 各種模式的 sign in 問題，可能只在單一版本、單一登入方式、單一帳號、單一平台 (APP或WEB)發生，因此仔細釐清使用情境和確認使用的軟硬體設備非常重要。例如在 APP 端出現問題，應該請使用者排除 (1)網路 proxy (2)帳號狀態 (3)軟硬體設備的情況。

就在某年某月某日，硬體 PM 宣布韌體更新的三天後，美國區使用者大量回報 Google SSO sign-in 報錯 403，從 agent 端轉跳預設的 Browser 的操作遇到 403/Disallowed agent 的問題。收到問題後，重新把韌體的版本與軟體登入流程確認一次，才發現在新版韌體將瀏覽器升版，卻沒有確認瀏覽器是否可以讓使用者從網頁登入帳號，一旦使用者採 Google SSO 登入流程，馬上會跳出 403/Disallowed agent 的警訊，讓使用者無法登入軟體。

此時公司的軟體與硬體部門都跳出來，從不同的登入方式，逐一測試予特定 SSO 的用戶的替代方案與解法。

無法登入是最常見的問題，常見的問題要解決之前要先確認客戶的使用環境；簡單的問題背後可能是不同原因造成，無法將解法 1 複製貼上給使用者 2 。

Browser 的問題

首先請用戶在同樣設備的 Browser 嘗試從網頁版登入網頁版，問題依然存在，幾乎可以確定是瀏覽器無法讓使用者登入 Google SSO。

軟體部門的整合測試問題

"跨部門的信任橋梁只能平時慢慢建立。" "信任的橋樑一旦垮掉要重建就很困難。"

軟體部門的登入通道在韌體更新後居然發生在同公司的設備無法登入，對各個跨部門的溝通拋下很多震撼彈。尤其是韌體在 preload 軟體的流程是瀑布式開發，軟體 SaaS 產品傾向敏捷開發，開發時間的間隔，外加整合測試的部門沒有特別將韌體與軟體測試列入必須測項，許多軟體問題反映出不同開發團隊的彼此默契。

軟體的問題找到硬體的解法 密技

面對客戶依然是要提出最有效的替代方案，在硬體部門討論出替代方案是在 Browser 的瀏覽預設改為手機板瀏覽器，如此操作可以讓 Google policy 接受瀏覽器登入，因此有經驗的 FAE 工程師在第一時間建議可以採用 手機板 mobile mode 的模式，讓使用者的 Google SSO 通過登入。

美國的 FAE 則視情況視機種提供客戶選項，其中一個選項是由客戶自行安裝第三方的網路瀏覽器。由於這個作法的風險是在客戶安裝後依然遇到登入問題，因此儘管知道有這樣的解決方案，也不會讓全球支援部門通知所有客戶，會由當地的 FAE 做評估後給建議。