(三) Google軟體測試之道 -- TE

TE需要以工程師的身分參與其中以保持一流水準。兼具受開發者所敬重的技術水準與能由使用者導向的角度來檢驗開發者的能力。
TE需要監督各個建置標的整合後以及涵蓋整個產品所有組成部分的品質。因為如此，大部分的TE會參與不同屬性的低階工作，因此需要更多的工程專業職能。如果說SET的工作是最有價值的，那麼TE所做的也是；如果檢驗程式碼是最重要的，那TE也會要做。如果缺了測試基礎架構，TE們也會注意到。
接著就可以在專案的其它地方，或是維護一項產品或是測試版軟體的測試工作上，引領一些探索性質的測試任務。有時候這就像是工作階段的早期，是時間驅動式的，還需要做許多像是SET要負責的工作，而在循環的後期，TE導向的工作才會變成主要的工作。

TE參與後的工作
1.何處是軟體容易出差錯的地方?
2.軟體中的安全性、隱私、效能、可靠度、可靠性、相容性、全球化以及其他考量所指為何?
3.所有主要的使用者情境 是否如預期地正常運作?適用於全世界的使用者嗎?
4.這個產品能與其他產品(硬體與軟體)搭配運行嗎?
5.如果出現問題，診斷工作能做到何種程度?

TE應該要做的工作
1.測試計畫與風險分析
2.檢查規格、設計、程式碼與現有的測試
3.探索性測試
4.使用情境
5.建造測試案例
6.執行測試案例
7.群眾共創
8.使用者評估準則
9.使用者回饋

ACC (Attribute Component Capability，屬性文件功能)
屬性是系統的形容詞，他們代表能推銷產品的品質與特性，也是之所以能與競爭產品做出區隔的因素。也就是說，這些屬性是人們在理性選擇採用何種產品時會據以判斷的。
元件是零件，放在一起組成系統以解決問題，它們是體現軟體的一堆核心程式碼。
功能是在使用者的命令下，系統所能執行的動作。它們是輸入的回應、查詢的回覆以及代表使用者所完成的動作。

Googlg+為例
每一項功能至少應該要連結到一個測試案例。
許多功能需要超過一個的測試案例，並不是所有功能的重要性都相同，有些功能會比其他的來得更為重要。

Google+屬性
社交: 讓使用者能分享資訊並做自己想做的事
表示: 使用者可以透過功能來表示自己
簡單: 直覺。很容易就可享到如何進行他們想做的事
相關: 只顯示使用者關心的資訊
擴充: 能搭配Google特性、第三方網站與應用程式
隱私: 使用者的資料不能外洩

Google+元件
個人檔案: 可將使用者的資料與偏好紀錄檔紀錄下來
人: 使用者所連結的檔案
資料流: 由貼文、意見、通知與照片等內容所組成的，經過排名的資料流
社交圈: 將聯絡資料以"朋友"、"同事"等位分類而組成的群組
通知: 貼文中提及你
感興趣或+1: 受使用者歡迎的指標
貼文: 使用者與其聯絡人間頻繁的貼文
意見: 對貼文、照片、視訊等所提出的意見
照片: 使用者與其聯絡人所上傳的照片

Google+功能
---個人檔案---
社交: 與朋友及聯絡人分享個人檔案與偏好
表示: 使用者可以建立一位網路版的化身
表示: 用Google+進行個人化的體驗
簡單: 容易更新資訊並將之傳播出去
擴充: 透過適當地存取方法，提供個人檔案資訊給應用軟體
隱私: 能讓使用者保護其私密資料
隱私: 只與通過核准的適當群體共用資料
---人---
社交: 使用者可與其朋友、同事與家人通訊連繫
表示: 其它使用者的個人檔案已經個別化處理，容易區別
簡單: 提供工具方便管理使用者的聯絡人
相關: 使用者可以各種相關條件過濾聯絡人
擴充: 梯供資料給已授權的服務與應用程式
隱私: 不讓已核准的群體取用使用者聯絡人資料

評估風險
1.我們關心哪些事?
2.發生這些事的可能性有多高?
3.它們對企業的影響會有多糟?
4.它們對客戶的影響會有多糟?
5.產品的實作降低了哪些風險?
6.哪些降低風險的做法可能會失敗?
7.處理這些失敗需要付出什麼樣的成本?
8.復原的過程會有多困難?
9.事件會重複發生或者只會發生一次?

頻率
稀少:很少會發生錯誤且不容易處理的情況
不常:有可能會發生故障，但因為複雜度或使用量都不高，讓這類的狀況不常發生
偶爾:很容易就能想到會發生的狀況情況，有些複雜，而且應該是那些我們預期會受到歡迎的功能所造成的
經常:這項功能是使用率高、複雜度高，在正常使用情況下會發生錯誤之軟體功能的一部分

衝擊
最小:連使用者可能都沒注到的問題
某些:可能會困擾使用者的問題。如果發現了，就直接重試或使用復原機制
重要:會打斷操作情境的問題
最大:會永久損害產品信譽並讓使用者不再採用的問題

使用者情節
使用者情節描述在測試時使用者操作軟體的實際或特定的操作流程。它們描述不包含產品實作與設計細節的使用者動機與期待。
使用者情節帶有一點功能的味道，因為功能可讓使用者操作。使用者會有需求，而情節就會描述使用者如何使用軟體來滿足其需求。
情節會盡量一般化，不會有特定步驟、沒有寫死的輸入，情節就只是個需求做某些工作的需求，再加上那些運用測試中的軟體來完成這些工作的通用方法。
使用者情節裡頭所列的應該是與技術無關的。這樣的一般性讓測試者可透過自己與眾不同的方法，建造出能從軟體中取得所需數值的測試，這種方式也可能是使用者用來完成同樣工作的方式。

SET與TE的差異

如果是一位SET:
--能照著規格，找面白板並編寫出強固且有效率的解決方案
--會將一般使用者想成是叫用API的人
--編譯器出現警示訊息時會讓你感到焦慮
--認為領導力就是能建造出一套很棒的低階單元測試框架，可供每一個人運用或每天會在測試伺服器上跑個幾百萬次

如果是一位TE:
--會找一份現有的程式碼，尋找其中的錯誤並且能立刻了解該軟體可能會在哪裡出錯，但並不那麼在意是否需要從頭將它編寫出來或者做一些調整。
--會讀不成熟產品的規格，獨力將所有缺的填補起來，然後把這些都融合到文件裡頭
--會對資料視覺化感到興奮