QA 2.0 – 會心派測試,釐清問題的新思路

by | Jan 4, 2024 | Software Testing

什麼是QA 2.0? 如果你聽過且理解Web 2.0,那你一定也知道QA 2.0想要做什麼。

Web 2.0是互動和分享,而QA 2.0則是更核心的「關係」和「溝通」

既然有2.0,那什麼是1.0,其實就是傳統測試的方法論,我需要做才能測更準、測更多、測更快,而QA 2.0要解決的,是傳統方法論無法解決的事情,是技術和效率提升都無法解決的問題,也就是人際關係與組織關係是如何影響軟體測試及軟體開發效率的。

未來的文章,我們都會透過小故事來帶著大家思考軟體測試。

故事:

Fabian擔任軟體測試工程師已經有1年的時間了,在他心裡一直存在著一個疑問,這天他決定到專門提供資訊技術的書局看看,想找找有沒有一種技術可以解決他心中的問題:為什麼每次都測不完?

Fabian所在的公司與團隊也不是小規模了,至少光測試團隊就有超過20個人,而且他還是年紀最資淺的,所以測試技術差,並不能夠說明為何每次的測試時間都不夠,最終只能直接發版,等待接受客戶的投訴和抱怨。

他走到專門賣軟體測試相關書籍的書櫃前,看著玲琅滿目的書不知從何挑起,索性用最簡單暴力的方法,一本一本翻。幾個小時過去,他已經接觸到各種軟體測試相關的技術,從品質的定義開始,看到AI在軟體測試上的應用,但仍然無法解答他的問題。

你知道這個問題的答案嗎?

 

引導:

身處於科技業的工程師,在思考事情上容易有一種慣性,那就是用技術來解決問題,因為技術是工程師可控的,而不可控的事情,因為不可控所以就不控了。而通常這些不可控的事情,往往都是跟人有關,而跟人有關的學問,就是社會學、心理學與經濟學,這也是大多數電腦科學背景的人所忽略的,畢竟在電腦的世界中,不是0就是1;不是true就是false,而人跟群體這樣複雜的東西,往往就像KPI被簡化成單一指標,有多少人力,多久能完成,需要多少資源,而忽略了人是多變的。

 

經驗:

我有一次參加面試,那是一間規模將近1000人的企業,由於我面試的是高階主管職位,因此是由研發部門的高階主管(M)與CTO(T)來負責面試我。

面試過程中,M問了我一個問題:「你要怎麼提升測試團隊的效率,並且降低離職率」。這個問題,基本正中會心派測試的領域,我就開始用會心派測試的理論快速講述了一遍,大概內容是:

我會去了解每一個測試工程師對目前的工作流程有什麼想法,過程當中與別的團隊合作遇到什麼樣的阻礙,從溝通面、流程面和制度面去根本性的改善造成軟體測試效率的問題……

而我還沒說完,M就打斷我的話:

「不不不,我想知道的是,你會用什麼樣的方法去讓我們原本需要三天的測試能夠縮減到一天,或是能讓測試工程師測試的Case變快變多」

這是典型的結果論導向思維,讓數字美化,就代表著效率的提升。我不以為然的回應:

「很多種做法都能夠應對這些指標問題,但如果只追求指標,會讓想要把控品質的測試工程師感到失望,這也就很難解決離職率的問題……」M又再一次的不等我說完就打斷我。

「要解決離職率還不簡單,我直接出絕招最快啊」我帶著滿臉的疑惑看著他

「我就規定每天早上九點上班,晚上六點下班,這樣大家都不會離職了啊」,當他這句說完,會議室裡的三個人都沈默了10秒,這時T才出來問了另一個題目,結束了一場鬧劇。

別問我當時的表情,那應該是我至今做過最無禮的表情。

 

 

點出問題:

敏捷和Scrum在科技業已經是蔚為流行,用快節奏的專案進度,來推動整個軟體開發團隊的效率。

