今天下午，團隊開了一個簡短的版本總結會。會上測試經理分析了一個案例：某子程序在轉測試後發現不能被平臺調度，原因是子程序的調度入口跟不符合平臺規範。很明顯開發在轉測試前沒有充分自驗證，測試經理提出，後續對跟平臺對接的子程序轉測試必須要有將子程序接入平臺跑通後的驗證報告和相關checklist，否則不予轉測試！然後大家開始討論，主要觀點大致如下：
1、測試的兄弟認爲從提升質量出發，開發應該充分驗證，對每個子程序，都應該跟平臺充分調試，並輸出調試報告作爲轉測試入口條件。降低轉測後發現低級問題，導致重新測試，浪費測試人力。
2、開發的兄弟認爲，通常大部分需求實現都是對已有子程序的功能做優化升級，子程序跟平臺之間的接口一般不會修改，而子程序的功能是可以脫離平臺進行驗證和測試的，如果要求每次子程序優化後轉測試都輸出跟平臺調試的報告，必然增加開發人力投入，這也是一種資源浪費。
從開發和測試兩個角色來說，矛盾點主要在於：質量和資源(人力)投入，大家都希望少投入，但把事情做好（質量高）。團隊一直強調基於角色和流程開展工作，開發和測試之間定義了標準交付件（如自驗證報告，代碼檢視報告等），因此測試很自然地想到在角色之間的交付件中增加一個跟平臺的調試報告來攔截開發問題流入測試。基於流程規範來解決問題的思路應該來說沒有問題，但這也僅僅是頭痛醫頭腳痛醫腳的辦法，如果問題都這麼解決，那麼下一次出現另外一個問題，再增加一個轉測試交付件（並且這個交付件真正能起到攔截問題的作用還很小），這樣機械式執行，開發人力浪費無疑非常大，作爲項目經理，希望用最少的開發和測試人力，交付高質量的產品，這當然不是上上策。那麼如何避免開發的低級錯誤流入測試從而導致測試人力的浪費呢？從本文前面描述的問題可以抽象出問題的特性：
1、子程序包含功能和接口，而開發通常關注於功能驗證，接口因爲涉及到其他平臺或者子程序，被忽略了。
2、開發粗心，或者意識不到位，導致沒有驗證到接口
那麼這類問題如何避免呢?開發在轉測試前必須保障交付的子程序的功能和接口的正確性是不可更改的，那麼是否一定要輸出調試報告等交付件呢，個人覺得只需要一個checklist即可（即：開發在轉測試前，只需要在checklist上簽字畫押，表示該子程序基於xxx平臺調試通過，如果不涉及，即寫明無需跟任何平臺調試並說明原因）即可轉測試，即如果子程序涉及跟平臺聯調，那麼聯調必須執行，但無需輸出報告。有人會擔心了，萬一需要聯調的子程序，開發人員明明沒有聯調卻在checklist上註明調試通過怎麼辦，問題還是要流入測試，其實這個問題可用考覈來解決，將質量和個人績效掛鉤，轉測試不通過計入開發質量關鍵事件，作爲績效考覈輸入，很多時候，只要有這一條，無需在流程中增加很多交付件，各個角色會自己想辦法提升交付件的質量的，項目管理，甚至團隊管理不應該將每個人都塑造成一個模式的，大家基於一個大的流程和規範，在流程規範內保持適當的靈活性（個性），所謂八仙過海各顯神通，我們不必要求所有人都像何仙姑那樣使用蓮花過海。
以上記錄比較倉促，觀點不一定正確，如有不同看法，歡迎留言。