第二季

    Q2通過qTest快速推動高質量的DevOps生態係統
    450
    涵蓋的金融機構
    4
    十億登錄
    400 +
    總開發人員
    圖像

    概述

    在零售銀行的世界裏,消費者期待的不僅僅是支票賬戶和借記卡,他們期待的是一套正確的解決方案來改變他們的財務生活。2004年,Q2創始人漢克·希爾(Hank Seale)開始通過技術加強金融機構,建立更強大、更多樣化的社區。為了實現這一目標,他開發了一個單一平台,通過與傳統金融機構技術集成來消除技術障礙。如今,美國每10個數字銀行客戶中就有一個注冊了Q2的單一平台,通過他們所選擇的金融機構進行銀行業務。

    第二季度將年收入的20%以上(2021年約為5億美元)再投資於研發,並建立了行業領先的內部可用性測試設施,專注於提供最佳體驗。Q2的產品理念——“問”。理解。交付。-意味著軟件更新必須以客戶期望的速度和最高質量交付。為了實現這一目標,Q2每個月都會針對網頁、iOS和Android平台多次發布其數字銀行軟件的新版本。

    “我們身處金融科技行業,測試至關重要,”數字銀行副總裁Jan Acosta說。“我們必須有良好記錄的測試,以顯示對我們執行的內容的非常清晰的可追溯性。為了達到我們需要的覆蓋範圍和質量,很大程度上強調了自動化——我們不能完全手工完成,並按照我們想要的節奏發布。”

    Q2的團隊已經轉向更高水平的自動化。他們利用多種自動化工具和框架來確保每個版本的質量,包括Selenium、Appium和基於Python的自定義框架。由於跨團隊有如此多的工具和過程,通常很難清楚地了解給定版本的位置。團隊需要一種方法來全麵地將問題追溯到特定的測試和環境,並將這些問題傳達給開發團隊。領導者在很大程度上依賴於對發布準備情況的直覺,而不是由數據驅動。

    而一些團隊可以訪問各種類型的測試用例管理工具在美國,跨越不同的、未集成的工具集的高度自動化造成了瓶頸和可見性問題。為了解決這些問題並繼續擴大他們的DevOps進展,第二季度的領導層確定了一個明確的需求,即需要一個更精簡的方法來測試管理。

    “qTest是我們為測試工作創建的生態係統的中心點。”

    製定策略並找到合適的工具

    阿科斯塔說:“測試效果必須放在第一位。”“它源於測試策略和測試計劃,與產品和開發有良好的關係,所以你能理解你所得到的是什麼。這使得測試團隊能夠梳理代碼,並了解可以檢查的滲透是什麼。”

    這一理念幫助指導團隊建立新的測試管理策略,並尋找一種工具來簡化他們的DevOps管道並推動創新。

    在評估了組織現有的工具和市場上可用的工具後,團隊選擇了Tricentis qTest。

    qTest與DevOps管道中的工具集成的能力是這個決定的關鍵。Acosta告訴我們:“qTest API的豐富性是我們最重要的賣點之一。我們能夠使用一種工具,讓它為我們的世界工作——它是可塑的,可以適應我們的過程,而不必改變我們做事的方式。”

    挑戰

    • 在高度監管的行業中,測試用例到結果的可追溯性對於遵從性是至關重要的
    • 確定釋放準備就緒是困難的,依賴於直覺
    • 缺乏追溯到開發人員工具的可追溯性減慢了缺陷阻塞進展的通信電路
    • 更大的開發組織缺乏信心

    qTest是直觀的。它具有一個優秀的測試用例管理係統應該具備的所有東西。作為一個領導者,它有我想要的所有關鍵東西——記錄和捕獲我的測試用例,一種查看我的執行結果的方法,Jira之間的集成和可追溯性,以連接各個點,並讓我的數據可訪問,以便我們可以以符合我們需求的方式報告。”

    發現成功:可見性、可追溯性,並為一致的質量定義護欄

    項目、過程和團隊的組織是重要的第一步。qTest中的項目按功能劃分,並與Jira中的特定板集成。由於從一個團隊到下一個團隊的功能重疊,在qTest中共享測試用例允許其他人快速定位和執行現有的測試用例——包括手動的和自動的。這個過程減少了從一個版本到下一個版本由多個團隊利用的測試用例的冗餘,並使跨團隊的測試用例維護更容易。

    阿科斯塔說:“最大的因素是製定標準。“當你在處理一個大型團隊和幾個大型項目時,有條理有助於更有效地管理資源。”

    首要任務是實現特定的護欄,以確保跨團隊協作的一致性和便利性。一個例子是測試資產的命名約定。因為這些字段在qTest中是可定製的,Q2的測試用例現在遵循與Bitbucket和其他存儲庫相匹配的特定命名約定,所以測試人員和開發人員都可以在需要解決測試用例時輕鬆地確定他們需要什麼。

    自定義字段和狀態也有助於發展Q2的測試過程。例如,除了指示測試在哪裏運行(移動、web或兩者都有)的自定義字段之外,還利用了自定義狀態來對失敗的測試用例進行分類。失敗的測試用例觸發評審,以確定失敗的來源。

    團隊意識到失敗有時是由於服務器停機、移動設備離線、網絡問題或其他測試環境問題,這些問題與代碼中的缺陷沒有直接關係。這種可見性允許測試團隊與IT中的各個部門更緊密地合作,以優化他們執行測試用例的方式和時間。這一舉措大大減少了由環境問題引起的誤報。

    “qTest給了更大的開發組織更大的信心,對交付和支持組織更是如此。我現在可以讓他們看看我做了什麼。它讓我們能夠做出數據驅動的決定,而不是憑直覺做決定。數據驅動的決策將情感從對話中剔除,以決定如何最好地繼續前進。”

    集成測試自動化與DevOps管道

    跨DevOps管道的集成簡化了Q2團隊的工作。當開發人員將代碼簽入Bitbucket時,會觸發一個作業來測試新構建的環境。運行狀況檢查完成後,將觸發Jenkins作業進行自動化,並將所有測試結果記錄在qTest中。為了讓其他涉眾了解最新情況,由qTest Pulse觸發的工作流將結果共享到Microsoft Teams通道,並向團隊發送電子郵件通知。

    這個過程允許在每個版本中有更大的信心。Q2團隊現在已經清楚地了解了發布的位置以及發布之前需要做什麼。

    阿科斯塔說:“這是從直覺反應到有形指標的演變。“如果我回到qTest之前的起點,我們每天都會為發布做準備。我會聽到這樣的說法,‘我們在正軌上’或‘我們很好’。“這並沒有告訴我我們離正式上線日期的完工率是多少。今天,我看到的是“我們完成了93%”或“我們在Jira中被問題#blank阻塞了”。’對我們正在做的事情的可見性為更廣泛的組織創造了更多的清晰度和信心。”

    數據驅動發布

    如今,數據是每個決策的中心,無論是發布準備就緒,還是確定團隊可以繼續改進他們的DevOps流程的方式。來自各個業務級別的涉眾依賴於這些數據來描繪一個清晰的版本所處的位置,並度量實現目標的進展——包括開發經理、高級領導、scrum團隊和測試戰略家。Q2利用qTest api每24小時將信息拉入數據倉庫。PowerBI用於構建對決策至關重要的自定義報告和儀表板。

    每個版本的數據都被用來管理執行和測試指標。執行度量,例如測試用例通過的百分比,多少是基於移動測試的,在Jira中報告的缺陷的百分比,被用來評估每個版本的準備和質量。測試指標用於確定團隊如何以及在哪裏可以改進。例子包括:我的每個團隊自動化的百分比是多少(確保自動化不會隨著功能和測試資產的增長而下降),哪些特性需要增加自動化,或者我們在哪裏發現了最多的問題。

    通過qTest從各個團隊的中心位置提取關鍵數據的能力有助於促進這一過程,並允許Q2的創新和質量的持續增長。

    結果

    • 自定義狀態允許對失敗的測試用例進行實時分類——減少開發需要解決的問題的數量
    • 測試用例在多個團隊之間共享,以減少冗餘和工作
    • 跨團隊的標準化測試管理流程
    • 集成到CI/CD管道允許跨多個渠道快速報告結果
    • 集成了多種自動化工具和框架,包括Jira, Jenkins, Bitbucket, Selenium, Appium和自製
    • 每24小時從所有項目中提取數據,以支持PowerBI中的自定義報告和儀表板,以便進行數據驅動決策
    • 增加了對測試的信心,提高了發布的質量
    Baidu
    map