iT邦幫忙

第 12 屆 iT 邦幫忙鐵人賽

DAY 4
0
自我挑戰組

轉職新手的自學筆記系列 第 4

淺談 QA Engineer 工作內容

前兩天介紹我的轉職學習求助資源,多少提到自己在職場的學習,而相信對程式新手而言,QA是相對陌生的職位,因此,想藉今日分享我所理解的分工職務內容

什麼是QA?為什麼需要QA?

註:目前是在軟體新創,比較偏向分享這樣組織的QA,並以純軟為主

試想一下?有沒有曾經買過一些服務或產品,對方描述都很棒,也有一些不錯的評價,真正開始使用才發現各種困難。可能是設計對使用者不友善,或者在某些情境效能不佳,甚至跟該公司的宣稱有所抵觸。

這就跟研究與實務可行的落差一樣,即使研發團隊盡全力確保自己的程式在效能與功能正確,不會突然crash,也沒有邏輯錯誤,受限於設計者本身對產品太過習慣,與使用情境太過單一,沒有真正經過測試的產品是很難直接進入市場。

這就是QA存在的重要性:

  1. 依據各種使用者可能使用的情境,確保產品都能正確運作
  2. 協助PM\RD\sales等夥伴釐清產品問題,並給予改善建議
  3. 在開發新功能時,基於對使用者與使用情境的理解,給予設計與實現建議

在團隊中的定位,通常有以下不同形式:

  1. QA直接在研發團隊中,技術導向,與RD高密度協作,大幅度自動化,從工程角度給予實現方法與架構建議
  2. QA歸屬於PM,依據產品roadmap排定每一次測試進度,更類似QC,可能影響RD進度
  3. 獨立QA部門,跟RD平行,直屬於產品長

這些分類很可能並行或隨組織需求變動,最終目的都是希望確保開發產品的品質與增進用戶滿意度。

當產品成熟,QA就更重要

對新創公司而言,產品開發會分幾個階段,也反映對不同職能的需求:

  1. 研發初期:設計師與RD為主幹,盡全力設計與實現重要功能,確認初步的商業模式
  2. 研發中期:業務開始變得重要,必須與研發人員討論可接觸用戶與優化商業模式,也會從用戶中得到反饋來優化設計
  3. 研發後期:產品趨於成熟,已有一些用戶(確認市場反應友善且能賺到一些錢),愈來愈在意品質,因此邀請QA加入

在開發愈來愈敏捷的情境下,客戶變多、實現的需求變得複雜,發版的速度也變得愈來愈快速,直接讓PM\RD\designer等大量測試使用者情境,可能嚴重影響原本業務,專職的QA可以減輕其他職位的負擔。

我的工作以每週、每個月的區分:

  1. 每個月:
    1. 配合客戶需求,通常一個月會有大型版本更新,因此每個月會有一段已知密集測試期
    2. 依據功能的重要程度,與設計師、RD討論確認roadmap,並給予自己長期操作產品的反饋,協助設計師優化設計或挪動milestone
    3. 持續因應roadmap修繕測項與自動化測試實現,以促進產品測試效率與品質
  2. 每一週:
    1. 依據客戶反饋,可能有在公司情境測試中仍未發現的事件,QA需要協助團隊去釐清特定環節出現問題
    2. 若有緊急修復產品,通常在一天內完成測試並回覆結果,反饋通常會細緻到RD程式碼可能出錯處的猜測

為什麼需要自動化測試?如何執行?

在上列描述,應該可感受到測試需求非常高,且要求效率,而自動化的好處是:

  1. 品質一致:人為操作測試可能每人標準不同,同一人當下測試狀況有差,造成品質不一致,將無法協助團隊掌控產品
  2. 增加效率:工程師都很厭惡重複性活動,最好的方法就是用工具解決麻煩,使人能做更有效益的事
  3. 結果清晰:在工具串接完整的情境下,很能直接讓系統跑完測試,輸出報告,使成員們易於偵錯

常見工具:以 微軟應用程式 的 UI testing 為例

  1. winappdriver
  • 是一套特別支援微軟產品的selenium工具,當時selenium被發展的目的,便是希望自動驅動網頁,可獲取產品的即時訊息,在測試應用上,可依據工程師的指定,自動模擬使用者按照特定順序與方式去操作產品,以達到所謂的UI testing
  • 舉例來說,可以實現去點擊某個頁面、捲動頁面、填入資訊等,各種我們在網頁上會採取的行動
  • 目前selenium API已經幾乎支援各類主流語言,可依據使用需求,選擇裝載的工具與撰寫語言。因為我經手產品架構以C#為主,也相對是開發測試微軟產品最佳選項,因此採取支援C#的winappdriver
  1. visual studio
  • 微軟針對開發C#需求的整合開發環境,可以在裡面架設專案架構、進行撰寫,也支援測試程式的撰寫與執行
  • 跟微軟另個產品VS code完全不一樣,這是相容於各種OS的編輯器,在mac操作特別方便
  1. inspect:(請點入連結了解更多)
  • 應用程式不像我們打開網頁原始碼或點選檢查就能一覽無遺,原有架構跟真實呈現也可能有落差,inspect是微軟協助工程師去確認微軟產品UI的工具,可看到特定物件的名稱、類型、隸屬層次等資訊,直接成為自動化測試撰寫所用資訊,以協助工程師抓取明確對象、測試該行為

實際執行方式,將會在之後文章深入分享,現在不特別贅述


在結尾則想提到我猜想 什麼樣的人適合QA\QA適合什麼樣的人,以及我所理解的 QA可帶來的好處\困境

對應業務與特質:

  1. 品質把關者:需有耐心與細心,不會對每天重複性工作不耐煩且降低品質
  2. 理解使用者需求:UIUX經驗或業務,多少都對使用者需求比較敏感,也自帶易用性測試的mindset
  3. 良好溝通能力:中間很常需要同時理解設計、RD、業務端的需求與想法,很可能需要轉譯彼此語言

QA經驗可帶來的好處:

  1. 工程菜鳥快速上手產品開發:模仿是一種學習的方式,撰寫自動化測試需要大量閱讀理解RD所寫內容,這些過程會刺激自己查詢更多資料與熟悉產品開發架構,有機會成為切入研發的跳板
  2. 建置完整產品觀:不同於RD任務會切分很細,有時難免不暸解整體需求,QA很需要跟著客戶需求,在比較整合的層次思考問題,所理解也相對全面

QA的困境:

  1. 時間永遠不夠:大家都知道理想上所有測試應該都被自動化,但耳聞不同公司的QA皆常見測試業務量太大,總有很多測試無法被自動化,產生測試的不效率
  2. 測試與研發語法邏輯不同:雖然都撰寫同一語言,但會用到功能與思考架構幾乎不同,會造成難以建立研發類型常用的語法與習慣
  3. 未必能轉RD成功:上述兩個問題帶來能力與經驗的限制,願意投入的QA也會讓主管未必想放手,多會繼續安排相關業務

目前的對策:

  1. 選擇較為彈性的新創組織,主管比較open-mind者
  2. 積極爭取任何接近研發的業務,有機會就實作證明自己實力
  3. 利用任何空檔與非上班時間栽培自己

總結上述,QA在逐漸完整的研發體系中扮演逐漸重要角色
雖然可能是轉職者初步理解研發的敲門磚,也可能成為限制
為有足夠積極與釐清自己目標,才能使QA成為墊腳石非絆腳石


上一篇
第二步:學會善用資源與提問
系列文
轉職新手的自學筆記4

尚未有邦友留言

立即登入留言