我不適合做 QA 吧？為什麼開 bug 會糾結？

我早期的經驗都是在做自動化，後來一點的經驗則大多是一個人負責一個專案的測試。

直到近期這份工作，有些專案到了測試階段，可能同時有好幾位 QA 一起測試，我才開始有了和另一位 QA 密切合作的經驗。


某次專案，到了測試階段，重要的主流程卻還有許多 blocked issue。

我們一開始就開了好幾個 critical bug、major bug，同時也發現了介面上有許多可能沒有那麼重要，卻和設計稿不一致的 minor bug。


一開始，我們都按部就班的把 minor bug 開起來記錄。

但眼看時程慢慢推進，一些 critical、major bug 反覆驗證還是失敗，Dev 卻開始先處理 minor bug⋯⋯更恐怖的是，minor bug 的修正，竟然導致了新的 major bug。


這時我在開 minor bug 前都很糾結。有時候真的很希望 UI/UX 和 PM 能放過這些小問題。我開始考慮去和 UI/UX 和 PM 對一下，說服他們維持現狀⋯⋯


以前的我一直覺得，這是不是代表我有什麼問題。

心靈強大的 QA，看到 bug 應該手起刀落吧？

「不一樣就是不一樣。bug 開就對了。」


-


但有一天，我和另一位 QA sync 彼此的進度，他截了一張圖給我。雖然功能用起來其實合理，但我看了一下，還是忍不住說：「這和設計稿完全不一樣⋯⋯」


見字如面。即使遠端工作看不到那位 QA 實際的表情，但他的訊息裡透露著一種我非常熟悉的無奈：

「還是得和設計稿一樣嗎⋯⋯那你去問一下吧」


那一瞬間，我才忽然意識到，原來大家都會有一樣的痛苦。

我們都知道不一樣就要確認，但有時候知道理論上要問，但我現在真的不想成為那個又去煩人的人。



我默默的非常懂，於是我去幫他追了。

我去問 UI/UX 和 PM：這個差異其實不太影響使用體驗，我們是不是可以先不修？


-


以前的我真的會想：


「為什麼我看到 minor bug 會這麼糾結？」

「我是不是太怕麻煩別人？」

「我是不是不夠強勢？」

「我是不是不適合當 QA？」

「正常 QA 應該看到不一樣就直接開 bug 吧？」


但在開始和另一位 QA 密切合作後，我才發現：原來大家心裡都會跑這些東西。


也是在看到別人有一樣的掙扎時，我才反過來理解到，我原本以為這些想法代表自己太脆弱，但其實，這可能是一種 risk-based thinking。


成熟的 QA，不是看到任何差異都毫不猶豫的喊：

「BUG！！！」


而會不斷在心裡做權衡：

「這個真的影響 user 嗎？」

「這真的是 bug，還是 design decision？」

「現在值得打擾 Dev 嗎」

「在這個時間點開這個 bug，真的會對 release 產生正面影響嗎？」

「我們現在是不是有更大的風險需要優先處理？」

「修這個東西本身的 risk 是多少？」

「為了修這個 minor issue，會不會反而引入更大的問題？」


QA 的工作並不是「找出所有和規格不一樣的地方」，在真實的軟體開發裡，資源和時間是有限的，所以風險和優先順序的評估非常重要。


不開一個 bug，不代表沒有看到問題，而是已經看到了背後更多的東西：

看到現在最重要的主流程還 blocked，看到 critical、major bug 還沒有穩定，看到了 Dev 的修改帶來新的 issue，也看到了這個 minor issue 對 user 可能根本沒有實際影響，就僅僅是「和設計稿不一樣」。


每一個 bug 都不是只有「要不要修」這麼簡單，它背後還有成本、時程，以及修正本身帶來的風險。


而或許：


「文件寫 12px，我看到 13px——Severity: CRITICAL！！！」


這才是真正不太健康的思維。

留言

張貼留言

這個網誌中的熱門文章

殺蟲劑悖論 pesticide paradox