從商業的角度來看,快速的迭代能夠應對急遽變動的市場,更快獲得市場反應,做更好的修正。但是在很多企業誤用敏捷與Scrum的情況下,這些流程只是要求成員在更短的時間做出更多的產出,因此從僱員的角度來看,並沒有一個更好的做法來應對時間的縮減,為了達成目標,只能選擇最快速的解法而非最適合的解法,這也造成了很多人的目標直接設定成縮短時間,而M面試官就是直接落入指標陷阱的受害人,甚至在離職率的分析上,直接挑選了最容易解決的問題當作問題的根本原因,而提出了一個可笑的解法。

 

解法:

當我們遭遇一個問題的時候,習慣於針對問題去解決,直接提出能夠讓這個問題消失的解決方案,卻忽略了問題發生的背後,是由諸多原因、限制和無奈所交織而成的,而這次的主題目標,就是要讓你在未來遇到問題時,尤其是頻繁發生的惱人問題,不要急迫的解決問題,需要冷靜的分析背後的真實原因。

以這次的課程來說,為什麼測試總是測不完?為何總是歸咎在測試的效率太低?這些是真正的問題嗎?實務上,常造成這些問題的原因如下:

      • 不恰當的專案時程安排,沒有考慮測試所需時間
      • 產品設計的變動性。雖然敏捷擁抱變化,但實務上有太多不受控制的變化了
      • 研發團隊的素質,無法應付專案安排的時間,總是延遲交付版本
      • 測試沒有排定測試項目的優先順序,容易造成嚴重問題在後期才被發現
      • 太多的隕石被安排進專案裡
      • 花費太多的時間在溝通和互相了解
      • 缺乏有效的溝通方式,只喜歡傳訊息,不喜歡當面溝通。

一起討論:

你可以參考你們的軟體開發團隊,在文章下方回覆你們的團隊可能的根本原因。

喜歡我們的內容嗎? 邀請您訂閱電子報

10 + 5 =

Similar Posts

除了「CrowdStrike到底有沒有做測試?」之外,你更應該思考的是這6個軟體測試思維問題

除了「CrowdStrike到底有沒有做測試?」之外,你更應該思考的是這6個軟體測試思維問題

2024年7月19日, CrowdStrike公司的更新引發的全球微軟Windows大規模當機事件,網路上在討論什麼?發現討論的焦點主要集中在以下幾個方面:開發者的軟體測試思維、分階段上線策略的缺失、軟體測試的必要性與局限性、敏捷開發與軟體測試的關係、自動化測試的爭議,但其實根本原因在流程!而不是測試!

「一日測試,終身測試」的正確解讀

「一日測試,終身測試」的正確解讀

註冊會員,取得Armoury測試管理系統的免費培訓課程 我們的Ticket Based Program跑了一段時間了,我們收到了很多人在軟體測試的相關問題,因此誕生了這個企劃,QA Q&A,當我們收到一些有趣的問題,不涉及企業機密的,我們就會考慮做成影片,放在官網上跟大家分享。 這次第一集就是要來討論一句老話: 一日測試終身測試是不是真的?這廢話啊,當然是真的啊,只是看你怎麼解讀而已。...

撰寫履歷要避開的六大陷阱,否則別想拿到面試機會

撰寫履歷要避開的六大陷阱,否則別想拿到面試機會

我們探討撰寫履歷時必須避開的六大常見錯誤,這些錯誤阻礙你獲得面試機會。從解釋空窗期的重要性、避免過強調過去的成就,到如何確保你的履歷既清晰又具針對性,每一點都是基於豐富的面試經驗和人才招聘實踐。還強調了履歷更新的重要性以及為何過分依賴Cover letter是個錯誤。此外,文章提供了具體建議,從而提高被邀請面試的機率。本文的實用建議都將助你避開讓你失去面試機會的履歷陷阱。