什麼是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面試官就是直接落入指標陷阱的受害人，甚至在離職率的分析上，直接挑選了最容易解決的問題當作問題的根本原因，而提出了一個可笑的解法。
解法:
當我們遭遇一個問題的時候，習慣於針對問題去解決，直接提出能夠讓這個問題消失的解決方案，卻忽略了問題發生的背後，是由諸多原因、限制和無奈所交織而成的，而這次的主題目標，就是要讓你在未來遇到問題時，尤其是頻繁發生的惱人問題，不要急迫的解決問題，需要冷靜的分析背後的真實原因。
以這次的課程來說，為什麼測試總是測不完？為何總是歸咎在測試的效率太低？這些是真正的問題嗎？實務上，常造成這些問題的原因如下：
-
-
- 不恰當的專案時程安排，沒有考慮測試所需時間
- 產品設計的變動性。雖然敏捷擁抱變化，但實務上有太多不受控制的變化了
- 研發團隊的素質，無法應付專案安排的時間，總是延遲交付版本
- 測試沒有排定測試項目的優先順序，容易造成嚴重問題在後期才被發現
- 太多的隕石被安排進專案裡
- 花費太多的時間在溝通和互相了解
- 缺乏有效的溝通方式，只喜歡傳訊息，不喜歡當面溝通。
-
一起討論:
你可以參考你們的軟體開發團隊，在文章下方回覆你們的團隊可能的根本原因。
