做得好的事項

1. 負責人對於分配的任務，總是耐心的講解，特別是每天很多人找的狀態下。
2. 很多同事在高壓下加班，連續加班，都能堅持下來

待提升的事項

1.項目4個月下來，每次交付的時候總是很被動；

現象1：第一次演示PC，演示的前一天流程都不通，周六再不通，計劃把數據寫死再去演示；但我們交付時間是提前已經訂好了的；

現象2：第一次演示ios/安卓（10月份），數據都是寫死的；我們的關注點都只在ios/安卓上面；以至於忽略了pc端已經跑通，可以真正的測試了；11月1日我們本可以按時交付PC端的，但是由於沒有完整的測試過；不敢交付；

現象3：項目開發的時間段，測試屬於空窗期，沒有及時安排相應的文檔任務；以至於後期需要一周，甚至周末加班來完成測試用例；

2.對於人員問題安排，出現問題時很被動，沒有可行的方案可選擇；

現象1：對於項目成員的懷孕（離職），剛好這個崗位人數比較少，出現問題時很難有可行的方案來解決；

現象2：對於項目成員的連續加班，特別是疲憊期，大多是依賴著人情關係協調加班，並不是大家有一個共同的目標；工作上的效率也將是一個問題；

3.不管流程有沒有通；都安排測試人員去測試；

現象1：第一遍要測試的內容，不管流程有沒有通（至少我們項目給過來，流程都是不通的），只安排測試人員去測試該內容；測試人員測試的煩躁，因為還需等著該內容修改好再來過流程；關注點都在一個上面，沒有安排其他的測試；

4.問題出現了，習慣性不從自己負責的部分開始找原因；特別是再交付的時候去等別人來排查問題；（少部分人）

現象1：同一套介面，發現問題說是介面的問題；提醒其他使用該介面沒有問題，依舊是等後台開發人員排查問題，排查到是參數錯了；

現象2：測試出bug了，總說自己測試時候是好的（或者其他理由），對於修改較為拖拉；

5.對於項目的完成度，大多開發人員這個靈敏度不高，部分偏低；

現象1：參與開發的關注的重點在於有沒有完成，對於完成的「質」並不感冒，以至於pms有很多的bug，特別是低級的錯誤；

現象2：換生產環境：新環境出現了多處404，500的問題；要交付的當天應用還掛了一次；

6.不一定是測試人員沒有審美；

現象1：交付給客戶之前，流程沒有跑通、功能缺少；測試提了頁面美化問題，關鍵是開發人員有時間修改么？

7.項目經理催著測試要可交付的版本，總是壓縮測試時間（數、開）

現象1：即將要交付給客戶准生產環境包，後台pms的1級問題還沒修改完成，有些功能流程還沒有走通，還有404、500的問題，就催著測試要可交付的版本；給開發人員說的是周二下班之前就改完，周三中午就需要交付；

項目經理著急的應該是開發人員什麼時候能修改完bug，著急測試並沒有用，測試又不會修復bug；這個壓力應該是給開發人員；

8.測試提的問題，開發人員修改好，總是需要測試陪伴著驗證（數）

現象1：某個小功能出現一個bug，pc、app都有問題，已入pms；非得找測試去復現問題，修改好了然後還主動找測試去幫驗證，要是還有問題他再去修改；就不會選擇pms上直接點已完成；況且這個項目上多數開發人員都是這樣。

改進點及落地措施

1. 項目被動：我們欠缺從整體的角度來考慮項目的整體的進度，被動是因為客戶要什麼，我們去盡量完成這個小目標，總是追著客戶的腳步走，所以我們一直在被動中。客戶每一步採取的行為，我們不僅要完成這次的，還需要想清楚客戶接下來需要的。例如部署客戶的測試環境，那接下來肯定是需要操作手冊的，不應該等到客戶要的時候，我們才急忙地安排這個任務，專門抽一周的時間來寫操作手冊。
2. 對於團隊來說，制定同一個目標，大家都為一個目標而戰鬥，明顯效率、結果都會上一個層次。如何增強項目成員來承擔這個項目目標呢（目前還沒想好）；
3. 流程不通：應該安排流程跑通的測試；加強流程跑通是開發人員職責的意識；提高交付到測試人員手裡的質量；各崗位的職責需更清晰；
4. 交付總壓縮測試時間：部門經理應該介入，對於不能交付的版本，要明確指出不能交付；並溝通好需留給測試的時間；內定項目交付時間不應該只有開發的項目經理說了算，測試人員也應該有話語權；

推薦閱讀：

相关文章