我們如何提升無障礙測試的水準

在我們的協助工具旅程初期，我們通常將協助工具測試分為兩個類別：自動化和手動。 前者用於快速發現可透過演算法偵測的容易解決的問題，後者則用於需要更多時間和專注力才能找到的所有其他問題。 自動化測試非常適合持續整合 (CI) 等快速流程，而手動測試則需要與熟練的測試人員仔細協調，以涵蓋自動化工具無法處理的所有內容。

在此過程中，我們發現這兩種方法之間其實存在一個最佳平衡點。 我們與 Assistiv Labs 合作，將更完善的流程與端到端服務測試相結合，形成一套重新定義自動化和手動的測試工作流程。 這是介於兩者之間的混合法，可大幅提高自動化涵蓋範圍，並減少手動協調的額外負擔。

現在，我們可以在幾小時內發現明確且易於修復的問題，而不再需要幾週的時間。 我們的新流程會自動判斷哪些是緊急問題，並將問題傳送給合適的團隊，這些團隊通常會在幾天內解決問題。

成效既體現在技術層面，也體現在文化層面。 我們更快提供無障礙功能回饋，團隊更快解決錯誤，Asana 的工程師也開始以不同的方式思考無障礙功能問題。

建立流程，為無障礙錯誤排定優先順序

以 Asana 的規模而言，由流程和治理原則支援的強大優先順序架構至關重要。 團隊需要知道需要排入待辦項目的內容、時間，以及現在需要注意的事項。

但我們很容易低估為無障礙功能錯誤排定優先順序的難度。 優先順序是基於一個令人眼花繚亂的獨特因素矩陣，其中包括輔助技術、瀏覽器、受影響的使用者群組、使用者回饋、產品領域、修復難度、變通方法、WCAG 符合性和歷史背景。 有些錯誤可能已經存在很長一段時間，但直到最近才被偵測到。 其他錯誤則隨著新功能出現。 還有一些是退化，即以前可存取但現在無法存取的功能。

為了建立架構，我們正式定義了不同類型的無障礙錯誤，以便針對每一種錯誤設計精簡的工作流程。 其中一個重要步驟是定義什麼構成退化，什麼不構成退化。

迴歸 (n)

一個有記錄 (是否有任何記錄顯示此功能曾正常運作，例如先前的錯誤、評論串、螢幕擷取畫面或畫面記錄？)、可重現 (同事是否能使用所述步驟重現？) 的問題，此功能先前正常運作，但現在不再正常運作。

退步自然會獲得高度優先順序，任何人最不希望發生的就是無障礙功能的倒退。 在許多情況下，這可以大大簡化優先順序的排定。

不過，這裡有一個問題。 退縮是透過前後快照來定義。 例如，之前的快照可能是功能正常運作的影片，而之後的快照可能是新問題結果的影片。 錯誤自然有「之後」的快照。 但找到「之前」快照通常需要深入挖掘。

若沒有可靠的「之前」快照來源，通常不值得花時間調查錯誤是否可以優先視為退化。 這就是新型自動化證明極為有用的地方。

端到端無障礙自動化

對於無障礙測試或 Asana 而言，完全自動化的測試並非新鮮事。 過去，axe DevTools 和 jsx-a11y for React 為我們提供了廣泛的橫向涵蓋範圍。 但它們很膚淺。 我們認為，業界自動化測試的 30% 標準估計值與我們實現的 WCAG 標準相當接近。 有限的涵蓋範圍意味著手動測試仍然會發現自動化工具遺漏的錯誤。

我們需要能夠更深入的工具。 這些工具必須更符合我們的使用者研究和治理原則。 這正是我們在 Assistiv 找到的。 Assistiv 的端到端服務測試是由 Assistiv 工程師從頭開始編寫，並以我們提供的使用者流程和測試參數為基礎。 這些套件包含鍵盤捷徑、真實螢幕助讀程式、瀏覽器以及由 Assistiv Labs 雲端提供支援的機器視覺。 結果不僅僅是模擬，事件以與人類使用者相同的方式傳輸到機器，從而最大限度地涵蓋 WCAG 以及更廣泛的無障礙性問題。

