今天無意中看到一位先輩寫的有關QA的帖子，覺得很好，所以複製下來收藏。
總有些朋友問我什麼是QA，不知道QA到底是做什麼。其實我也沒辦法用一個純理論的言語來解釋什麼是QA。把我自己的理解與經驗與大家分享吧。QA其實是品質管理。爲什麼說是管理呢？因爲QA結合了管理，分析和測試三大行業的知識。公司的研發進度，產品研發初期的標準制定及產品後期的研發都需要QA的參與，缺一不可。QA可以有效的控制研發的進度和每個環節的質量。不管任何的產品，都是以適合人使用爲前題的。在產品初期制定設計標準的時候，QA能夠站在消費者的角度來看待這個產品，讓產品更人性化。設計階段，QA成爲一個測試者，驗證每一個環節的質量，是否達到了設計標準所規定的。用當局者迷，旁觀者清來形容再貼切不過了。QA就是這個旁觀者。任何產品不可能十全十美，出了問題，設計者不可能一一來查找問題，因爲很難有單獨一個人完成整個產品設計，這時候QA就是一個分析師，查找在哪部分出了問題，節約研發的時間，解決不必要的麻煩。任何的公司都有自己的產權，而QA能很好的保護公司的產權。健全的公司，QA有很大的權力控制公司的所有技術資料。任何設計工程師不可以私自給客戶公司的技術資料，這些管理都是由QA來完成的。
如果想成爲一個成熟的QA需要經過三個階段的成長期。
首先，先讓自己成爲一個優秀的測試者。有靈活的頭腦，用逆向思維來思考如何做測試。不能做到與常人不同的角度去想問題，就不可能成爲一個好的測試者。應廟畢業生最適合做測試者，這時候的人如一張白紙，什麼也不懂，需要做的是按照自己想的方式去測試你手上的東西，不用考慮這樣操作是不是會把產品弄壞，如果你弄壞了，我要恭喜你，你成功的成爲了一名測試者。優秀的測試還需要有良好的記憶力，你每做的一個操作都要記住了，萬一產品出現問題，你能找到發生的規律。做爲一個測試者，還需要有良好的表達能力，要能將自己看見的現象描述清楚。有些人天生就對文字表達不擅長，但沒關係，描述bug是有一定規則的。以下提供一個我經常使用的格式：
測試環境，軟件版本，硬件版本，測試時間，此項測試的申請人。記錄這些的目的是爲了快速準確的找到相對應的人與開發環境。方便問題重現。
說明此bug是隻出現在一個版本上，還是所有的版本都會出現，出現的機率是多少，大概出現在哪個產品模塊。
將操作步驟寫清楚。此點並不容易描寫清楚，給個建議，你不需要用太多麻煩的描述，只需要列出每一步做了什麼，用最簡單的語言描述你當時所做的操作，最好用列表式，用數字排列出步驟的先後順序。
列出問題點，只需要寫出現象，不需要做過多解釋，這樣更容易讓看報告的人明白。
如果你做到了用逆向思維方式不約束的頭腦去測試，用超強的記憶力，記錄下自己所做的步驟，用敏銳的觀察力去發現每一個不起眼的異常，用簡單清楚的語言描述bug，那麼你就是一名優秀的測試者了。
在成爲一名優秀的測試者後，不要滿足喔，你還沒成爲真正的QA，你還需要具有分析問題的能力。這個需要時間和精力來完成，沒有捷徑，只有努力纔可以達到。但也是有方向的，向大家指個方向。QA需要了解大量的專業知識，除了要讓自己瞭解公司所有的規格標準技術資料外，更應該讓自己成爲一個博學者。每個人能力有限，博學不代表要精通，但至少要知曉相關知識的大概。QA的分析能力與經驗有相當大的關連。QA需要長時間來積累自己的經驗，積累經驗也有要領的。每次出現一個問題，都要去問爲什麼，爲什麼問的越多，經驗就越多，你會在爲什麼中不知不覺的成長。一般五年是QA的一個階段，五年內，QA需要默默的學習，積累紮實的基本功和經驗，如果你做到了，五年後，你將發現，你成了奇缺人材。
最後一點要說的是管理。QA需要管理自己內部的資料，也需要管理整個研發團隊的。首先要做到的是，QA需要有正直的人品，不要因爲任何的外界的因素而改變自己對公司產品的嚴格要求，要勇敢地說不，對不合格產品嚴格地打回去重新做。其次，QA需要有完善的體系來管理工作。每家公司各不相同，但我認爲需要以下幾個方面體系：
工作記錄。此測試是何人完成的，何人申請的，進度如何，完成時間，要嚴格控制記錄，如果出了問題方便找到相關的人，不是爲了讓誰去擔這個責任，是爲了能更快的解決問題。當然也有對測試者的約束力，要讓每一個QA知道，要對公司負責。我通常採用一個工作記錄表格，個人認爲還有一個好處是給QA和其他部門的同事看。當QA全部在忙，研發工程師們可以內部自己調整case的重要性，暫時pause或者delay某個任務，調整工作，讓QA的工作更有效率。
Test Case管理系統。這個需要一個小型數據庫，將每一個測試項目詳細記錄下來，測試者可以將自己的經驗變成文字寫在裏面，讓後來者可以爲之所用，提高QA團隊的整體力量。每一個Test Case都必須根據公司的設計規格書和行業標準來編寫，通過此，測試者也可以更瞭解公司產品的標準。
Bug管理系統。這個系統可以便於QA上報bug，研發工程師能很快的去解決，也可以幫QA控制產品的研發進度，push研發工程師按進度解決問題。也可以根據此來制定每一個版本的release時間表。
Code mangerment. 一般的公司都有這種工具，就不需要我來特別說明了，通常用的是Perforce和CVS。說明一點的是，有些公司對code管理比較亂，客戶打個電話code就release出去了。不成熟的產品出去了，會讓客戶覺得這家公司的產品爲什麼如此差勁。所以如果要對公司好，就一定不可以隨便開放權限。健全公司的做法通常release全部由QA發佈，最後再由相對應的客戶服務經理髮給客戶。畢竟公司的面子最重要。
其實對於管理方面我也只是在學習摸索，也不太清楚，先寫這麼多吧，以後我將給大家講一講具體產品方面的QA知識。
每一種工作在一家公司都不是無故存在的，都會有它的作用存在。通常在面試中，都會被問到，QA在公司產品研發中的作用是什麼，當然我也會常常問求職者這樣的問題。那QA的作用到底是什麼呢？不是一個非常重要就能概括的，今天這篇短文，總結一下，我認爲的QA的作用，純屬個人觀點，希望大家共同討論。因爲我做的是家用消費類電子產品，所以就以這種產品爲例，寫一下我的觀點。
一家公司看準了一個產品市場，準備去做研發了，那麼，市場部的人員會做市場調查，看看用戶對於這種產品的需求是什麼。這時候QA就要介入進來，共同reivew這份需求，我給這份需求書起個名字‘MKR’。研發部門會根據MKR來制定公司的產品規格書。從制定公司產品的spec開始，QA就需要介入了。QA需要站在終端用戶的角度來考量這份spec所定義的東西是否符合用戶的使用習慣，是否符合行業標準，是否與業內通行的默認的潛規則一致，等等。如果QA認爲有任何的錯誤，都應該及時向研發部門提出異議，這樣才能從最初期保證產品的質量。要知道產品的致命缺陷通常都是因爲設計理論本身就有問題，導致後端開發人員無法彌補，而最終產生嚴重後果。在這點上，QA需要積極地與PM合作，推動研發部門改正不合理的設計方案。做爲家用消費類產品，我們要以終端用戶的使用習慣爲最終的要求。
在spec制定出來以後，QA就要投入到緊張的工作當中。在研發人員開發的同時，QA需要制定出test plan和test case。
QA如何制定test plan呢？
這項工作需要與項目經理和design team的人使用共同完成。首先，我們需要從PM那裏得到project schedule，根據schedule來制定QA的test plan。test plan包括產品測試的具體內容，release schedule，release test plan and schedule, code management，QA的工作流程和參與人員的工作安排與職責。
test case是一個非常詳細的工作，我就不在這說明了，這需要經驗，根本也不是三言兩語可以說得清楚的，但可以介紹一下大的方向。寫test case的宗旨是讓測試變得最簡單，看case的人哪怕完全不懂，是個新手，也能按照case去完成測試的工作，並且給出測試結果；儘量減少人爲的經驗因素帶來的影響，將需要測試的方面，和有可能被忽略的方面都要寫進去，讓case成爲一個衆人經驗的集合，達到case的最大功效。
當然test plan制定以後不是一直不變的，需要大家一同來review，而減少QA本來有可能帶來的失誤，因爲是人都會有想不到的，有犯錯誤的時候。這個就需要QA與PM和design team的人去溝通，需要大大小小很多的review meeting來解決。這個時候千萬不要怕麻煩，這個時候偷了懶，危機就在後面等着你。這時候會遇到很多困難，design team的人通常很難合作，因爲對於那些研發工程師來說，這種meeting是非常討厭的，肯定會排斥。但就是被排斥，得不到合作，也不可以放棄，QA應該堅持自己的原則，這裏就會考驗到一個人的溝通能力了。
上面的工作都做完了，QA會得到小小的休息時間。按步就班的做事，開始跟着PM和研發進度走。到了產品研發成熟期，客戶會出現，這時候，QA又會起到重要的作用。在這裏提一下，有些健全的大公司，把QA分成了兩個team。與研發部門合作，只做產品研發測試的development QA，與客戶打交道，接受客戶投訴，幫客戶產品質量把關的customer QA，我們公司在發展的後期，就出現了CQA和DQA。如果說公司QA分成這兩部分，那麼QA的工作就變成更爲複雜。
DQA的使命只是維護研發期的產品質量，我們把這種產品叫reference design products，而CQA的使命是維護客戶的產品質量。
不管是在產品的研發中，還是在客戶產品的質量維護中，QA還有一個重要的職責，就是推動力，QA要成爲工程師們工作的推手。人都有惰性，不要期望每個人都自覺地努力工作。QA的通常做法是，每週給出一個進度報告，做一次bug review。通常研發部門的工程師非常討厭這種會議，那沒辦法，我給大家一個小方法。QA把每目前嚴重的問題分列出來，詳細到把每個負責的工程師所屬的bug全部列出來，告訴工程師們這些bug需要被fixed時間，然後羣發email，當然不要忘記CC給老大們喔，這樣纔夠power。當然，態度不可以太強硬，最好在郵件結尾加一句，如果有困難，可以提出，meeting中商量。通常都會有人接受meeting。一個研發工程師手中通常不會只有一種產品，那麼就會有衝突的時候。QA需要問清楚優先級和工程師的難處，儘量解決，這樣才能達到良好的協調。協調好了，工作效率會更高。不過，有些公司，把這類工作交由PM來做，但本人認爲，推動公司的產品質量朝更好的方向發展，是QA義不容辭的責任。
整理這些也不容易，我目前只想到這麼多了，以後想到再補充吧。下次我會詳細給大家介紹QA的工作流程。
