近期工做中的問題總結

       問題1：對於項目開發時間節點的分歧

       當咱們一塊兒開項目立項會議時，開發人員每每根據代碼量來評估時間節點，給出的解釋通常也是技術上是否有難度，代碼量是否大，而測試人員是從測試的複雜度來 評估，因此有時候會出現比較大的分歧。好比開發人員認爲工做量很小，而測試人員認爲業務複雜，和別的模塊交互比較多，測試工做量大。

       解決方案：

       團隊內部須要評審測試用例，這樣開發人員能夠理解測試的工做量。而做爲測試人員，應該在閒暇時間積極的補習coding方面的知識，儘量地去理解並參與到團隊的討論中。

       問題2：敏捷式開發的弊病

       敏捷式開發的一個原則是但願團隊集中在一個或兩個功能模塊上，完成後再轉移到下一個功能模塊，爭取價值的最快交付，但帶來的問題是每一個模塊之間，彼此之間有依賴關係，你們不得不等待。而對測試人員來講更是痛苦，須要測試不少中間產物，測試量顯著增長。

       解決方案：

       版本控制與項目時間節點的掌控應該更加嚴格，好比某個時間節點應該完成那些功能須要嚴格的執行，測試應該在功能完成的時候開展新一輪的測試，功能沒有完成以前，更多的應該是對於已經實現的功能的迴歸及驗證。

       問題3：每一個迭代週期後期，滯留大量測試任務

       目前常常出現的狀況是每一個迭代週期後期，滯留大量測試任務。若是這個時候發現了不少問題，開發人員也不得不加班修復。爲了解決這個問題，一方面整個團隊要 慢慢培養一個共同的意識：只有測試工做結束了才意味着這個用戶故事真正結束了；另外一方面，若是一個用戶故事計劃用少於一週的時間能完成，但實際上在第5天 站立會議上評估仍然完成不了，就要加派人手，集中力量保證它的進度。若是是由於技術難題陷入困境，能夠留下一個或兩我的員繼續攻堅，其餘人員就要及時撤離 出來，以保證其餘的用戶故事能正常進行。

       解決方案：

       爲 瞭解決這個問題，一方面整個團隊要慢慢培養一個共同的意識：只有測試工做結束了才意味着這個功能模塊真正結束了；另外一方面，若是一個功能模塊計劃用少於一 周的時間能完成，但實際上在第5天在晨會上評估仍然完成不了，就要加派人手，集中力量保證它的進度。若是是由於技術難題陷入困境，能夠留下一我的員繼續攻 堅，其餘人員就要及時撤離出來，以保證其餘功能模塊能正常進行。

       以上爲工做中遇到的問題，而對於創建QA部門以後測試工做如何高效的開展有如下幾點建議：

       1.測試在需求確認以後就開始介入，根據項目經理肯定的計劃時間節點作出合理的測試計劃，在單元編碼階段完成測試用例的編寫及評審。

       2.經過禪道與內測分發平臺進行版本控制，開發人員須要3天提交一個新版本（須要與開發人員商議決定版本迭代時間，理想爲3天）。

       3.新版本提交以後，測試人員須要完成對新版本bug的驗證，測試用例的執行及新版本bug的發現工做（在下一版本以前完成）。

       4.測試人員須要推進研發進度，嚴格按照項目時間節點完成任務。

       5.測試人員跟進的項目不宜過多，才能保證測試的質量。

       6.在後期給客戶提交版本時，應該對總體流程進行測試，保證不會出現顯而易見的問題。

       7.提交bug時，務必選擇正確的模塊類型和bug類型以及bug嚴重等級，便於bug管理及研發肯定解決bug的優先級。

       8.測試過程當中要作到"五個大於"，即計劃大於執行，覆蓋率大於執行率，記錄大於操做，再現大於發現，評估大於總結。

       最後，總結起來，測試在工做上要主動詢問，態度上不能輕易妥協，習慣上要善於記錄細節，方法上軟硬兼施。