文長慎入
當QA有些時日了 分享一下
我和很多人一樣對QA的工作分際到底是什麼有些疑問? 不同公司，組織，人理解都不太
一樣 有必要彼此釐清清楚 這樣開發與測試流程才能好好的運作
光是要釐清說服 必須相當理解所有的細節包括開發的想法與盲點? 哪類的測試是哪個
角
色來負責較為恰當 unit test,build test,functional test, integration, performanc
e .... 測試也有分階段分層次 唯有親身歷經才會有較深的感受
我個人會把QA跟SDET當成是不同的角色 雖然常常有人混為一起談
我的定義裡QA的角色較接近使用者的想法與感受 能把關產品經理或專案經理的需求跟使
用者的感受 越是不理解開發者越好(避免洗腦 開發者常常會說這是framework的問題啦
這有效能的極限 不能這樣操作啦! 使用者會理解嗎? 就是不買不用而已) QA只要理解使
用者的需求就好 測試可能也是較為手動的方式
而SDET的角色較為接近開發者 最好本身有過幾年的開發經驗 這個角色深知開發者的一些
習慣與盲點 透過自動化測試來確認功能的正常外還需要確認一些例外狀況的處理 還有開
發者的設計邏輯會不會影響效能 當然這也可以透過其他測試來達到?
這是我常常喜歡舉例的case
"從web用A帳號送一封信給B帳號 然後拿起手機app用B帳號登入去收信 結果收不到信"
通常QA就是這樣描述 這也很正常 因為這就是使用者的行為
但開發者有web-front-end server-back-end android-app QA到底要找誰問啊？只能一個
一個問
web-front-end: 我看log有送出去喔 應該是後端有問題
server-back-end: 看來是有收到 從log看也有push到android-app
android-app: 手機我看一下ōo邊沒收到啊! 當然秀不出來
QA:幹你老師! 那信是跑去哪了? 每個開發者都說自己沒問題?
如果是一個好的SDET就能直指是哪出問題 且知道要問誰還能幫他找出問題點 畢竟SDET自
己也要開發 思維上較接近開發者 比較能知道開發者需要什麼才能debug 還能告知哪邊加
個log比較好釐清
Web>back-end>db>back-end>android(service>db>ui)
問題可能發生在上列的任一點上 可以透過自動化測試來逐步釐清 (只是帶觀念省略一
些細節)
SDET較著重於自動化測試包括功能效能結構資料庫設計都可以提出建議
QA除了使用者行為的測試外，可能要多反饋使用者的感受 也許UIUX需要調整
兩者角色都很重要 幾年下來的感覺是?
QA最好是有產品背景的?
SDET最好是有開發者背景
但好玩的是
有產品背景的喜歡當產品經理
有開發背景的覺得測試很low
個人覺得好的SDET真的不容易要模擬的情境很多 寫的code也不比開發者少 通常會更多而
已 當時程被延誤最後都會是壓在測試上 有問題改版再改版 回歸測試決不能少 只能透過
自動化且還要跑的快 這還是api能解決的
如果要連前端的Web,App要自動化也沒辦法急 沒事只要前端開發者心血來潮rename個obje
ct id就能搞死你 所以測試也會慢慢有自己的framework自己的configuration方便快速調
整 refectory更是家常便飯 不然要cover一堆需求的改變 新舊相容 很快就會難以維護
最後就會便宜行事(手動測一下這次改的部分) 品質下滑的開始 因為時間不會多給但要co
ver的範圍更多更廣 還有一些side-effects 所以不自動化是很難短時間快速驗證的 但又
變得越來越難維護 扯遠了
所謂專業是要能指出問題論述有理 有憑有據(log) 能被接受 甚至不得不接受 沒有模糊
一堆人瞎猜的空間 這樣就不會有吵架的空間 大家乖乖的回去修bug或加case讓系統更好
更完善
這就是我認知的專業測試
※ 編輯: jl40 (61.228.234.104), 12/05/2018 00:27:54
※ 編輯: jl40 (61.228.234.104), 12/05/2018 00:28:58