近期，一個測試朋友遇到了關于測試排期的問題哩都，簡單聊下自己的想法。
問題：
組織架構是這樣的内列，項目開發(fā)和產品同屬一個部門杭煎，測試屬于一個部門恩够，各自有各自的領導。
由于開發(fā)質量很差羡铲，例如簡單的從數據庫顯示數據到頁面的功能蜂桶，三四個頁面，能有40+bug也切，重新激活的bug也有6個+扑媚，所以測試估期就比較長。
結果項目負責人兩次打回測試的估期雷恃，讓重新排期疆股，測試同學其實感受到了項目負責人的意思，但是沒有主動與項目負責人和自己的領導溝通褂萧。
結果今天測試同學與自己的領導面談押桃，才發(fā)現(xiàn)項目負責人已經與自己的領導抱怨過好多次了，于是測試同學說明了原因，領導才恍然大悟唱凯，并告知了測試同學的解決方案羡忘。
先拿著每個迭代的bug數和重新激活數，與項目負責人委婉地談一談磕昼，讓項目負責人下次適當把控下提測質量卷雕，不行可能要打回了。
其次票从，往下3個迭代漫雕，都按正常提測質量來估期，萬一時間不夠峰鄙，拿著bug數浸间，直接讓整個項目組看，并延期交付吟榴，堅持三個迭代魁蒜，如果每次都這樣，以后估期就可以長點了吩翻，如果改善了質量兜看，皆大歡喜，以后正常估期狭瞎。
個人建議：
在測試估期的過程中细移，一般遵循的原則：測試時間為開發(fā)時間的1/3左右，最多不要超過1（當然特殊情況除外）熊锭。
測試排期的長短弧轧，取決于測試同學的效率，業(yè)務的復雜度球涛，提測質量和開發(fā)同學修復Bug的速度等等劣针。
在實際估期過程中，先按正常的項目質量和人力配合程度來估期亿扁，如果出現(xiàn)了如上所說的提測質量差等問題捺典，在執(zhí)行的過程中，反饋出來从祝，讓大家都看到問題襟己，即使后續(xù)項目延期了，項目負責人也可接受牍陌。
但是擎浴，如果測試同學一開始就將各種風險因素例如質量差，評估在自己的測試時間里毒涧，對于個人和整個測試團隊都是不利的贮预，因為項目負責人看工期，大多數時候會忽略質量問題，只會從業(yè)務復雜度和測試效率去考慮仿吞，如果很簡單的功能滑频，由于質量問題估期很長，項目負責人一般首先質疑的是測試效率唤冈。
這種是涉及到部門利益的問題峡迷，拿著數據，及時反饋你虹，是很有必要的绘搞。
所以以上的解決方案：先拿著數據去找相關負責人聊質量問題，其次正常估期傅物，用3個迭代來驗證是否可行夯辖，是不錯的解決方案。
ps：我是lc馨馨紫董饰，全網名稱統(tǒng)一楼雹，期待優(yōu)秀的你關注我~
原創(chuàng)文章，轉載請注明出處~
