跳至主要内容

OwlPay QA 團隊如何透過自動化測試工具 Cypress，確保複雜的 SaaS 付款產品能在快速迭代下保持穩定的運作

可靠的軟體測試，才能提供可靠的軟體產品。

在 OwlPay 團隊中，我們的測試工程師 (Quality Assurance Engineer，下均簡稱 QA) 會透過一系列嚴謹的測試，確保軟體可以正確運行。

OwlPay 是一個付款解決方案產品 (Payment solution)，無論企業規模大小，OwlPay 都能提供合適的 B2B 跨境付款方案。

但是付款 (Payment) 類型的軟體產品在操作上極為複雜。例如 OwlPay 目前支援了

  • 國內外共 4 種付款方式
  • 幣別超過了 50 種
  • 支援到帳國家高達 190 個

每一次新增功能時，QA 都必須確保既有功能運作正常。如果採用傳統的測試方式，這將是費時費力的巨大工程。

那麼 OwlPay 的 QA 是如何在如此複雜產品的功能下完成測試工作，配合產品工程團隊如期地上線新功能的呢？

背後的秘密就是–自動化測試工具 Cypress。

這一篇文章將從 3 個角度切入。和你分享 OwlPay 的 QA 團隊是如何導入 Cypress，以及 QA 團隊和其他角色的合作方式。

分別是：

  1. 技術選擇：為什麼要使用 Cypress 進行自動化測試
  2. 功能驗證：如何保證 OwlPay 的前端和後端功能正常運作
  3. 團隊角色：QA 團隊在 OwlPay 中如何和其他角色合作

主題 1. 技術選擇：為什麼要使用 Cypress 進行自動化測試​

Cypress Logo

我們先來認識 Cypress，再來講解這款工具對 QA 的影響。

這裡會提到 3 個重點：

  • Cypress 是什麼
  • 使用 Cypress 的優點
  • 使用 Cypress 後的協作方式

重點 1. Cypress 是什麼​

Cypress 是一款自動化測試工具，幫助 QA 省去人工一步步測試系統元件的麻煩。

不過 Cypress 並不是第一款自動化測試工具。

OwlPay QA Leader - Cody 說：

在以往的測試，都是使用 Selenium 及Appium ，主要測試場景在 Web 及 APP。

Selenium

但是 Selenium 跟 Appium 在進行自動化測試時，卻有一個大麻煩：安裝較費時。

以上兩者在進行 Webdriver 設定時，會遭遇到「版本」及「環境變量」的問題。如果沒有正確設定，就無法順利使用工具。

光是設定，就容易讓許多 QA 打退堂鼓。

但 Cypress 的出現有效解決了這個痛點。

分別是：

  1. 只要按照 Cypress 官方網站的技術文件 安裝完畢，就能無痛使用
  2. 不用另外測試安裝瀏覽器，直接使用更容易入門

下面是 Cypress 官方網站上的安裝與啟用示範。

重點 2. 使用 Cypress 的優點​

在使用 Cypress 進行測試時，它的主要優點是：

  • 支援介面測試及終端機操作
  • 測試中有 UI 介面截圖及錄影
  • UI 介面操作便利
  • 自動等待元件出現
  • ...

其中「自動等待元件出現」最有用。

因為在進行自動化測試時，常會遇到需要等待前端網頁元件出現才能進行下一個動作。使用者可在 Cypress 中設定一個預設等待時間 (例如 3 秒)，如果某些元件需要更長的等待時間，則可以自己手動加入。

這項功能大幅增加 QA 的測試效率。

重點 3. 使用 Cypress 後的協作方式​

Cypress 的出現，也影響了 QA 與產品團隊中其他角色的協作流程。

讓我們以 End-to-end Test 作為範例。

所謂的 End-to-end Test，是指 QA 模擬使用者操作系統介面。例如「使用者新增一張訂單」，在 OwlPay 系統上的動作會是：

  1. 點擊側邊欄的 訂單
  2. 點擊 新增訂單 按鈕
  3. 填寫 訂單金額、訂單 UUID
  4. 點擊 送出

在進行 End-to-end Test 時，QA 會透過 Cypress 的程式語法定位到特定網頁元件，接著才能去觸發元件。

以往在測試時，QA 會按照網頁元件的層級來定位。

例如要點擊 送出，原定位的語法是：

