質(zhì)量保證組職責(zé)說(shuō)明

質(zhì)量保證組（簡(jiǎn)稱：質(zhì)保組）一、目標(biāo)協(xié)助研發(fā)對(duì)項(xiàng)目周期中產(chǎn)生的相關(guān)文檔進(jìn)行評(píng)審，展開(kāi)內(nèi)測(cè)工作，保證部門(mén)整體管理及產(chǎn)品質(zhì)量品質(zhì)的提升.二、主要職責(zé)1、作為研發(fā)與需求、UE、測(cè)試的統(tǒng)一接口人，起到溝通協(xié)作、承上啟下的作用2、負(fù)責(zé)對(duì)需求部提交的需求規(guī)格說(shuō)明書(shū)進(jìn)行評(píng)審；3、負(fù)責(zé)對(duì)UE部提交的高保真/低保真、通用規(guī)則進(jìn)行評(píng)審；4、負(fù)責(zé)對(duì)測(cè)試部提交的測(cè)試用例進(jìn)行評(píng)審；5、負(fù)責(zé)對(duì)測(cè)試部提交的Bug進(jìn)行確認(rèn)；6、參與需求變更的評(píng)審工作，負(fù)責(zé)將變更內(nèi)容及時(shí)、有效地反饋給研發(fā)，并負(fù)責(zé)跟蹤需求變更在研發(fā)的對(duì)應(yīng)情況；7、負(fù)責(zé)在提交測(cè)試部測(cè)試前根據(jù)項(xiàng)目情況進(jìn)行功能走查或功能測(cè)試。三、職責(zé)流程圖質(zhì)保組職責(zé)流程圖需求部UE部研發(fā)組質(zhì)保組測(cè)試部需求規(guī)格說(shuō)明書(shū)審評(píng)的檔文類測(cè)試用例發(fā)起需求變更發(fā)起需求變更發(fā)起需求變更發(fā)起需■求變更發(fā)起需求變更制控更變求一需求變更發(fā)送需求變更通知mailI收到需質(zhì)保組職責(zé)流程圖需求部UE部研發(fā)組質(zhì)保組測(cè)試部需求規(guī)格說(shuō)明書(shū)審評(píng)的檔文類測(cè)試用例發(fā)起需求變更發(fā)起需求變更發(fā)起需求變更發(fā)起需■求變更發(fā)起需求變更制控更變求一需求變更發(fā)送需求變更通知mailI收到需芋更通知反饋研發(fā)*1跟蹤需求變更情況交提不試測(cè)認(rèn)確查走能功或測(cè).內(nèi)測(cè)或走查回歸Bug提交Bug—-—一提交Bug確認(rèn)Bug有疑問(wèn)―分配技術(shù)經(jīng)理—分配、11日分配研發(fā)人員修改Bug按bug處理流程繼續(xù)任務(wù)說(shuō)明：1、各類文檔的評(píng)審目前暫定采用問(wèn)題跟蹤表的形式（后期考慮轉(zhuǎn)移至Jira中，以實(shí)現(xiàn)問(wèn)題的統(tǒng)一管理、確認(rèn)及跟蹤，具體的流程定義待定）以所有問(wèn)題全部確認(rèn)關(guān)閉為原則。2、需求變更控制需求變更的發(fā)起：由需求自發(fā)產(chǎn)生由UE在設(shè)計(jì)高/低保真時(shí)產(chǎn)生，由研發(fā)在設(shè)計(jì)或編碼時(shí)產(chǎn)生，由測(cè)試在編寫(xiě)用例時(shí)產(chǎn)生需求變更的反饋:a）發(fā)起人直接與需求人員進(jìn)行問(wèn)題的溝通及確認(rèn)；b）若需求發(fā)生變更，需求人員發(fā)送變更通知的mail必須抄送給質(zhì)保組；c）質(zhì)保組將需求變更的mail轉(zhuǎn)發(fā)給相應(yīng)的研發(fā)人員，若是由研發(fā)人員發(fā)起可省略該步；d）質(zhì)保組需要跟蹤需求變更的對(duì)應(yīng)情況.需求變更的跟蹤：考慮使用Jira進(jìn)行管理，具體的流程定義待定3、夕卜測(cè)Bug的處理流程測(cè)試部提交Bug;Bug會(huì)自動(dòng)先分配給質(zhì)保組（各服務(wù)單元對(duì)應(yīng)質(zhì)保組成員名單在測(cè)試前會(huì)發(fā)送給測(cè)試經(jīng)理，配置在bugzilla中，不需要手動(dòng)進(jìn)行該步驟。）;質(zhì)保組接收到分配給自己的Bug后，首先確認(rèn)Bug的有效性；a）判斷為無(wú)效的、無(wú)法重現(xiàn)、需求變更的Bug需要跟Bug的提交者進(jìn)行溝通確認(rèn)，確認(rèn)后，直接將Bug置為已解決，解決途徑選擇相應(yīng)選項(xiàng)，并在備注中說(shuō)明已經(jīng)與何人進(jìn)行了確認(rèn)，確認(rèn)結(jié)果及原因；b）判斷為重復(fù)的Bug,需要跟Bug的提交者進(jìn)行溝通確認(rèn)，確認(rèn)后，直接將Bug置為已解決，解決途徑選擇已修復(fù)在備注中說(shuō)明已經(jīng)與何人進(jìn)行了確認(rèn)，確認(rèn)與哪一個(gè)Bug重復(fù)；判斷為需要修改的Bug，質(zhì)保組將Bug分配給技術(shù)經(jīng)理，有必要時(shí)可以補(bǔ)充相應(yīng)的備注說(shuō)明，在標(biāo)題處以"[***『開(kāi)頭標(biāo)識(shí)Bug的缺陷類型；技術(shù)經(jīng)理接收到分配給自己的Bug后，進(jìn)行Bug修改的判定，a）判定為需要修改，則根據(jù)Bug的優(yōu)先級(jí)、嚴(yán)重度，綜合評(píng)估目前研發(fā)人員已分配Bug的對(duì)應(yīng)情況，將Bug進(jìn)行二次分配給具體的研發(fā)人員；b）判定為決定不改、稍后再改的Bug,直接將Bug置為已解決，解決途徑選擇相應(yīng)選項(xiàng)，并在備注中說(shuō)明原因；研發(fā)人員對(duì)分配給自己的Bug進(jìn)行調(diào)查對(duì)應(yīng)a）對(duì)應(yīng)修正完畢，自測(cè)沒(méi)有問(wèn)題后，將Bug置為已解決，解決途徑選擇已修復(fù)，在備注中說(shuō)明修改內(nèi)容，若缺陷類型定義有誤需要修改；b）調(diào)查后對(duì)Bug有疑義的，可以再與質(zhì)保組溝通，根據(jù)實(shí)際情況判定解決途徑。測(cè)試人員會(huì)根據(jù)計(jì)劃對(duì)已解決狀態(tài)的Bug進(jìn)行回歸確認(rèn)

