莉亞不會變身

我面試新人的時候一定會問的兩個問題

一、 你覺得測試的工作是什麼樣的?
二、 你覺得一個好的QA要具備什麼樣的條件?

很多人都覺得測試工作很簡單，其實要簡單也可以很簡單

要難也可以無限上綱的去抓出毛病

所以我要聲明!!!測試不是那麼簡單的，如果只是反射的重複性操作，那個就不是QA了是作業員...

一、你覺得測試的工作是什麼樣的? 什麼是QA??

QA（QUALITY ASSURANCE，就字面上來翻譯就是“品質保證”

一個產品為什麼值得被人一買再買?? 因為品質好嘛~~那什麼是品質呢?

1. 信賴度：不良率在容許出錯的範圍內

2. 售後服務：當出現問題後，是否能快速的解決問題

3. 特殊功能性：一台手機除了能打電話之外，商人紛紛想出各種不同的複合式功能來完善客戶的隱形需求

4. 外觀質感好：質感美觀也很重要，還要越便宜越好

5. 可靠度：越耐用越好

身為一個專業的QA

1. 最基本要做到的：我們要做的工作就是幫RD找出他開發設計的缺陷問題

2. 不是只是照本宣科跟著PM給出來的規畫走
應該要把自己當成使用者的角度去思考這個設計點是不是符合人性

3. 可以主動提出問題，協助PM去完善產品的功能
更要幫使用者想到隱形需求，因為user常常只知道自己不要什麼，但他也不知道自己要什麼

你知道嗎
QA有分三種

第一種：獨立的 QA 部門
這種 QA 單位，技術、與領域知識並重，是完整的營運單位。

缺點：
溝通成本較高

第二種：掛在 R&D 底下的 QA
通常是以技術導向的。這類的 QA 要懂技術，會寫 Code，懂得自動化工具。依照不同產品性質，需要條件如下：

產品本身就是技術性產品，通常這類的 QA 需要具備一定程度的領域知識與專業能力，知道很多實際的使用情境。
產品本身是消費性的，例如電商網站、人資系統，大部分 QA 不需要具備專業知識，就可以入門。
如果要做自動化相關，不管哪一個領域，都要一定程度 QA 才行。

在這樣單位底下，通常RD會用技術導向來看 QA 這件事情，而看不到程序問題。
這種單位的用人，習慣性的會問用什麼 automation tools、什麼程式語言，而不是問 QA 在整個開發流程扮演怎樣的角色、怎麼有效回報問題、怎麼溝通、組織與分析問題、測試方法、測試管理 (Test Management) … 。

缺點：RD說了算，QA容易被忽視，也最容易被放在資遣的第一波

第三種：附屬在 PM 底下
掛在 PM 底下的 QA，其實應該叫 QC，很多時候是 PM 兼著做，因為 PM 要測了才知道產品長怎樣。
工作以產品內容的商業邏輯確認為主、專注的不是技術，需要很清楚產品的內容、需求規格、流程等。
技術性質的工作則會倚賴 RD 單位。

缺點：外行領導內行，忽略QA的專業

二、 你覺得一個好的QA要具備什麼樣的條件?

1. 耐心：測試工作有時候會遇到重複性的狀況
如果容易失去耐心，有時候會因為重工的關係導致測項會不小心被忽略

2. 細心：簡單來說就是敏感度要夠

覺得怪怪不太合理的部分，記得勇於提出問題
這點是很重要的，發現任何問題一定要提出來
 

3. 堅持：有時候明明知道不合理的事情，記得要堅持 (但也不要太鑽牛角尖，這邊要拿捏有點難，我也還在努力學習中)

4. 良好的人際溝通技巧：除了技術面上的專業能力之外，也要搞好人際關係，對RD對PM的溝通技巧也是很重要的

5. 理解力要好：邏輯要清楚，有時候我們會遇到不夠明確的需求規劃書，我們必須去釐清基準點在哪裡，通常QA必須是最清楚公司產品邏輯的人。

6. 表達能力：除了口頭上的溝通之外，QA有時候會需要寫一些文件、SOP和測試案例

  6.1 寫文件：你必須清楚明確知道寫文件的目的、為了什麼而寫，這樣才能減少溝通成本

    有方向之後，用容易懂的方式條列式去寫出簡單扼要、如何言簡意賅的文章
    雜亂沒有章法、沒人看得懂的文章不如就不要寫了，文章如果有寫得不夠清楚的地方代表你不夠熟悉系統

  6.2 回報BUG：回報BUG不外乎就是你必須寫出

    發生的狀況

    預期的結果

    如何重現你測試的手法：提供LOG、測試環境或者更明確的參考資訊更好

    描述必須明確、簡單扼要、注意代名詞，避免雞同鴨講的狀況 (有時候你說的這個"它"，會不會跟RD的角度的"它"不一樣呢?)

7. 抗壓性要高：有時候要等RD開發完畢才能驗證BUG，其實回到第一點，這也很考驗耐心

8. 可獨立作業

9.  英文能力：有些公司會要求英文能力啦，畢竟有些SPEC是原文的，如果連設計邏輯看都看不懂了怎麼驗證

結論：

如果你都不具備以上條件

測不好沒關係，顏值要高。起碼上班起來賞心悅目(誤)