cy.get(‘.border > .ant-form-item-control > .ant-form-item-children > .ant-submit')

如果 UI/UX Designer 後續有變換按鈕的位置，QA 就需重新改寫 Cypress 的語法。

此時，若前端工程師協助將網頁元件命名 id，那定位元件就會是變得簡單許多。

例如語法是：

cy.get(‘#form_item_submit’)

不論 UI/UX Designer 如何更新版面，測試內容都不需要更動。

主題 2. 功能驗證：如何保證 OwlPay 的前端和後端功能正常運作？​

知道了 QA 如何應用 Cypress 這款工具後，接著我們進一步聚焦在 QA 的測試工作上。

這裡將介紹 2 個 QA 重要的工作：

  • 擬定測試計畫
  • 提升測試效率

工作 1. 擬定測試計畫 (OwlPay QA 如何制定測試計劃或策略以確保功能的完整性？ )​

在每一次測試之前，QA 會先擬定測試計畫以確保功能測試的完整性。

測試計畫的內容主要有 3 大類：

類別 1. 功能測試​

確保送出內容符合預期。

根據功能需求建立測試計劃，並將 "測試結果" 與 "預期結果" 進行比較。

類別 2. 整合測試​

整合相關功能測試，避免功能衝突。

模擬一個使用者從頭到尾操作系統，又稱為 end-to-end Test (端到端測試)。

類別 3. 回歸測試​

確保原有功能正常。

驗證此次 "修復bug" 或 "新增功能" 後，不會破壞現有的系統運作。

在執行順序上，依序是：

  1. 功能測試
  2. 整合測試
  3. 回歸測試

系統必須通過 3 種測試，才算是驗收通過。

工作 2. 提升測試效率​

QA 導入自動化測試，主要是改善上述測試中的反覆執行動作。

這些動作包含

  • 重要流程：例如訂單支付
  • 耗時流程：例如填寫安全性身分驗證表單
  • 低異動流程：例如使用者登入、使用者註冊

使用自動化測試，可以大幅降低人工手動操作的時間。

主題 3. 團隊角色：QA 團隊在 OwlPay 中如何和其他角色合作​

最後，我們來一起看看團隊合作的方式。

QA 在 OwlPay 團隊中的主要職責，是確保新功能與既有功能可以正常運作。

下方將分成「新功能」與「既有功能」兩個場景，分別聊聊 QA 和其他成員的互動方式。

場景 1. 新功能​

在這個場景，QA 的主要職責是確保新功能在上線前能正常運作。

那麼 QA 是在哪一個環節去作這個工作呢？這就要提到 OwlPay 產品團隊的開發流程。

目前產品團隊採用敏捷開發法 (Scrum)。

因為 OwlPay 團隊中並沒有配置 PM，因此接收需求的工作主要由設計師負責。

設計師收到業務單位需求後，緊接著會有一連串的規劃與執行流程。

依序是：

步驟 1. 設計師規劃新功能​

設計師會定期提案新功能。

這場會議將邀請：

  • 前端工程師
  • 後端工程師
  • 技術寫手
  • Product Owner

針對這個 Sprint 設計的功能，進行 UI 與功能進行討論。(各個團隊僅 1 位人員代表參與)

設計師的提案必須經過團隊確認沒問題後，才能排入開發流程。

步驟 2. 團隊共同排定開發項目​

也就是軟體業常說的 Sprint Planning Meeting (衝刺規劃會議)。

由設計師向 OwlPay 產品團隊的所有人員，解說要開發的新功能背景與細節。

QA 了解即將開發的新功能後，可以先規劃接下來的測試計畫。

步驟 3. 團隊每日同步開發進度​

也就是軟體業常說的 Standup Meeting (站立會議)。

每天早上舉辦，產品團隊中的每個人用 3 分鐘快速說明：

  1. 昨天做了什麼
  2. 今天要做什麼
  3. 需要什麼幫忙

QA 此時可以知道最新開發狀況。

步驟 4. 工程師送測功能​

前端/後端工程師在本機端開發新功能完畢後，會將功能部屬到測試環境供 QA 測試。

在 OwlPay 中，產品團隊使用 Jira 作為專案管理與工單系統。當工程師在 Jira 將工單切換成 Done 的狀態，並且按下 Complete sprint 的時候，系統會自動產生此次 Sprint 新開發功能的工單紀錄。

QA 可以閱讀此工單，了解本次送測的新功能。

OwlPay Release

步驟 5. QA 測試與驗收功能​

QA 依照設計師在 Figma 的設計規格，驗收工程師開發的功能是否能正常執行。

驗收的邏輯是：

  • 若正常執行，則通過測試
  • 若功能有異常，則會開立工單 (Bug ticket) 追蹤工程師的修復狀況

步驟 6. 工程師正式上線功能​

當本次 Sprint 功能皆測試完畢，QA 會通知工程師可以部屬新功能到正式環境上。

以上步驟，就算完成了一個開發週期。

場景 2. 既有功能​

QA 平時也需確保正式環境的功能可以正常運作。

當 QA、產品團隊、或是外部使用者發現系統問題時，QA 會按照下方流程處理。

依序是：

步驟 1. 接收問題與確認​

QA 會先確認問題發生的細節，像是在哪個系統環境上發生、發生問題的步驟為何。

步驟 2. 和工程師討論釐清問題​

了解問題後，QA 會先通知工程師並進行簡單的討論。

步驟 3. 開立工單​

當 QA 對問題有了初步的頭緒後，會將和工程師討論的結果紀錄在問題工單。

步驟 4. 判斷問題緊急程度​

若問題會影響到正式環境使用者的使用流程，QA 會請工程師進行緊急修復; 若問題不會影響，工單將先存放在工單系統中等待排序。

步驟 5. 團隊共同排定修復順序​

在 Sprint Meeting 時，由 QA 依序解說問題工單的細節。團隊了解問題細節後，共同討論影響範圍與修復順序。

步驟 6. 工程師修復與送測功能​

前端/後端工程師在本機端修復功能完畢後，會將功能部屬到測試環境供 QA 測試。

步驟 7. QA 測試與驗收功能​

QA 依照問題工單上的描述，驗收工程師是否正確修復功能。若正確修復，則通過測試; 若功能有異常，則退回工單並要求工程師繼續修復。

步驟 8. 工程師正式上線功能​

當本次 Sprint 功能皆測試完畢，QA 會通知工程師可以部屬新功能到正式環境上。

最後，QA 是如何確保測試結果，能夠迅速地反饋給其他團隊成員呢？​

OwlPay QA Leader-Cody 說：

我會在問題工單中附上 3 大類的內容：

【測試環境】

  • 測試環境
  • 測試帳號與權限
  • UI 設計

【測試環境】

  • 截圖
  • 操作順序
  • 測試案例

【測試環境】

  • 測試說明
  • 測試方式

在工單中紀錄的資訊愈明確，愈可以減少和工程師溝通的成本。

標籤：