前一陣子在 Facebook 上的 Test Corner 和 Scrum Community in Taiwan po 文, 想知道大家的想法為何.
如果要做到 100% 測試自動化, 不需要手動測試介入.
也就是之後產品出貨, 都是靠自動化測試, 沒有手動測試的步驟.
你覺得怎樣做會比較容易成功?
現在來整理一下兩邊的想法
(1) Test Corner
顧名思義, 這個社群主要是測試人員為主, 或者主要工作是在進行測試. 他們的建議大約如下
a. 把 RD:QA 的比列降到 5% 以下
b. 個人不認為完全沒有手動測試的流程會是一件好事...
c. AI 人工智慧測試嗎?
d. 根據經驗，自動化測試除非你的case夠多夠廣，不然真的還是無法取代人工測試，自動化只是幫助執行一些反鎖的工作，但代替不了人腦。
e. 開發團隊必須是由一群不論職能都很熱愛寫自動化測試的工程師組成，且definition of done中包含對所有delivered features必須要有最基本的coverage
f. 之前待的部門有討論過完全自動化這件事, 討論到最後發現有太多的狀況還是需要人工介入, 所以就把開發測試的自動化流程 改成以半自動化為主 ...
g. 同意調整dev/QA比例, 自動化過程中有牽扯架構調整以增加可測度時, 需要大量系統內部知識, 改的動的話 其實根本也在做dev的事了
h. Regression test , or check? 就很難100%了， 之前有想過 build domain knowledge base, automate "learning feature", automate "explore feature", automate "write test case", automate "coding test case"一整套的自動化測試, 再讀了一些相關論文，就放棄"不需要手動測試的自動測試”了
i. 10%、20%的目標一步步達成，才是通往全自動的捷徑
j. 假設前端都沒有技術的進化 然後相關的自動化測試都有資源可用 或許還有一點點可能 但事實上前端技術是會不斷進化的
別灰心 還有一種可能 機器人把你操作過的動作反覆操作 如有不對的地方 回放紀錄影片 然後再重新操作給機器人看 這樣機器人就知道特定條件下該如何操作測試 因為是真正模擬人的操作 效率會差點 但至少是全自動化了
把做不到自動化的case都砍了 也是一種方式
k. 如果考慮ROI, 就不會想要啥都100%自動化。
如果靠100%自動化，且可以承擔其風險，就代表當發生問題時，那個代價不會高到影響core value.
但通常那代表那東西不夠重要。
l. 個人覺得 只需要70%自動化 剩下30%改為探索性測試 產品其實就可以算是對它有信心的吧? 全自動你一樣會有意想不到的BUG XD
大概從最初產品規劃/設計就要把 100% 自動化測試考慮進去,
驗收也只看自動化測試 XD
m.
production monitor - Sentry, Zipkin之類的讓你可以及時察覺用戶的usage/crash/error report
Feature toggling - 可以及時關掉有問題的新功能但不用換回舊版或rollback
Dark launch或Canary release - 從內部或小群使用者開始部屬
test automation - 有了以上機制，automation其實也不用百分百，讓你有足夠信心上版就行。但toggle on/off的scenarios都也要做automation test.
n. 增加RD人數，開發時候就包含自動化測試內容，100%真是一個夢
o.
首先會想知道組織為什麼想要100%的自動化測試？
自動化測試也是由人去撰寫出來的，這樣的話會有一個前提，有辦法達到100%的規劃嗎？
突然想想，其實問題的方向是成功變成100%自動化測試，並沒有說成為100%沒有bug的產品，這樣如果用TDD導向開發並且撤除手動測試變相就達到了
(2) Scrum Community in Taiwan
a. Story 在開發時就要考慮易測試性，比較容易實踐出 100% auto test
b. 那要把這種需求放到產品設計上
c. 人力充足時
e.
這讓我想到前年的海盜年會，曉梅老師說的，同一個産品，不同的人來做測試，對於品質的感受是不同的。
我認為我已經100%測過這個産品，對於品質也很滿意。但換個人來測可能會得到這個産品是個垃圾的結論。
回過頭來說，100%自動化可以帶來什麼樣的價值？而這個成功又是什麼？産品可以因此多賣更多或賺更多錢嗎？
如果真能100%自動化測試，是否意味著就可以不需要進行探索測試？
如同追求100%單元測試覆蓋率，也無法保證程式一定沒有 bug 一般。
列完兩邊的想法後. 我列一下自己對題目更近一步的解釋:
我猜那位主管應該是希望測試工作的進行, 大多是自動化方式來做, 也就是大多數時間都是以測試程式的方式來執行測試, 幾乎沒有工程師要以手動的方式來進行測試. 這是我對他 100% 測試自動化的解釋.
他應該不是要涵蓋所有測試狀況. 當然, 有可能他以為這樣的測試, 就是涵蓋所有測試狀況. 所以他才認為不需要再有手動測試的資源.
並且, 他可能會覺得這樣的測試強度應該夠的,因為已經全面要做的事情給自動化, 受測程式的品質應該是沒問題的, 經得起市場或是用戶的考驗.
因此, 在這樣的目標下, 我們要怎麼做才可能比較做到主管想要的.
接著, 我們來比較 Test Corner 和 Scrum Community in Taiwan 兩邊的解法.
在不管哪邊有效的狀況下. 你可以看到 Scrum Community in Taiwan 的人大多覺得這件事可行, 只要夠人, 設計時有考慮到, 測試是可以 100％ 以自動化方式來進行.
但是在 Test Corner 那邊, 幾乎壓倒性悲觀的覺得不太可能.
兩邊的思維很明顯的不同.
Scrum Community in Taiwan 這邊比較是開發人員思維, 他們覺得大多工作是可以被自動化的. 這個觀點基本上沒有太大問題.
差別在於
(1) 有多少要自動化: 如果要測的東西很少, 把他們全部自動化當然不是問題.
(2) 自動化的效果如何: 雖然要測的事情都自動化了, 但是他們都抓不到 bug, 或者都是測到同一個 scenario, 這樣的自動化意義為何呢?
Test Corner 那邊的想法是以測試人員的主的, 基本上, 他們認為要測的東西是無限, 不可能全部自動化. Scrum Community in Taiwan 那邊不認為有這麼多東西要測. 他們認為只要有足夠人力, 用好的工具, 設計好的架構, 這件事不難達到.
另外, 就算有人可以做, 有工具可以幫忙, 架構的可測試性也不錯, 測試人員也是很擔心. 因為程式會怎麼 run, 是因為你邏輯設計怎麼做. 可是 bug 呢? 都是出現在你沒想到的狀況, 你怎麼能期待一個預先想好邏輯的測試程式, 可以全面性抓到未知的 bug?
所以, 很明顯地 開發人員 和 測試人員 的思維, 是兩個不同的世界. 一個樂觀, 一個悲觀. 一個認為可以做完, 一個想要能做好. 一個認為世界不會這麼壞, 一個認為大家都是壞人.
那到底測試是否可以被 100% 自動化呢?
受測程式的 path 和可輸入的測試資料是無限的, 因此本來就不可能涵蓋所有的 路徑和資料. 只是這個知識, 大部分工程師不知道.
因此, 測試要做的, 就是從中找出有代表性的路徑和資料, 測完後就安慰自己應該沒問題. 所以如何挑出有代表性, 來降低風險, 是我們要努力的.
前面提到, 有工具幫忙, 架構的可測試性, 這些都是很重要的基礎. 這些開發人員可以幫忙. 但是工程師在學校並沒有接受這樣的訓練, 可能教授也不會. 這裡可以參加 91 哥的課程, Joey 在這邊有很深入的研究.
另外, 需要加強的是如何選擇有效的測試資料和路徑. 這部分通常是開發人員的弱點. 他們總是認為假設太多狀況都沒問題, 都不會發生. 這部分測試人員就比較有這個思維.
如果不能補強這個思維, 調整 RD/QA 比例是沒太有用的, 因為就算都是 RD 來進行測試, 他們都認為這個不太會出錯, 都只開一些 happy path 的 test case, 那這樣的測試, 這樣的全面自動化, 無法確保品質能夠好到哪裡去.
所以 RD 要去接受一些 black box testing 方法的訓練, 練習怎樣開 test case 會比較容易抓到問題. 這個部分就可以找我來訓練 XD
還有, 你無法依賴某個方法, 或是某個人就可以抓到所有問題. 因此你需要多層關卡來把關. 例如:
靜態分析工具
設計檢視 (人工)
單元測試
整合測試
回歸測試
探索測試 (人工)
效能測試
…
人工與自動化交互搭配. 利用自動化來讓人有空去執行手動. 利用不同關卡檢查不同問題.
至於要分配多少比例, 這需要看你的產品定位. 有些產品是 1.0, 會不會賣錢還不知道, 可能不需要測這麼多. 有些則是公司主力產品, 那每個地方都很重要都要用力測. 因此沒有標準答案.
所以測試 100% 自動化可行嗎? 有機會. 只要人員有相關的技能. 不過 100% 自動化, 不等於 100% 涵蓋度. 並且做到 100% 自動化, 不代表品質就沒問題, 他只是把要做事情, 以自動化方式執行.
全站熱搜
留言列表
