兩次項目出差的經驗總結

今年分別出差過青島銀行和興業銀行作現場測試支持，感受和公司裏產品仍是有蠻大的區別。

      剛入場時，有三點必定要再次確認下：

•    專門給測試的環境。 只給測試用，不能用做項目開發或者是缺陷修復。如今項目基本模式都是敏捷模式，測試入場時，只有部分功能塊已經提測，還有部分功能須要開發，因此必定要有3套環境才行，以避免缺陷修復的時候佔用測試環境。
•    提早告知提測條件（好比已經冒煙測試和聯調）後，在開發提測後，先走一遍冒煙測試。青島銀行時候是對方聯調過，可是後來代碼改動卻沒有再聯調，而興業銀行是根本沒有聯調，甚至部分功能都沒有單元測試。先走一遍冒煙測試能夠將各個功能塊的問題提早發現，讓開發修復，避免影響到測試進度。
•   若是有需求方面的疑問，在和項目經理溝通後，必定要再找行方確認下。全部的需求變更都要找行方確認，哪怕是字段名字的變化，否則銀行人員仍是會顯示下存在感。
•   現場的項目git和公司的已經分開，包括各個依賴包， 以避免公司開發人員對依賴包這些基礎功能的改動引入問題。

     測試過程當中：

•      發現的缺陷天天都須要找個固定時間發給開發，並約定好修改時間。而後親自前往對方那邊再次確認，以確保缺陷分配給正確的人修改。
•     天天要詢問開發的進度，以確保後續測試不會由於進度中斷。
•     若是必要的話，仍是要提醒下開發，新包先部署到開發環境，而後在上面冒煙下今天要測試的內容，若是ok，才准許部署到測試環境。項目中常常存在開發迷之自信，爲了節省時間，代碼不自測就提交打包。

   測試結束後：

•        項目到後期後，大部分開發都已經結束了開發工做，若是這時候第一輪功能測試還未結束。能夠建議項目安排人員優先對未測試功能聯調，若是人員富餘，能夠安排開發人員以冒煙測試的形式進行迴歸測試，若是能按照測試的用例進行迴歸測試，那就更好了。
•     第一輪功能測試結束後，必定要在進行一輪迴歸測試。
•    若是時間還有，那就看狀況對測試範圍外的我方新增改動進行測試。