《BUG建立&观念介绍_modify字型课件.ppt》由会员分享，可在线阅读，更多相关《BUG建立&观念介绍_modify字型课件.ppt（57页珍藏版）》请在三一办公上搜索。
1、PLM Bug System Introduction,Dis LeeTest TeamTest Engineering DepartmentR&D Division,2,Whats your favorite APPLE?,3,How about our Customers&Products?,You need to know the truth:Requirements will be different for each model!,4,Project Objectives,You need to know the truth:ERS 只是產品要求的最低標準而非全部.,5,1,5,4,
2、3,2,什麼是Bug?哪兒來?如何類別?,Bug Life-cycle Flowchart,Bug如何追蹤?(系統Step概念),Bug System應用(Feedback),Bug System使用介面,報告主題,6,結語:,系統是死的,人是活的.是人讓系統發揮作用共識並非天生,而是需要持續不斷的教育訓練&要求,才有機會觀念一致,唯有在”同一共識”下,Bug系統方可達到其最大效益.所有系統的通則:Garbage in then garbage out!,7,Q&A,8,1.什麼是Bug?“蟲”?,就公司專案階段而言:MP(Mass Production)前,屬於此專案之objectives目
3、的達成前所遭遇之問題點皆屬之.誰是開Bug的人?專案Team所有成員皆可.目前PLM Bug系統僅來自QE部門&系統測試部執行驗證所遇到的問題點 那其他屬於專案之問題點到哪裡去了?,專案階段與異常處理方式,問題點整合系統直是專案開發重要的環,如何運用現有的Bug System來輔助PL&PM專案control與管理,是重要的課題.,10,Bug如何類別?,以嚴重性區分:-Critical,Major,Minor 三類以發生頻率區分:-Always,Often,Sometimes,Seldom四類以設計開發範圍或測試範圍區分:-Safety,Reliability,Function,Perfor
4、mance,Usability,Image,Appearance,Avisions Policy,Error-Handling,Document.等十類.,11,Bug開立目的,For 專案:藉由系統驗證單位所規劃的test,在產品送交或大量生產時,及早對產品瑕疵作矯正與預防性對策,以增加專案成功機會.避免Rework or Repair層出不窮,導致Cost up!For 組織:藉由Bug發生引發出的管理issue 重複發生or 顯而易見&技術瓶頸issue Design Limitation 做一有效的feedback動作,使組織針對此些項目做有效改善,以達到持續向上的趨勢.,12,2.B
5、ug Lifecycle Flowchart,1,2,3,4,5,6,7,13,3.PLM-BUG Step概念(Trace Bug用),Step 關卡名稱0.1 BUG_發起通知0.2 BUG_PL分配工作0.21 EDM-原申請人修改 0.25 BUG_是否為會議同意放行0.26 BUG_PM審核0.27 BUG_填入BUG預計解決日0.3 BUG_工程師處理BUG 0.31 BUG_直屬主管審核1 BUG_QE工程師確認2.2 BUG_主管審核,任何Bug皆要處理,只是該用何種方式處理,但絕非不處理.任何Bug皆有其黃金處理時間,若擱置過久未處理,將無助於專案performance,透過
6、專案管理人員與系統稽催機制來有效協助專案(系統本身有報表機制可方便專案管理者使用),14,1.根據結案處理者單位,每2 weeks分別做統計以mail方式寄給部門主管參閱.2.部門主管可依其下工程師常犯的錯誤來加以進行improve operations.每季統計一次,召開meeting方式讓R&D主管與VP參閱.每月統計一次,寄給專案PM&PL參考(Judgment Skill Learning)&驗證單位主管,以作為modify Test Plan的參考資料.每week統計一次,驗證單位主管需召開meeting檢討,並應予立即改善.作表monitor,並要求每次機種驗證必需將此testca
7、se納入確認.,4.Bug System應用(Feedback),15,開立個新Bug(流程Step 0.1)專案PL收到Bug-處理模式(流程Step 0.2)工程師對策-處理模式 流程Step 0.3)上階主管Review 工程師對策內容 流程Step 0.31)Bug驗證-處理模式 流程Step 1)Bug Closed Feedback 流程Step 2.2),5.Bug System使用介面,16,PLM BUG系統-主畫面介紹,主功作區,物件功能區,搜尋區,主工作區,物件功能區,物件訊息區,系統訊息區,簽核區,我的文件區,17,開立個新bug(“New”的概念),Create Bu
8、g選擇“NEW”,18,開立個新bug(“下拉式選單”概念)(不可修改,未來改成以下:1.Critical2.Major3.Minor,19,開立個新bug(“下拉式選單”概念)(可修改 例外,可允許 Free Key-in(若有需要),20,開立個新bug(“下拉式選單”概念)排列組合“亂”,未來改成以下:1.Always2.Often3.Sometimes4.Seldom,21,開立個新bug(Bug描述是開立時最重要關鍵),此項有規定格式:請參閱BUG敘述參考要點,22,1.Settings:Mode:Resolution:Paper size:Application:2.Procedu
9、res:Step01:Step02:、3.Result&預期的正確結果:4.補充說明:包含您做了哪些DOUBLE CONFIRM,還有哪些線索給RD、,Detail Description 參考要點:(將必要之關鍵資訊紀錄),23,Examples:Bug Description,24,開立個新bug(簽核流程在此設定),選擇False:表示BUG是由STD提出由STD驗證選擇True:表示BUG是QE提出由QE驗證,25,“Finish”系統自動產出一個編號,建立BUG後需做Submit,方可進入流程中,需做修改編輯選Edit,若有“圖檔”或”相關補充資料”可藉此將檔案上傳至PLM,開立個新
10、bug(Bug No.,輔助資料上傳&Submit),26,開立個新bug(完成開立個Bug),Submit至會簽流程,選擇Close後Bug建立完成會通知Project相關人員,27,專案PL收到Bug的處理模式,PL收到Bug時有4個choices:選擇1:需工程師分析與改善,進入Edit填寫分配工程師人員 Step 0.3選擇2:Bug敘述不夠清楚,直接sign-off,退給測試工程師修改 Step 0.1選擇3:會議決議需走“特結”流程 Step 0.26選擇4:因某特殊原因,需將“PL分配工作”這權限Reassign給某人,所有處理模式皆需Bug上所敘述之問題情況來做選擇!,28,編
11、輯完成,編輯指定處理工程師工號 點Value Set帶出姓名2.可以輸入員工姓名 關鍵字或完整的員工姓名查詢 範例：王小明 查詢方法：*小*或 王*,PL指定權責單位,可填寫一個單位以上co-work,PL選擇1:Assign工程師處理Bug PL分配工作 Step 0.2,29,選擇 Signoff作簽核動作,選Complete則BUG流程至Step 0.3,PL選擇1:Assign工程師處理Bug PL分配工作,30,PL選擇2:Reject給測試工程師修改 Bug描述有瑕疵時,即 Reject 作用,直接退回給測試工程師修改,簡單扼要說明退回理由,31,PL勾選BUG Review會議同
12、意放行必須與“會議紀錄”建立關聯.卡關條件,PL選擇3:會議決議“特結”不需經工程師處理程序,PL需將此項目打勾 系統Default=不勾,Bug會循“特結”流程處理,常遇到的問題點:勾選會議同意放行,但未有會議記錄佐證,32,(3)專案工程師收到Bug 時,3個處理模式:,處理模式1:是我該處理的Bug 先進入Edit填寫“Bug預計解決日”系統default=14天 工程師自行確認已fix此Bug,再填寫其真因&對策.sign-off後選擇”Complete”即完成處理模式2:不是我部門該處理的Bug 直接sign-off,選擇”Unable to complete”並寫下 comment
13、後,退回給專案PL.處理模式3:因某種因素須reassign給同單位之其他工程師處理 直接sign-off,選擇”Reassign”輸入其他工程師工號 在comment欄位說明理由,33,1.註明輸入者（中文全名）系統會帶出日期。2.註明DRIVER與F/W在哪一版所解。(若因code架 構無法確定未來是哪一版,就可skip此需求),Sign-off完成選擇”Complete”,處理模式1:注意事項),作用:系統會依填入日期做基準點,再過14天後會發提醒通知.限制:同帳號僅可編修一次,34,(4)直屬主管Review自己工程師對策內容 Step 0.31,贊成 工程師原因分析&對策,模式1,模
14、式2,模式3,不認同 工程師原因分析&處理對策但須寫出不認同之理由,授權給他人執行此關卡,35,(5)收到bug需驗證時,測試工程師處理模式 Step 1,處理模式1:需要執行驗證Bug 先釐清真因,暫時對策與有效對策內容上作法&邏輯錯誤.將”待確認”的Bug之情形加以review,若有目前測試cases 無法涵蓋之Bug,需將其整理列表使其成為下版驗證時首先 確認項目.(對於非Always發生的Bug需進行Test規劃)執行下版驗證後,若Pass則填寫驗證相關資訊且sign-off後 選擇”Approve”即完成 若Failed,則依處理模式3進行.處理模式2:不需要執行驗證Bug conf
15、irm理由(若此資訊是未傳遞至驗證單位時),若屬實則將 理由填入後,sign-off選擇”Approve”即完成.處理模式3:因某種因素須Reject退給PL 對策Failed or 結案理由不合理(需將理由清楚說明)未將Bug原因&對策交代清楚處理模式4:因某種因素須reassign給同單位之其他工程師處理 測試resource arrangement 個人職掌變更,36,Who you are?Which version?Check method?Result?,作業畫面,編輯完成選擇Signoff填寫相關資訊。如果驗證失敗選擇Reject流程至PL重新分配工作。,37,Bug Close
16、d Feedback 流程Step 2.2)QE主管&測試部主管有此權限,Bug最終approve 流程:專案決議必須是合理邏輯下之決策.站在公司整體利益為第一優先角度思考,此對策仍成立.無存在潛藏之重大risk.由專案角度轉變成組織角度思考此bug,38,嚴重性區分:,39,發生頻率區分,注意事項:發生頻率之判定常與測試手法與心態有所差異,故需更注意開立Bug前,測試工程師所做的測試細節部份.發生頻率資訊在R&D工程師Debug手法及效果確認上,也是有所差異的.“sometimes”發生的bug,R&D工程師如何確認自己所下的對策是有效的?,40,以設計開發範圍或測試範圍區分:,41,Fun
17、ction類 Bug,對於產品本身宣告或承諾客戶該達成之功能未達到基本要求標準.,42,Usability類 Bug,對於使用機台者而言,有操作上不手順或機台本身設計邏輯行為不符合般預期.,43,Image類 Bug,對於基本之scanner該有的影像品質加以確保,可以分為可量化之影像規格與Visual-Check.,44,Appearance類 Bug,會導致使用者抱怨的機台外觀問題(破損髒污);有時與時間軸會有關係.(脫落or掉屑),45,Avisions Policy類 Bug,公司內部爲特殊理由規定產品必須符合某公司內規,如Energy Star(能源之星)&USB-IF Logo C
18、ertification取得.,46,Safety類 Bug,涉及法規類之規定,通常會讓產品遭遇重大打擊,導致無法出貨或Rework issue發生.,47,Reliability類 Bug,經過溫溼度效應或模擬shipping狀況實驗下,導致機台因元件受損使得機台基能下降或失效情形發生.,48,Performance類 Bug,因提供之功能是不穩定,導致使用者需要花更多時間去做check動作,或重scan一次.,49,Error Handling類 Bug,設計研發未對機台本身運作&使用者錯誤使用行未做出該有的反應與訊息,有誤導使用者作出錯誤行為之虞或無法繼續執行job.,50,Docume
19、nt類 Bug,對於產品之相關文件有錯誤的情形發生.,51,Get More Information Flowchart,2,52,PLM Bug 開立 Flowchart,2,開立的時機與判定:,Now:目前機種之Functional SPEC皆無完整定義情形下 對產品功能產生懷疑,此Bug即成立.(Bug=值得探討的Question)在產品規格書中未將Functional SPEC納入以前,依此rule執行判定 未來:在機種規格完整定義條件成立狀況下 不符合 customers 需求與潛在需求時,此Bug即成立.依Functional SPEC判定)未定義的客人潛在需求的推斷 可討論,53
20、,Bug Review會議 Flowchart,01.Bug Review Meeting召開為專案PL的職責,故PL必須到場此會議方有召開的意義.02.會議何時結束是取決於“結果”而非“時間長短or 次數“,2,54,Bug 特結 Flowchart,2,BUG與會議紀錄建關聯是此流程必須達成的要求,55,專案Team處理 Flowchart,2,填入“預計完成時間“這動作將影響“系統稽催”的日期若填入日期為2008/10/22,但你未完成此關該完成的所有動作則請問2008/10/23 隔天 此bug會怎樣?,56,PLM Bug驗證 Flowchart,2,Release Test之流程是必要且對品質瑕疵risk最小的必要手段,57,PLM Bug結案Feedback Flowchart,2,