端到端的無障礙自動化與傳統自動化截然不同，它與 Asana 互動，以與手動測試人員相同的方式完成任務。 根據測試情境，最多可涵蓋 75% 的 WCAG 標準。 而且仍有批判性思考專家實時監控所有情況。 Asana 和 Assistiv 的人員都參與設計具有代表性的使用者動作並審查結果，在範圍、頻率和準確性方面大幅提高自動化測試的基準。

結合力量

透過穩健的優先順序架構，以及從尋找少數錯誤轉變為尋找大多數錯誤的新自動化，我們實施了強大的優先順序工作流程。

首先，自動化測試會與 Asana 現有的工程管道同步。 新問題會以近乎即時的方式偵測到，並與可能導致這些問題的程式碼變更相關聯。

接下來，Assistiv 工程師會進行審查，篩選出誤報，並在 Asana 的待辦項目中撰寫一個議題，並附上具體情境的使用者影響和改善指引。 由於自動化測試持續執行，因此可以隨時取得之前的快照，並輕鬆分類退化。 我們維護自動化的 Asana 工作流程，將問題轉交給正確的團隊。

在實務上，這表示退化通常會在部署後 24 小時內被標記，並以無無障礙背景的工程師也能輕鬆理解的方式記錄。 這使我們的無障礙團隊能夠設定一個解決退化問題的 SLA，並將其交給產品團隊處理。 沒有人需要說明退化應該排在第一、第二或最後。 這些只是需要注意的錯誤。

這種去中心化直接轉化為更永續的計劃和更具包容性的終端使用者體驗。 我們有更多的自主權和影響力，有更多的創造空間，因為我們不再不斷救火。 這反過來意味著我們更快樂，也更有效率。

更快回饋迴圈的投資報酬率

一個未被發現數週或數月的錯誤，修復成本很高。 必須有人將其分流至適當的團隊，並確保其獲得優先處理。 被指派的工程師很可能不是造成錯誤的工程師。 即使是同一位工程師，也很難挖掘出被遺忘的背景資訊、轉換工作模式，或與其他團隊協調，以解決在中間幾週或幾個月內產生的技術債務。

若要用數字來說明這個問題，一項被廣泛引用的 IBM 研究發現，在生產階段發現錯誤的成本是設計階段發現錯誤的 30 倍。 這聽起來很有道理。

當工程師在早上部署更新時，任何退化的跡象通常會在工作日結束前開始出現。 回饋迴路非常短，因此我們的端到端測試在多個情況下率先提醒我們注意一般 UI 錯誤，而不僅限於螢幕閱讀器或鍵盤導覽。

隨著工程師開始更快地從端到端測試中獲得回饋，我們注意到優先順序的認知負擔有所減少。 模糊性消失了。 工程師會想：「我要對此負責，因為我今天早上發佈了它。 昨天還能正常運作，今天卻出現問題，我現在需要修正。」 修復無障礙功能錯誤變得像是肌肉記憶。

在 Asana 中，無障礙功能錯誤只是錯誤。 而且會被修復。

更出色的無障礙自動化方式

在我們採用端到端協助工具測試之前，我們的協助工具團隊已經取得了重大進展。 在營運方面，設計和工程團隊已經記錄了審查流程、退化定義和 SLA。 在測試方面，有用於快速但不深入報告的自動化解決方案，以及用於徹底但耗時稽核的手動品質保證。

透過端到端，我們擁有技術解決方案，可補充現有投入量，並建立在現有投入量之上。 退化情況的記錄更及時、更詳細，且提供更多證據。 幾乎沒有人會浪費時間處理無法行動或無法重現的錯誤報告。

現在，我們清楚掌握哪些錯誤是新的，哪些是舊的，它們影響哪些使用者流程，以及由誰負責修復。 我們可以領先一步，專注於未來 Asana 無障礙性的願景。

關於作者：  Cameron Cundiff (技術主管) 和 Jiaxin Zheng (技術計劃經理) 均為開發生命週期群組的成員，致力於提供工具，使開發人員能夠快速、穩健且愉悅地將想法付諸實現。