壹家公司看準了壹個產品市場，準備去做研發了，那麽，市場部的人員會做市場調查，看看用戶對於這種產品的需求是什麽。這時候QA就要介入進來，***同reivew這份需求，我給這份需求書起個名字?MKR?。研發部門會根據MKR來制定公司的產品規格書。從制定公司產品的spec開始，QA就需要介入了。QA需要站在終端用戶的角度來考量這份spec所定義的東西是否符合用戶的使用習慣，是否符合行業標準，是否與業內通行的默認的潛規則壹致，等等。如果QA認為有任何的錯誤，都應該及時向研發部門提出異議，這樣才能從最初期保證產品的質量。要知道產品的致命缺陷通常都是因為設計理論本身就有問題，導致後端開發人員無法彌補，而最終產生嚴重後果。在這點上，QA需要積極地與PM合作，推動研發部門改正不合理的設計方案。做為家用消費類產品，我們要以終端用戶的使用習慣為最終的要求。
在spec制定出來以後，QA就要投入到緊張的工作當中。在研發人員開發的同時，QA需要制定出test plan和test case。
這項工作需要與項目經理和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需要問清楚優先級和工程師的難處，盡量解決，這樣才能達到良好的協調。協調好了，工作效率會更高。