作業: 取得可測試性承諾
這項作業的重點是定義、設定優先順序及提升可測試性需求和效益。
規範: 測試
目的

這項作業的目的如下:

  • 推動建立可測試的軟體來支援測試工作的需求
  • 提倡和支援採用適當的自動化技術與工具
關係
步驟
檢查可測試性需求
目的:  充分瞭解要由軟體交付流程或軟體架構和設計來解決的測試實作和評量需求。 

研究測試自動化架構和測試介面規格,以充分瞭解測試實作和評量需要。 尤其,瞭解這些需求在軟體交付流程或軟體架構和設計上加諸的限制。

評估衝擊和設定優先順序
目的:  指出對測試工作最重要的可測試性需求,並提出優先於次要需求的解決方案。 

研究可測試性需求,並根據需求不符在測試工作上造成的衝擊,進行基本的衝擊分析。 對於開發團隊可能所需的工作量,也要考慮進行一些基本的分析,並提供需求的解決方案。 對於每一項需求,指出對開發團隊衝擊較小的潛在替代方案。

利用這項資訊,制訂優先順序清單,把對於測試工作產生重大衝擊的需求(如果未符合且沒有替代方案的需求)列為最優先。 如此可以避免寶貴的開發資源浪費在不重要的可測試性需求上,將這個機會留給真正重要的需求。

定義可追蹤性的效益
目的:  根據基本的成本效益向關係人宣導可測試性需求的價值。 

規定具體的測試工作來要求開發團隊去開發軟體,將對開發工作增加更多需求和限制; 基本上等於加重開發團隊的工作量,也會提高風險與複雜性。 有些開發團隊會將可測試性的設計視為責任範圍以外。 在其他方面,可測試性需求必須佔用開發資源,反而不利於通常較為優先的客戶需求。 因此,您必須向專案經理、軟體架構師及其他開發團隊關係人「宣導」可測試性需求的效益。

對於您要取得承諾的每一項可測試性需求,進行效益分析。 研究報導、文章及論文來佐證可測試性需求的價值,並善用 ROI 統計資料。 以開發團隊的利益來考量效益;您在滿足這項需求的情況下可以提供什麼實用的評估資訊? 在每一個建置週期內,您如何更簡單、更有效率地提供及時、準確、深入或實用的意見給開發團隊? 這項需求可以提供實用的功能給開發團隊用在自己的測試工作或未來的軟體失敗診斷上嗎? 與客戶需求發生衝突時,請設法證明如果儘早解決可測試性需求,後續的建置週期將更有機會支援客戶需求。

支持和認同可測試性的擁護者
目的:  與重要的關係人合作,這些人支持建立可測試的軟體且支援測試團隊在這方面的需求。 

假定您會加重開發團隊的工作負荷或風險,則應該支持並認同有權力核准或支配可測試性支援的關係人。 在積極宣導您要支援的可測試性需求以前,請儘快行動。

最重要的三個關係人是軟體架構師、專案經理及客戶代表。 與軟體架構師合作,宣導建立支援可測試性軟體架構的價值。 與專案經理合作,強調團隊生產力和評估資訊的快速轉換來宣導可測試性的效益。 鼓勵客戶重視交付的優質產品。

宣導可測試性需求和效益
目的:  向重要關係人表示測試工作有一些重要的可測試性需求,並尋求他們對於可測試性的支持。 

必須以正確的方式宣導可測試性需求。每一組專案經理、開發團隊及客戶關係人各有不同的社會機能和文化,在宣導可測試性需求時必須密切注意。 根據經驗,如果團隊非常鬆散且不正式,請不要發起正式的可測試性「運動」; 在佷正式的專案中,請不要採取非正式的作法。

有時,「集體研討」會議是很有效的發表方式,可將需求視為對開發團隊的一項挑戰,並鼓勵建立創新的解決方案來滿足可測試性需求。 這有助於加強解決方案的主導權,並提升參與感。

時機掌握在此步驟中也很重要。通常,您應該儘早確認和宣導最重要的可測試性議題,通常是在「詳述階段」,但最好從「初始階段」就著手進行。 如果專案在這些早期階段提出可測試性議題,團隊通常會較小且易於調整。 由於通常不太需要重做,很容易在逐步發展的設計中納入這些需求。