大家應該都聽過，不斷使用某牌的殺蟲劑，最後該環境的蟲子就開始對那牌的殺蟲劑產生抗性。 殺蟲劑漸漸無效，蟲子開心的吃著火鍋唱著歌。 殺蟲劑悖論 是測試領域的一個名詞，也如同字面上的意思，產品會漸漸對不斷執行的「相同測試案例」有抗性。 同樣的一組測試案例會漸漸無法發現產品的問題。 所以測試案例需要不斷更新維護，嘗試發現其他問題。 （全文完，大家看到這邊就可以了。） 以下是幹話時間 「為什麼？難道產品是活的，還懂得怎麼搞事嗎？」聽到殺蟲劑悖論時，剛進來的 QA 實習生 A 覺得很驚訝。 「產品是死的，但 Dev 是活的。」資深的前輩 R 又說了讓人無法頓悟的話，然後喝了一口茶。 實習生 A 和前輩 R 並不重要，等一下也不會再提到他們。 為什麼會有殺蟲劑悖論的現象 假設現在有一個非常簡單的產品，這個產品做的就是輸入1個數字，然後顯示這個數字+10之後的結果。 透過一些門路，我們知道產品的 code 長這樣（因為是黑箱測試，測試的人並不知道喔）： num = int(input("Input a number...")) print(num + 10) 規格書有說，不輸入就當作0的意思。 對了，這個故事不幸的是，這間公司為了縮減開銷，把 QA 都裁掉了。 現在剩下便宜大碗的實習生  aka 血汗萬用雜工 照著前人留下的測試案例來測。 我們現有的測試案例是這樣： 輸入正整數 預期結果：正整數+10 輸入負數 預期結果：負數+10 不輸入 預期結果：10 輸入小數 預期結果：小數+10 第一次測試，我們火眼金睛的實習生立刻發現，這個產品在不輸入和輸入小數時會壞掉，於是開2張單請 Dev 修： [PDADDNUM-100] Throw an error if no input [PDADDNUM-101] Throw an error if a number with a decimal point 我們的 Dev 連夜趕工修好了： num = 0 input_num = input("Input a number...") if input_num: print(float(input_num) + 10) else: print(10) 第二次測試，現在不輸入沒問題了，關了一張單(PDADDNUM-100)。 ...
閱讀完整內容

手動測試與自動化測試的選擇

在聊手動測試與自動化測試的選擇之前，先聊聊手動測試和自動化測試的優缺點和適用場景。 手動測試 手動測試是指測試人員手動操作軟體應用程式，確認使用起來一切安好、一切符合規格和預期。 優點 以人類的角度使用一個軟體產品 畢竟產品最終就是要給人使用，判斷這個軟體應用的功能、流程設計是不是直覺、易懂、美觀等等。而且也能很輕易的發現介面上的問題，比方跑版、點了之後乍看好像沒有反應等。 即時的適應變化 在敏捷開發中，一個還在開發甚至是設計中的軟體功能就可能需要測試參與了，其中可能有多次的大改，自動化在這時候就是完全不適合的狀況。 進行探索性測試 發掘一些被規格書遺漏掉的部分、特殊的使用情境、一些很清奇的操作、在一些原本簡單但越來越複雜的軟體系統中，嘗試各種操作的交互。 缺點 當軟體功能穩定時，每次都以手動來執行相同的測試，較耗費人力、時間。 在測試次數極為頻繁、時程緊迫的狀況下，測試人員容易因為精神上的疲倦而導致錯誤和盲點，導致測試結果可能不可靠。 測試速度仰賴測試人員的熟練度。如果功能交給其他不熟悉的人測試，時間上可能會有巨大的差異。 適合的場景 探索性測試 (Exploratory Testing)：發掘一些沒有明確定義在規格書上的行為，一些特殊場景下可能沒考慮到的問題。 可用性/易用性測試 (Usability Testing)：對於界面是否直覺、美觀，文字大小、排版、顏色、聲音等測試。 臨時/隨機測試 (Ad-hoc Testing) 小型的專案 - 可能沒有自動化的時間及預算。 新的功能 - 功能還在發展初期，會經常變化等。 頻繁更動的功能 - 雖然不是發展初期的功能，但還是可能時常大幅更動。 不穩定的功能 - 可能因為測試環境資源不足、第三方服務（理想上這要做 mock）等問題，而時好時壞（多嘗試幾次可能成功或不成功）的功能。 接著來聊聊自動化。  自動化測試 自動化測試通常是指相對於手動測試，透過程式、工具來執行預先定義好的測試步驟。目的同上，為了確認一切符合預期。 優點 準確、一致的執行測試步驟 不會遺漏任一瑣碎的步驟，在被自動化涵蓋的部分，有任何非預期的細微改動都能夠發現。 能大量的重複執行、不間斷的執行 如果一天之內有多次要確認操作行為都和之前一樣的改動，自動測試能穩定的執行，確保一切如常，沒有意外的影響。 相對可靠的結果。 缺點 初期建置的成本非常...
閱讀完整內容

