每一種工作在一家公司都不是無故存在的，都會有它的作用存在。通常在面試中，都會被問到，QA在公司產(chǎn)品研發(fā)中的作用是什么，當然我也會常常問求職者這樣的問題。那QA的作用到底是什么呢？不是一個非常重要就能概括的，今天這篇短文，總結(jié)一下，我認為的QA的作用，純屬個人觀點，希望大家共同討論。因為我做的是家用消費類電子產(chǎn)品，所以就以這種產(chǎn)品為例，寫一下我的觀點。
　　　　一家公司看準了一個產(chǎn)品市場，準備去做研發(fā)了，那么，市場部的人員會做市場調(diào)查，看看用戶對于這種產(chǎn)品的需求是什么。這時候QA就要介入進來，共同reivew這份需求，我給這份需求書起個名字‘MKR’。研發(fā)部門會根據(jù)MKR來制定公司的產(chǎn)品規(guī)格書。從制定公司產(chǎn)品的spec開始，QA就需要介入了。QA需要站在終端用戶的角度來考量這份spec所定義的東西是否符合用戶的使用習(xí)慣，是否符合行業(yè)標準，是否與業(yè)內(nèi)通行的默認的潛規(guī)則一致，等等。如果QA認為有任何的錯誤，都應(yīng)該及時向研發(fā)部門提出異議，這樣才能從最初期保證產(chǎn)品的質(zhì)量。要知道產(chǎn)品的致命缺陷通常都是因為設(shè)計理論本身就有問題，導(dǎo)致后端開發(fā)人員無法彌補，而最終產(chǎn)生嚴重后果。在這點上，QA需要積極地與PM合作，推動研發(fā)部門改正不合理的設(shè)計方案。做為家用消費類產(chǎn)品，我們要以終端用戶的使用習(xí)慣為最終的要求。
　　　　在spec制定出來以后，QA就要投入到緊張的工作當中。在研發(fā)人員開發(fā)的同時，QA需要制定出test plan和test case。
　　　　QA如何制定test plan呢？
　　　　這項工作需要與項目經(jīng)理和design team的人使用共同完成。首先，我們需要從PM那里得到project schedule，根據(jù)schedule來制定QA的test plan。test plan包括產(chǎn)品測試的具體內(nèi)容，release schedule，release test plan and schedule, code management，QA的工作流程和參與人員的工作安排與職責。
　　　　test case是一個非常詳細的工作，我就不在這說明了，這需要經(jīng)驗，根本也不是三言兩語可以說得清楚的，但可以介紹一下大的方向。寫test case的宗旨是讓測試變得最簡單，看case的人哪怕完全不懂，是個新手，也能按照case去完成測試的工作，并且給出測試結(jié)果；盡量減少人為的經(jīng)驗因素帶來的影響，將需要測試的方面，和有可能被忽略的方面都要寫進去，讓case成為一個眾人經(jīng)驗的集合，達到case的最大功效。
　　　　當然test plan制定以后不是一直不變的，需要大家一同來review，而減少Q(mào)A本來有可能帶來的失誤，因為是人都會有想不到的，有犯錯誤的時候。這個就需要QA與PM和design team的人去溝通，需要大大小小很多的review meeting來解決。這個時候千萬不要怕麻煩，這個時候偷了懶，危機就在后面等著你。這時候會遇到很多困難，design team的人通常很難合作，因為對于那些研發(fā)工程師來說，這種meeting是非常討厭的，肯定會排斥。但就是被排斥，得不到合作，也不可以放棄，QA應(yīng)該堅持自己的原則，這里就會考驗到一個人的溝通能力了。
　　　　上面的工作都做完了，QA會得到小小的休息時間。按步就班的做事，開始跟著PM和研發(fā)進度走。到了產(chǎn)品研發(fā)成熟期，客戶會出現(xiàn)，這時候，QA又會起到重要的作用。在這里提一下，有些健全的大公司，把QA分成了兩個team。與研發(fā)部門合作，只做產(chǎn)品研發(fā)測試的development QA，與客戶打交道，接受客戶投訴，幫客戶產(chǎn)品質(zhì)量把關(guān)的customer QA，我們公司在發(fā)展的后期，就出現(xiàn)了CQA和DQA。如果說公司QA分成這兩部分，那么QA的工作就變成更為復(fù)雜。
　　　　DQA的使命只是維護研發(fā)期的產(chǎn)品質(zhì)量，我們把這種產(chǎn)品叫reference design products，而CQA的使命是維護客戶的產(chǎn)品質(zhì)量。
　　　　不管是在產(chǎn)品的研發(fā)中，還是在客戶產(chǎn)品的質(zhì)量維護中，QA還有一個重要的職責，就是推動力，QA要成為工程師們工作的推手。人都有惰性，不要期望每個人都自覺地努力工作。QA的通常做法是，每周給出一個進度報告，做一次bug review。通常研發(fā)部門的工程師非常討厭這種會議，那沒辦法，我給大家一個小方法。QA把每目前嚴重的問題分列出來，詳細到把每個負責的工程師所屬的bug全部列出來，告訴工程師們這些bug需要被fixed時間，然后群發(fā)email，當然不要忘記CC給老大們喔，這樣才夠power。當然，態(tài)度不可以太強硬，最好在郵件結(jié)尾加一句，如果有困難，可以提出，meeting中商量。通常都會有人接受meeting。一個研發(fā)工程師手中通常不會只有一種產(chǎn)品，那么就會有沖突的時候。QA需要問清楚優(yōu)先級和工程師的難處，盡量解決，這樣才能達到良好的協(xié)調(diào)。協(xié)調(diào)好了，工作效率會更高。不過，有些公司，把這類工作交由PM來做，但本人認為，推動公司的產(chǎn)品質(zhì)量朝更好的方向發(fā)展，是QA義不容辭的責任。
　　　　整理這些也不容易，我目前只想到這么多了，以后想到再補充吧。下次我會詳細給大家介紹QA的工作流程