吾給力的部落格

分享這幾年在系統廠研發端Q的工作，常態的工作流程，順便註解抱怨一下BU內部其他部門XD

簡單解釋工作性質跟職稱的部分。

性質：屬於研發端(NPI)的部分，驗證範圍落在驗證"硬體/韌體/軟體"，三者之間相容性的部分。

跟純軟體or純硬體又不太一樣，是一種軟硬體跟韌體要通吃的狀態，主要確認零組件/整機產品賣出去，客戶自行組裝或整機可以穩定使用。

作業系統: Windows 跟 Linux 都要熟悉怎麼使用 (( 雖然我部門有十年以上資歷的老(ㄉㄨˊ)鳥(ㄌ一ㄡˊ)，Linux菜的跟什麼一樣

職稱：職稱這個部分挺有趣的，在不同系統廠的稱呼會出現不一樣的狀況。

常見就是QA ,QT , PQA , DQA 還有我覺得比較少見的CQA/E(Compatibility Quality Assurance/Engineer)
　　某個程度上來說簡稱中最後一字的T/A/E可以直接代換，習慣上稱呼的差異，反正統稱Q啦（包山包海）。

QA(Quality Assurance), QT(Quality Test)

DQA(Design Quality Assurance)

PQA(Product Quality Assurance)

跟工廠端的Q(QC)是不一樣的。

NPI工作流程 - New Product Introduction(3C業界常用的流程)：底下資料都是Google(參考別人比較完整的內容)並加上我自己的經驗跟見解。

下圖可知新產品開發的流程(NPI)，最主要﹝基本﹞是協助產品研發設計階段幫助RD找出問題、複製問題及釐清現象，讓RD能較輕易的解決問題。

進階的PQA/DQA就是要在EVT/DVT之前的時候提早驗出潛在問題、舊產品問題回饋/分析，讓RD提早因應問題做出處理或改善。

(我目前待的單位，同一個產品整個EVT->PVT並不是同個Team接手驗證，而是整個BU開發中的專案
，各階段拆分成時間區段的進測時程，依照人力去安排驗證的人員數量，每次專案進來驗證在GO的時候都有短時程的時間壓力
，中間要驗其他專案，而不是隨時可以複驗RD提供的Solution。
假設A專案，當時的人力分配下EVT需要5天、PVT需要25天，第5天驗完EVT→第6天換(B/C/D...etc)專案驗證→等A專案RD問題解的差不多之後，第31天才進測DVT，驗完EVT已經是第55天的事情了，因此釐清現象這件事情，只能有多餘的時間才會做。
通常EVT的機台比較不穩定，只要有發生異常都會提報問題，但某些Project Leader(RD Leader)會在Review Meeting上反問你為什麼一台發生就高光/提報問題，某些北爛北爛的RD或RDPM，因為Q提報太多問題，還反過來High Light Q亂驗…那又是另一個有趣的故事了)

比較進階的PQA/DQA：

重點就是負責EVT/DVT/Regression/BugFix階段的驗證需求，撰寫Test plan，schedule & sample數量安排、協調；建立標準實驗方法、品質工程文件之制定。

Before EVT：協助PM(RDPM)修正PES內容﹝看合理性及設備性能﹞、RD需要協助確認提供PES資訊﹝看頭看尾，有些比較懶的RD就隨便View﹞，以自身經驗協助RD、提出潛在問題、訂定有效的系統配置(Configuration)。

因為PES是由RDPM把SPM﹝Sales PM﹞跟RD討論過的開案需求從MRS上的紀錄轉成實際Design的規格，PES也就是產品規格的SPEC。

MP：以市場回饋之失效，建立失效模式，並且以此為基準建立標準實驗方法、品質工程文件及spec之制定，並將此做為lesson learn 課程報告與主管及RD。

EVT : Engineering Verification Test (工程驗證測試階段) 這個階段的產品都是工程樣品，是給研發工程師做debug及驗證用的。許多東西剛設計出來，問題還很多，甚至含有實驗性質的元件，研發工程師可能還在測試可行的設計方案，所有可能的設計問題都必須提出來一一修正，所以重點在考慮設計完整度, 是否有遺漏任何規格。 ﹝在這個階段，通常我是用最簡單的功能測試的方式去驗證不同韌體設定的搭配，檢查硬體功能設計是不是符合功能，甚至是用PVT的方法提前驗證滿規負載的狀況，協調測項平衡，檢視產品目前的可靠度跟穩定度，研究各種配置條件下使產品都可以符合Spec，負責實驗文件編寫、報告產出、提供客戶所要求的各項品質驗證技術與品質統計資料報告﹞   DVT: Design Verification Test (設計驗證測試階段) 這是研發的第二階段，所有設計的發想已經確定好該產品的功能變化跟功能。重點是要把更多潛在問題發掘出來，尤其是軟韌體之間的相容性是否穩定可靠。基本上測項會涵蓋EVT測項﹝HW改壞也不是不無可能的﹞並且增加許多韌體功能及軟體(作業系統)功能的項目驗證。另一個重點是把生產組裝可能會發生的問題找出來，確保所有的設計都符合規格.而且可以穩定進行生產；通常會有幾次的DVT Regression讓產品品質更好才進PVT。 ﹝在這個階段，我會用功能面的角度，去驗證檢視功能是不是符合設計，同時透過不同的作業系統與軟韌體設定去檢視產品的功能是不是完善，並負責實驗文件編寫、報告產出、提供客戶所要求的各項品質驗證技術與品質統計資料報告﹞   PVT: Production Verification Test(生產驗證測試階段) 這個階段的產品設計已經完成，所有設計的驗證也告一段落。試產的目的是要做大量產前的製造流程測試，所以必須要生產一定量的產品，而且所有的生產程序都要符合製造廠的標準程序，這個階段就完全交由工廠端的PE/QA(或MQA?)負責。 MP:  PVT階段順利完成試產後，產品進去MP階段。 MP之後就看市場回饋是不是針對客戶需求或是市場回饋失效的現象去進行回歸測試的驗證(Regression)

備註：我的經驗是，鮮少有EVT或DVT測完之後，又完整跑一次EVT或是DVT的狀況，除非HW Design功力太差，不然不太會遇到

，所以流程圖可能跟參考資料或是其他資料看到的不一樣。也有遇過Pre-EVT/DVT後才正式EVT/DVT的狀況，遇到的機率也是很低

至於有沒有NPI階段(ex: EVT階段)就偷賣的產品，也不是沒有經歷過ㄏㄏ，被凹的很慘阿~~~加班加到天荒地老

，通常是這個晶片組/平台系列的自家產品已經穩定之後(或refresh的機種)，比較有機會遇到。

參考資料：Google & 好車友偉恩寫的HWDQA 工作流程?  https://blog.xuite.net/waynegao/blog/585537205
延伸閱讀：提供幾個內容不錯，談QA工作內容的網站

1. QA只是測試？你知道他的完整名稱意思是「品質保證工程師」嗎？
不只是Tester, 淺談產品品質守護神QA https://progressbar.tw/posts/238
@QA通常是公司中最了解產品的角色，而為提升「事先預防，預先治療」的價值

2. 三種 QA (Quality Assurance) https://rickhw.github.io/2015/08/20/SQA/Three-Kinds-Of-QA/
＠雖然大部分的內容跟敘述角度是以SQA的方向出發，但其中一個觀點和我現在的情況蠻類似的
＂QA 不是只有找問題、Automation 這種表面的東西，QA 更多關注的是程序品質，確保程序能產出有品質的產出物。＂
現在單位的老闆對於"找問題、Automation 表面的數據或東西"特別在意，甚至是有種走火入魔到想要讓專案進測的數量多一倍、兩倍、甚至好幾倍的想法與做法。
舉例來說：前陣子同仁做了一個Automation Tool，號稱可以把好幾小時的測試操作，縮減到一個半小時，甚至一個小時內；但包含她的一階主管，在沒有檢視Automation Tool實際運作的過程和驗證結果，就盲目的導入驗證。；雖然有開個小型"讀書會"的方式解釋跟展示運作方式，過程中我有發問Tool運作上的問題與初步結果內容有些異狀，且問答中並沒有針對我的疑問點跟擔憂進行正面回應。等到排好Schedule並且專案也實際排入驗證後，接手驗證專案的同仁發現這個Tool導出的結果是有問題且是無效的結果，導致接手驗證這功能的同仁，改回手動驗證之外，還被壓縮到驗證的時間。