a）確認(rèn)沒(méi)有問(wèn)題，測(cè)試人員會(huì)將Bug直接置為已關(guān)閉；b）確認(rèn)存在問(wèn)題，測(cè)試人員會(huì)將Bug重新打開(kāi)，并在備注中說(shuō)明返回的原因,研發(fā)人員接收到返回給自己的Bug后，重復(fù)執(zhí)行步驟⑥附：缺陷類型缺陷類型說(shuō)明Bugzilla中如何對(duì)成的補(bǔ)充說(shuō)明【需求】未明確定義需求中沒(méi)有明確的定義，導(dǎo)致實(shí)施結(jié)果與測(cè)試用例不符此類Bug，置為需求變更，請(qǐng)跟蹤需求進(jìn)行補(bǔ)充或修改，需要在備注中補(bǔ)充說(shuō)明【需求】描述不清需求中有相關(guān)定義，但是理解會(huì)產(chǎn)生歧義，導(dǎo)致實(shí)施結(jié)果與需求不符【功能】正常系邏輯錯(cuò)誤基本功能按照正常業(yè)務(wù)流程進(jìn)行使用，出現(xiàn)錯(cuò)誤此類Bug需要修改【功能】異常系邏輯錯(cuò)誤進(jìn)行異常系測(cè)試，發(fā)現(xiàn)的功能性錯(cuò)誤【功能】功能點(diǎn)遺漏需求中有明確定義，但是沒(méi)有實(shí)現(xiàn)【功能】關(guān)聯(lián)模塊錯(cuò)誤在測(cè)試A模塊時(shí)發(fā)現(xiàn)了關(guān)聯(lián)模塊B的問(wèn)題此類Bug需要重新分配給關(guān)聯(lián)模塊的負(fù)責(zé)人進(jìn)行修改【功能】JavaScript錯(cuò)誤進(jìn)行操作時(shí)，頁(yè)面拋出JavaScript錯(cuò)誤此類Bug需要修改【界面】格式校驗(yàn)錯(cuò)誤【界面】提示信息錯(cuò)誤【界面】界面不一致【界面】低/高保真錯(cuò)誤高保真或低保真本身存在錯(cuò)誤，即不符合需求或通用規(guī)則此類Bug，置為需求變更請(qǐng)跟蹤低/高保真進(jìn)行了修改或補(bǔ)充需要在備注中補(bǔ)充說(shuō)明【界面】與低/高保真不符實(shí)現(xiàn)的結(jié)果與低/高保真的設(shè)計(jì)不相符此類Bug需要修改【界面】框架、組件錯(cuò)誤此類Bug需要重新分配給框架或組件的負(fù)責(zé)人進(jìn)行修改【界面】瀏覽器錯(cuò)誤相同的功能在A瀏覽器下可用，但B瀏覽器下不可用時(shí)使用?！窘ㄗh】易用性錯(cuò)誤建議級(jí)的Bug不一定要當(dāng)時(shí)進(jìn)行修改，此類問(wèn)題需要與組長(zhǎng)討論后冉做決定，涉及到需求、UE的地方，【建議】功能錯(cuò)誤需求中定義的父互或功能存在微不足道的問(wèn)題，不修改也

