fbpx

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

by | Jan 4, 2024 | blog, Mandarin, Newsletter

什麼是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面試官就是直接落入指標陷阱的受害人,甚至在離職率的分析上,直接挑選了最容易解決的問題當作問題的根本原因,而提出了一個可笑的解法。

 

解法:

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

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

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

一起討論:

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

Similar Posts

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

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

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

The New Chapter in Software Testing Courses – Tickets Based Program

The New Chapter in Software Testing Courses – Tickets Based Program

KEENLITY is launching its innovative ‘Tickets Based Program’ for software testing, a unique blend of self-directed learning and professional guidance. This software testing course aims to enhance learning efficiency and provide precise learning directions while reducing time costs. Subscribers of the ‘Tickets System’ can pose questions about personal learning, software testing, Python development, and receive immediate, personalized responses from experienced professionals. Additionally, the program emphasizes balancing self-study with practical experience to aid students in advancing in the field of software testing.

軟體測試課程的新篇章 – Tickets Based Program

軟體測試課程的新篇章 – Tickets Based Program

KEENLITY鋒測科技正推出其創新的「Tickets Based Program」軟體測試課程,這是一種基於自主學習與專業指導相結合的指導模式。該計劃旨在提高學習效率,確保學生獲得精準的學習方向,同時減少時間成本。透過訂閱「Tickets System」,用戶可以提出有關個人學習、軟體測試、Python開發等問題,並從經驗豐富的專業人士那裡獲得即時且個性化的回答。此外,該計劃還特別強調在自學和實踐經驗之間取得平衡,幫助學生在軟體測試領域取得進步。