💭 不分手動與自動，可能是成熟團隊的結果，而不是起點

如題，這篇是在說，不分手動與自動，可能是成熟團隊的結果，而不是起點。 ➼ 很多很猛的團隊不分手動和自動⋯⋯ 沒錯，不少成熟的測試團隊，其實不太會把手動測試和自動化測試劃分成兩種職位，而是要求團隊成員都具備一定的自動化、開發能力，依照需求去做不同的測試工作。 也因此，有些測試團隊在成立的初期，似乎就設定了一個目標：「不分手動和自動」。 這在產品穩定發展、大家能平平順順覆蓋核心場景時，其實都沒什麼問題，但是有些產品可能迎來幾次爆發式的成長，或是過去太順了，一直疏於建立自動化測試，終於有一天就掉進了回歸和手動的泥沼。 我後來覺得，如果今天的目標是「救一個已經陷入測試泥沼的團隊」，明確區分手動與自動，可能是一個有效的做法。 ➼ 先 align 一下認知 手動與自動化測試，本質上都是「測試」這一件事，不過它們分別適合產品與功能的不同階段。 手動測試比較適合負責緊急、零碎、現階段變動較大的工作，例如新功能初期的驗證、需要複雜裝置或網路設定等情境，以及需要一個真實的人類，根據實際狀況判斷「這個功能到底好不好」。 而自動化測試則適合保護關鍵業務邏輯、核心功能、CI/CD 中的 smoke test、覆蓋已經穩定的功能 E2E 流程與回歸測試；在功能開發初期，也可以從核心的 API 邏輯介入。 ➼ 掉進回歸、手動的泥沼 舉兩個我實際遇過的例子。 案例1 團隊為了推動自動化，把自動化測試的人員分散進各個 scrum team，希望每個人都能同時負責新功能的手動測試與自動化。 理想上，這應該會讓自動化更貼近產品。 但實際上，新功能一個接一個進來，手動測試有明確的時程壓力，自動化卻變成「有空再做」。最後不是自動化的人沒有能力做，而是根本沒有時間做。 久而久之，自動化工作開始不斷延期，原本負責自動化的人逐漸失去發揮空間。甚至由於被大量的手動測試工作消耗，選擇離開。 案例2 測試團隊的招募策略是廣招 Staff 等級、擁有很強工程能力的測試進來。 照理來說，這應該會發展成有完整可靠的自動化測試的團隊。 但結果卻是大家每天都忙著手動測試新功能。 因為沒有專門的人承接那些緊急、零碎、需要人工判斷的測試工作，所以每個人都被拉進手動測試的泥沼裡。最後反而變成一個很諷刺的狀況： 一群很會寫程式、也知道應該做自動化的人，卻沒有建立自動化測試。 「所有人都會自動化」和「團隊真的有能力持續建立自動化」，其實是...
閱讀完整內容