怎麼安排內建測試工作

靈活是沒有內建測試環節的，但大部門要求停下新功能開發，做兩周的內建測試，是以，這個沖刺我們也沒有安排開發任務。

以往內建測試怎麼搞？

按照以往的經驗，全員測試，從內建測試開始，每人每天必須提10個BUG，第二周5個，第三周3個。看到的效果就是，內建測試BUG多，很有成果，并且随着時間的推進，BUG在收斂！哈哈……人為收斂！

我的工作安排

我讓部門内兩位資深的測試分成兩個組，全員參與內建測試，并讓她們拿出測試計劃、範圍、分工、用例、規則等

到了晚上，結果出來了

計劃：

采購轉固單、實物卡片、财務卡片、變更單、清理單、調撥單、基礎資料

——孫春豔 周豔 周健 司彥濃 清茂 李亞勇

計提折舊 月結 報表

——龍倩 駱佳 趙詣 勃然 志超

遺留任務：

趙詣參與的代碼模型改造

勃然和清茂繼續月結改造内容；

需求同學同時要兼顧規劃概要工作；

測試同學保證用例完整性；

規則：

第五階段遺留BUG在12月1日前清零，有困難的及時提出；

所有同學發現量至少為每天1個BUG，該要求隻是提醒大家要主動測試；

16:00前提的BUG，個人遺留達到3個，考慮BUG分攤和加班處理；

項目經理每天16:30，按人頭發出BUG發現量、BUG修複量

我看了以上分工，感覺很粗糙，範圍是一坨，資源是一坨，這樣的分工根本沒有辦法考核到人，要如何考核呢？

這時，我想到了以往的做法，即：BUG發現量。我終于了解為什麼以往內建測試都是以BUG發現量為考核名額了！原因是，大鍋飯不容易統一名額，是以就以BUG發現量為考核名額。

以BUG發現量為考核名額的壞處我覺得不用多說

- 隻為了應付數量，而忽略了更有價值的BUG

- 以BUG發現量作為結果導向，而不是産品品質作為結果導向

不成熟的想法

這樣安排工作比較簡單，起初我也想這樣做，并且提出兩點改進

1.全員參與，開發人員也要提BUG

2.借助每日例會，根據大家手頭任務情況，推算測試投入并确定每日計劃發現量（投入低/中/高：開發1/2/3；需求1/3/5；測試3/5/8）

這樣做就結合了靈活，既不至于一刀切，不用隻盯着數量，又能對結果有預期。

我自認為這個想法很棒！

改變想法

我把這個想法和項目經理溝通後，項目經理持反對意見，她認為這樣做，隻關注到人，而不是任務；并且她提出，靈活關注團隊，而不是個人——我清楚，這是靈活的說法！我也知道，她說的是不對的！

我認為，上述概念錯誤的原因如下：

1.靈活是沒有內建測試沖刺周期的

2.KPI都是要明确到人的，該講求團隊速率的時候，就要講求團隊速率，該明确到人的時候，就不能吃大鍋飯

現在是要說服一個人的時候了！

每當我要說服一個人時，我都會本能地先考慮一下我們共同的目标，那就是：內建測試要切實地提升産品品質。

對全員要求BUG發現量的做法，不論是一刀切也好，或是立會時動态計劃也好，其實都是以數量為導向。以數量為導向，這就有違內建測試的初衷——以提升産品品質為導向

那麼，我們應該怎麼做呢？

目前我們的做法

我以前是做開發的，內建測試偶爾也會要求開發人員測試産品。如果這個功能是我做的還好，但大部分都是維護别人幾年前做的産品。當時的我，既不懂業務，又不懂流程，我能測出來什麼？于是，隻能裝模作樣地點一點産品，其實我什麼BUG也找不出來。

* 第一個結論就出來了：開發人員參與産品測試，能力很有限

作為開發人員，難道對産品品質一點促進的能力也沒有嗎？答案是絕對否定的！

* 第二個結論就出來了：開發人員參與內建測試是可以提升産品品質的

其實，開發人員是擅長一些測試的，哪些呢？比如，字段規則、字段間邏輯、資料反寫等，需求文檔中每一個點原本就是開發實作的，也是要開發自測的，這部分内容由開發保證品質，再合适不過了！

是以，要想讓開發人員進行産品測試，就要：

1.給開發人員安排非常具體的任務

2.像對待測試新手一樣，耐心地給開發進行指導

3.提供必要的文檔及資料

經過以上思考，我提出如下方案：

1.開發人員負責功能測試或簡單流程測試，業務負責測試用例及複雜流程測試

2.功能測試包括：字段邏輯、菜單操作、按鈕操作

3.測試負責人重新制訂計劃表：按單據+功能為顆粒度拆分，明确到人

4.讓開發人員交叉測試，即誰開發的單據，就讓另一個人測，避免慣性思維

4.測試人員逐漸完善測試用例：測試用例要與上述文檔相對應，并按上述文檔将測試用例明确到人

5.測試人員要對開發的用例進行抽檢

目前做法的好處是

責任明确到每一個人，隻關注結果

長遠來看，測試人員逐漸解放，不需要從流程到細節全關注

長遠來看，開發人員在開發過程也會逐漸養成自測的好習慣