不會(huì)對(duì)整體功能產(chǎn)生影響，由組長(zhǎng)溝通后反饋給研發(fā)和測(cè)試人只是建議進(jìn)行修改員。【建議】功能點(diǎn)遺漏需求中沒(méi)有定義，提出的問(wèn)題微不足道，不修改也不會(huì)對(duì)整體功能產(chǎn)生影響，只是建議進(jìn)行追加【標(biāo)準(zhǔn)】不符合通用規(guī)則需求中沒(méi)有明確定義，但是通用規(guī)則中有定義，而實(shí)現(xiàn)的結(jié)果與之不符此類Bug需要修改【其他】接口問(wèn)題【其他】環(huán)境問(wèn)題【其他】DB問(wèn)題【其他】性能問(wèn)題【其他】其他所有類型均不能準(zhǔn)確定義該Bug類型，需要在備注中補(bǔ)充說(shuō)明，以便后續(xù)缺陷類型的補(bǔ)充4、內(nèi)測(cè)的形式根據(jù)項(xiàng)目的實(shí)際情況安排測(cè)試計(jì)劃對(duì)比測(cè)試方式功能走查功能內(nèi)測(cè)測(cè)試依據(jù)需求跟蹤矩陣需求規(guī)格說(shuō)明書(shū)側(cè)重點(diǎn)大體基本功能是否實(shí)現(xiàn)功能操作是否拋出異常或錯(cuò)誤基本業(yè)務(wù)流程能否走通需求中要求的業(yè)務(wù)規(guī)則實(shí)現(xiàn)完整且正確；進(jìn)行異常系的測(cè)試；從需求、功能、界面等各方面進(jìn)行測(cè)試，