在測試過程中，經(jīng)常遇到需要和RD、PM溝通的問題。
1、寫case時(shí)，對(duì)需求文檔內(nèi)容存在疑問。
解決辦法：
1）先找之前參與需求評(píng)審的QA，詢問；
2）問開發(fā)該需求的RD：查看RD排期，是否已經(jīng)，或即將開始開發(fā)，若RD未開始開發(fā)，很多時(shí)候，他們也不是很了解需求內(nèi)容。
3）若影響case的編寫，可在企業(yè)微信上，直接問PM。若問題較多，可直接找PM當(dāng)面詢問。
4）若不影響case的編寫，可在case里做標(biāo)記，在case評(píng)審時(shí)拋出，請(qǐng)PM回答。
2、在開始測試的前一天，找RD確認(rèn)是否能正常提測。有時(shí)RD反饋無法正常提測。
解決方法：
1）一定要確認(rèn)影響提測的原因，如果當(dāng)前自己排期內(nèi)可消化，可在與其他RD溝通，并在自己排期內(nèi)做調(diào)整。
2）一定要確認(rèn)可以提測的時(shí)間點(diǎn)，如果是由于server端導(dǎo)致delay，是否可以讓端上RD給個(gè)入口，端上先mock數(shù)據(jù)先測。
3）若端上或server有delay，一定要告知直接領(lǐng)導(dǎo)。
4）delay有可能導(dǎo)致風(fēng)險(xiǎn)，一定要及時(shí)拋出，若需要報(bào)risk，一定告知RD，一定及時(shí)在Jira提risk。
5）若嚴(yán)重delay，且server或端沒有配合盡快解決，可邀請(qǐng)領(lǐng)導(dǎo)加入微信群，催促大家盡快完成；若問題非常嚴(yán)重，可邀請(qǐng)領(lǐng)導(dǎo)的領(lǐng)導(dǎo)加入微信群（謹(jǐn)慎邀請(qǐng)），催促大家盡快完成。
3、在測試過程中，遇到RD無法解決的bug，同時(shí)無法解決的bug數(shù)量不多。
解決辦法：
1）告知PM：bug詳情、RD反饋無法解決。
2）若PM表示不修改，則在Jira上對(duì)應(yīng)的bug上備注并關(guān)閉bug（備注中要標(biāo)明具體PM）。
3）若PM表示要修改，在企業(yè)微信上拉群：QA、RD、PM，在群里告知該問題，@RD和@PM，反饋實(shí)情，讓RD和PM商量，并給出最終結(jié)果。
4、在測試中，若遇到RD無法解決的bug，同時(shí)QA感覺該問題比較影響體驗(yàn)，可告知PM且與PM達(dá)成一致后，拉微信群，@RD，反饋bug，讓RD修改。
5、若QA感覺需求設(shè)計(jì)有問題，可與RD達(dá)成一致后，與RD共同反饋給PM。
6、在測試中，遇到RD無法解決的bug，同時(shí)無法解決的bug數(shù)量較多。
解決辦法：
1）將問題一一統(tǒng)計(jì)，在企業(yè)微信上拉群：QA、RD、PM，在群里告一一拋出問題，@RD和@PM，反饋實(shí)情，讓RD和PM商量，并給出最終結(jié)果。
若遇到特殊情況：
1）很多bug，RD反饋無法解決，PM反饋要修改，但RD和PM僵持不下，沒有結(jié)果。
2）有的bug，QA感覺嚴(yán)重影響體驗(yàn)，但RD反饋無法解決，PM反饋當(dāng)前版本不修改。
3）當(dāng)前需求無法解決問題太多，嚴(yán)重影響用戶體驗(yàn)。
4）若嚴(yán)重delay，且server或端沒有配合盡快解決。
解決辦法：
1）告知直接領(lǐng)導(dǎo)當(dāng)前情況。
2）發(fā)郵件：列表格，將各個(gè)bug一一記錄，加上RD的反饋，和PM決定當(dāng)前版本是否修改，將表格添加到郵件中，在測試結(jié)束前，發(fā)郵件，郵件里@RD和@PM，使其在某個(gè)時(shí)間點(diǎn)前作出回復(fù)確認(rèn)當(dāng)前情況。郵件抄送給直接領(lǐng)導(dǎo)、QA全員。
3）如果問題很嚴(yán)重：嚴(yán)重影響用戶體驗(yàn)，告知直接領(lǐng)導(dǎo)當(dāng)前情況，找明明說明當(dāng)前情況。
4）可邀請(qǐng)領(lǐng)導(dǎo)加入微信群，督促大家盡快處理當(dāng)前問題；若問題非常嚴(yán)重，可邀請(qǐng)leader加入微信群，督促大家盡快處理當(dāng)前問題。
8、在參加需求評(píng)審前，先閱讀一遍需求文檔，如果有疑問，需要記錄下來，可在wiki的需求文檔上直接對(duì)有疑問的地方備注提出問題，在參加需求評(píng)審時(shí)，直接提出，問PM。
若在需求評(píng)審上，有未確定的內(nèi)容，在需求評(píng)審的checklist上，是否通過一欄，填寫：“未通過”，并備注未通過原因，以及未確定的內(nèi)容。需求評(píng)審后繼續(xù)跟進(jìn)，督促PM對(duì)會(huì)上未確定的內(nèi)容作出解答，或開二次評(píng)審，需求上有更改、添加、刪除的內(nèi)容，督促PM在wiki上做相應(yīng)的更改。
9、在測試過程中，PM作出的需求更改、需求添加，都要及時(shí)督促PM更新到wiki文檔上。
10、向RD詢問bug引入原因的時(shí)候（尤其是以前沒有該bug，最近都沒有對(duì)該部分作出修改，但是測試中發(fā)現(xiàn)了該bug），有些RD不配合查找bug引入原因。
溝通方法：
1）一定耐心告知RD“查找bug引入原因”的目的，不要引起誤會(huì)。
2）一定不要和RD產(chǎn)生爭執(zhí)。
3）從RD和QA的利益共同點(diǎn)出發(fā)，詳細(xì)告知我們這么做的目的，以及我們的收益，和最終希望達(dá)成的效果。
11、在測試過程中，即使是需求小改動(dòng)，也要告知直接領(lǐng)導(dǎo)，只要沒有排期，不允許上線及測試，沒有排期不允許修改。
12、RD在代碼上作出的修改，是否免測由QA說了算：
1）有些RD會(huì)告知沒有影響，無需測試；
2）有些PM告知他已驗(yàn)收，無需測試；
以上2種情況都不可，是否免測由QA說了算。
