一、提交測試后的代碼改動導(dǎo)致線上BUG
- 在迭代開發(fā)之前榕堰，應(yīng)該更深入了解需求與更仔細(xì)的設(shè)計(jì)技術(shù)方案奸焙，爭取在提測前一次做對刀荒。
- 在提測后遇到需要更改的部分時(shí)，應(yīng)該暴露問題友雳，組內(nèi)進(jìn)行技術(shù)與影響范圍評估，如果不必要，則在下次版本優(yōu)化曼追，必要?jiǎng)t郵件提交給測試。
二汉规、測試時(shí)間節(jié)點(diǎn)不明確
- 測試須在提測前2天提供完整的測試用例礼殊。（根據(jù)兩周一迭代計(jì)算）
- 測試須要提測前4天進(jìn)行測試用例評審驹吮。（根據(jù)兩周一迭代計(jì)算）
三、UI評審不及時(shí)
- UI須在提測前2天開始評審并在提測前完成評審晶伦。
四碟狞、提測成果不完整
- 開發(fā)在獲取測試用例后的2天，進(jìn)行高優(yōu)先級測試用例自測和功能模塊互測婚陪，并將測試缺陷與UI評審缺陷全部修復(fù)族沃。
- 開發(fā)在提測當(dāng)天或前一天，在測試面前進(jìn)行功能演示泌参。
五脆淹、BUG修復(fù)不及時(shí)
- 測試須備注BUG的優(yōu)先級。
- 無特殊情況沽一，開發(fā)須每日根據(jù)優(yōu)先級順序清空名下BUG盖溺，避免阻礙第二天測試工作。
六铣缠、溝通不足導(dǎo)致需求缺失咐柜、無人認(rèn)領(lǐng)
- 開發(fā)、產(chǎn)品攘残、UI之間的協(xié)作須拒絕口頭協(xié)議拙友，以郵件或wiki的方式抄送存檔。
- 測試無須跟蹤BUG進(jìn)度歼郭，但是須將BUG指給正確的人遗契，如果不知道，指給對應(yīng)的開發(fā)負(fù)責(zé)人病曾，由負(fù)責(zé)人分配牍蜂。
- BUG相關(guān)責(zé)任人（無論是直接還是間接），須對問題跟進(jìn)到完全解決為止泰涂。
- 高優(yōu)先級的問題鲫竞，與問題相關(guān)的所有人討論解決（開發(fā)、測試逼蒙、BA）从绘，討論結(jié)果wiki存檔。
- 低優(yōu)先級的問題是牢，每日晚上匯總僵井，第二天晨會統(tǒng)一提出，站會后拉相關(guān)責(zé)任人一次解決驳棱，提升效率批什。
七、需求評審不充分導(dǎo)致后期工作指數(shù)增加
- 需求評審階段的結(jié)束標(biāo)志：需求問題清空社搅、技術(shù)難題方案調(diào)研結(jié)束驻债、UI圖完整乳规。
- 需求評審階段達(dá)成的共識：UI、測試合呐、開發(fā)驯妄、BA對需求有充分的了解與有完整的文檔輸出，后續(xù)的更改都需同步文檔合砂。
八青扔、文檔中UI圖與原型不符合問題
- UI在設(shè)計(jì)圖須完全按照原型。
- 在需求評審結(jié)束后的一切UI改動翩伪，須以增量的方式在wiki更新微猖。
- 如果需要提升效率，可以在給對應(yīng)的開發(fā)提供UI之后缘屹，每日晚上更新文檔凛剥。
九、部分功能的測試步驟復(fù)雜
- 開發(fā)遇到一些需要管理后臺修改數(shù)據(jù)的操作轻姿，可以找相關(guān)測試尋求幫助犁珠。
- 如果無法操作，須在代碼層使用全面的模擬數(shù)據(jù)進(jìn)行單元測試互亮。