為了確認可測試性需求,並以務實又不做「表面功夫」的態度來描述, 最好的作法是由測試團隊負責評估概念實證的活動,以及評估如何選擇開發用途的協力廠商元件。 尤其,由測試團隊參與資料庫元件選擇、UI 控制或元件選擇、中介軟體元件等, 意謂著可測試性議題可視為元件選擇準則的一個觀點。 例如,開發團隊大多不太關心採用哪些 UI 小組件程式庫; 如果有一個程式庫比另一個程式庫更易於測試,則開發團隊一定很喜歡使用較易測試的小組件程式庫。

如果您在支持或加入可測試性擁護者方面有困難,您可能需要設法採取更漸進的方式提倡改革,以期降低潛在的風險和阻力, 或必須將最重要的可測試性需求提升為嚴重的專案議題,表示如果不解決,無法成功完成測試工作。 就後者而言,建議您審慎考量所有選項,再決定這種作法。

取得支援和維護可測試性的承諾
目的:  達成協議,開發團隊將持續支援和維護可測試性功能。 

必須確定可測試性需求和開發工作上的其他任何需求或限制一樣,受到同等的重視。 您必須確定可測試性功能可以持之以恆。

有時,試圖取得這項承諾可能會造成開發團隊拒絕開發或支援可測試性需求。 雖然很令人沮喪,但最好注意這種情況並儘早面對現實; 等到投入大量時間和精力來開發測試實作之後,最後開發團隊卻放棄不再支援,到時情況將難以收拾。

提倡可測試性爭議的解決方案
目的:  監督和支持可測試性議題的解決方案。 

即使開發團隊同意對測試工作的可測試性需求提供必要的支援,您也一定要積極參與設計、實作及完成這項工作。 別因為開發團隊已同意解決可測試性需求或開始設計解決方案就不再關心;您必須確保適當的解決方案可及時開發完成。

您自己及其他測試團隊人員要能夠隨時解答開發問題的問題,並儘快在原型建立之後主動評估。 提出有建設性的意見,且對於開發團隊投注心力來達成您的需求,展現您的熱忱。 對於較複雜的可測試性需求,儘量要求重要人員出席或協助召開設計研討會, 但要預防團隊獨斷操縱開發人員設計流程的解答空間。

如果您感到提出的議題未得到適當的關注,或只是草率地解決,請向軟體架構師和專案經理表達您擔心的問題。 可能的話,請專案經理將議題記入專案爭議清單上。

評估及驗證結果
目的:  驗證作業已適當完成,並且產生可接受的工作成果。 

現在您已經完成工作了,這時最好驗證該項工作確實具有足夠的價值,而不只是花費在大量紙上作業。您應該評估您的工作是否具有適當的品質,並且該工作的完成狀態可以讓團隊的其他成員用作他們的後續工作之輸入。請盡可能使用 RUP 提供的檢查清單,來驗證品質和完成狀態都「夠好」。

請邀請執行下游作業而必須以您的工作成果作為輸入的人參與審查您的暫時性工作。請在您仍有時間採取動作來處理他們關心的問題時執行這個動作。您同時也應該將您的工作和關鍵的輸入工作成果做評估,以確定您已經正確且適當地重新呈現那些工作成果。 在這個基礎上,邀請輸入工作成果的作者審查您的工作,會有助於您評估您的工作成果。

請記得 RUP 是一項反覆式的交付程序,在許多情況下,工作成果都會隨著時間而演進。因此,通常並不需要(通常是缺乏生產力)對只會在緊跟在後的後續工作中用到一部分,或甚至於完全用不到的工作,做出完整的工作成果。這是因為和工作成果相關的狀況極可能會變動,因此在建立工作成果所做的假設狀況就變成不正確,導致浪費許多人力物力以及成本高昂的重做。同時也要避免浪費太多時間在呈現方式上,而導致損害內容本身的價值。在呈現方式佔極大的重要性,並且可以提交專案就具有商業價值的專案環境中,您可以考慮將呈現工作交給管理資源來做。