寫下這行標題，其實我的內心是崩潰的，因爲還在等待bug修復
開個玩笑，其實還好啦，作爲一個快5年的測試中鳥，這點自我調節能力還是有的。
新工作入職小半年，最近其實才陸續鋪開工作。那這頭一個開乾的項目其實就是一個很簡單的營銷內容小程序，大概樣子就是一個極簡版大衆點評or馬蜂窩babala...
核心無非就是前端頁面展示後端接口吐出來的各種數據，但是即便如此，居然還是跟小夥伴提了100多個bug。
那麼這種簡單項目卻問題很多，都是因爲啥呢？姑且來分析分析，當做一個簡單的覆盤好了。
項目小盤
一、項目流程
流程上問題不大，雖說這裏是個創業型公司，但是規模不算小。
另外這個項目雖然一期內容簡單，但是後續要迭代的內容不少，也承擔着未來營銷內容的重任，所以項目流程基本上都是按規矩來的。
1. 立項 - 確定好項目核心成員
2. 排期 - 各團隊負責人計劃自己的工作週期
3. 測試設計 - 測試大綱設計、測試用例評審
4. 提測
5. 冒煙、正式測試、bug修改
6. 開發、UI、驗收走查
7. 測試報告
雖然流程大面上沒啥問題，但是細節上還是存在的，這個放到後面問題裏一起說。
二、團隊結構
由於公司控制正崗的HC，於是招聘了大量的外包的同事過來參與進各種項目的工作，所以這個小程序項目也不例外。
測試是1正+1外，小程序前端是2正+2外，後端系統（接口服務+後臺系統）算是3正+3外，項目週期從立項到預計上線是1個月多點。所以，結合人力和週期來看，應該還是比較寬裕的。
那麼都存在哪些其他問題呢？
三、問題梳理
1. 需求層面
唯一一點我要吐槽的就是PM希望提前2天上線的事情了。理由在我這是站不住腳的，但是呢由於這初版不會正式投入使用，而且當時看這個測試情況應該問題不大，所以故沒做過多計較。
其他因爲需求經常變化導致後面開發返工這事情倒是基本沒有，所以並不是需求層面的問題導致了開發工期不夠，而問題劇增。更何況壓縮的也測試的時間。
2. 開發層面
這裏可就是我要重點吐槽的部分了。
問題這麼多，歸根結底還是因爲開發的代碼質量太爛。
從提的bug問題來分析，這些爛代碼的開發人員畫像是這樣的：
1. 需求理不清，就寫功能
2. PRD、UE、UI相關文檔不管畫的如何（雖然有的錯誤一眼就看出來不通順），照着實現就行
3. 開發完成了，聯調僅發現可以展示數據了即可
4. 修改完bug，不自測
5. bug改一增二
6. 遇到不會的開發問題，不能及時拋出風險
...
所以就前 5 項來說，起碼可以說明這個小夥責任心不強，或者說職業素養不夠。
置於第六項嘛着實令人頭疼。你經驗欠缺個人能力不夠倒也情有可原，你倒是問啊，一個問題自己吭哧搞1天都等着呢，最後告訴大家搞不定需要支援。。。
個人能力差+態度不認真這兩個大頭都佔齊了，能寫出好代碼纔怪了，後續估計會考慮換掉這批外包開發人員。
另外就是部分開發的接口、後臺功能都有不同程度的延期，故導致原先計劃好的接口測試也不能充分的進行。
3. 測試層面
吐槽完開發，說說自己這塊吧。
我覺得首先要說的，可能是測試准入門檻放的低了，但是目前階段也是不得已而爲之。畢竟大家第一次合作，還不知道具體如何，項目還是要往下走，最重要的是這個項目1期不會正式使用，所以相對放寬了些。
接口測試部分測試的不充分，這主要原因還是因爲開發提測延期，所以大多隻測試了單接口的邏輯。考慮到最終還是會結合頁面功能全量測試，所以這裏問題也不大。
再有一點的話，可能還是我過於操心了一些事情，包括bug精準定位，溝通協調等。
四、問題解決方法
綜上來看，其實這種還算是比較典型的問題了：提測質量差 + 測試工期壓縮`，相信很多小夥伴之前多少也遇到過，下面來說說我的看法。
1. 對於提測質量差
- 適當提高測試准入門檻
當你知曉目前開發團隊的整體提測質量很差時，那後續就可以適當的提高准入門檻。
- 儘可能的提前測試
因地制宜，比如提前進行接口測試、或者代碼能力強的直接可以走查開發代碼。小程序這種項目也可以提前申請項目代碼權限，在本地運行起來，看看頁面數據，UI樣式等等。
- 問題及時通知到對應的人
本次由於使用在線Excel來記錄跟蹤處理問題，所以也一定程度的降低了效率。原因是jira要被替換，所以就準備後續直接在新系統裏進行項目跟蹤。那麼這時候，你提的bug要確保對應的開發已經關注到了，阻塞類問題一定要儘快修復。
2. 對於測試工期壓縮
- 重新評估工期
其實對於壓縮測試工期的情況，首先我們要進行合理的評估，到底能不能壓縮，風險如何。
我之所以同意壓縮，主要是考慮到一期項目簡單也不會立即投入使用，而且大多數問題也是頁面數據呈現，UI交互樣式等。
- 及時跟蹤進度、拋出風險
可以把目前的問題核心、風險點都整理出來，與項目負責人確定好必須修復的問題，然後貼在大羣裏@所有人共同關注。
剩下的就是跟蹤這些問題的修復進度，每天/幾個小時（視情況而定）同步風險情況。保留好郵件\飛書等重要問題的溝通內容，以防止以後遇到扯皮的事情。
另外就不要更多的參與的bug細節中去了，更好的投入到進度和風險把控上去。
- 明確剩餘問題的修復安排
其他非核心問題也不能忘記了，要明確修復優化的時間。
五、小結
上述也只是我的一家之言，僅供參考。這些問題的類型、處理方法我覺得倒也不是什麼難點。
我覺得最困難的是當我們處於項目質量這個角色上，如何能快速適應項目，把控風險點，並且運用各種方法解決或者降低風險對項目質量造成的影響，同時還要儘可能地最好對我們自身的保護。
對於此，你是怎麼看的呢？歡迎大家留言討論。
最後插播一條預告：接下來恢復pytest官方文檔解讀系列的更新。
這個系列有不少童鞋覺得不錯，希望有更多甚至全量的解讀。所以決定恢復這個系列的更新，是否會全量不一定，但是核心重要的知識點肯定不會少，有興趣的小夥伴敬請關注。