項目背景簡介
| 項目代稱 | K項目 |
|---|---|
| 項目成員 | 6人（1個測試猿+5個程序猿） |
| 項目週期 | 兩個月（截止日期，國慶節前） |
| 工時評估 | 以天爲單位（模糊評估） |
測試猿的窘境：
1、需求文檔不明確？
2、提測時間不明確？
3、項目進度不明確？
4、我是誰？我該幹嘛？
想必每個測試猿都會遇到以上的窘境，版本到項目快截止時才提測，最後項目延誤了，又要默默的背鍋？
項目進行了半個月，依然沒有我什麼事兒，我真的不想國慶加班啊，去年就已經安排了今年的國慶節行程，怎麼可能延誤，必須要改變現狀了···
第一步：主動溝通，拋出問題
主動找研發經理溝通，拋出問題，提出解決方案；邁出這一步我也是三思而後行。
1、找到溝通有效的人
- 找項目負責人？項目負責人只是其中一個研發，解決不了根本的問題。
- 找項目經理？項目經理嘴上天天掛着忙，諮詢問題不問三遍絕對得不到答案，內心拒絕與TA溝通。
- 最後，只能冒昧約研發經理談話了，程序猿的直屬領導，應該是最有話語權了。
2、拋出問題，提出解決方案
存在問題：
- 需求不明確，沒有相關文檔輸出
- 任務沒有劃分優先級
- 任務工期評估模糊
- 按目前的進度，國慶前不可能完成該項目
解決方案：
- 工時精準評估，以小時爲單位
- 提供產品待辦列表，輸出任務優先級、研發進度、提測日期等信息
- 進行迭代開發，三期迭代，每個迭代爲期兩週(離項目截止日期正好6周)
備註：該圖片爲引用圖片
溝通結果：
- 第一點被否定，可以嘗試進行迭代開發
- 測試（me）主動提供迭代需求清單模板
- 測試提前介入，先行接口測試，後續功能測試
第二步：迭代開發，積極推進
1、我主動提供迭代開發需求管理模板 （見如下截圖）；
2、總共三期迭代，每期迭代歷時兩週；
3、週一：項目負責人郵件發出一期迭代需求清單，抄送項目干係人；
4、週五：測試負責人（me），總結項目進度，郵件發送項目干係人；
5、每期迭代結束，總結本期迭代的完成率以及優缺點，要生成可交付的產品；
第三步：迭代結束，項目完結
經過爲期6周的迭代開發，團隊小夥伴的不懈努力、研發經理的不斷施壓；項目最終按時完結，迴歸測試也提前完成，終於可以安心慶國慶、過中秋嘍···
最 後：測試經驗總結
1、如何實現測試左移
- 需求階段介入，明確需求甚至可以給出自己的對產品的設計意見
- 先行接口測試（或是單元測試），儘早發現接口層面的問題，可避免後期測試浪費時間
- 重視數據庫測試，新的項目所有的表都是新建的，可以從表結構、字段、索引等各個方面把關，遇到問題前期修改成本較低
2、多版本並行，如何高效執行測試任務
由於我一個測試猿要對接五個程序猿，某天出現了同時提測四個版本的情況，在片刻的慌亂後我採取了以下方式：
- 提測任務按優先級排序，進行一輪主功能測試，確保每個程序猿手頭都有bug要處理；
- 對優先級較高的任務進行第二輪全功能覆蓋測試
- 迴歸缺陷，缺陷關閉後，再進行三輪冒煙測試，發現新的bug，絕對不能讓研發空閒
- 就像玩遊戲一樣，輪番先各個研發扔bug，直到所有bug關閉才game over
3、迭代開發、敏捷測試
由於我大學畢業後就加入了敏捷開發團隊，敏捷（scrum模式）對我的影響很深，一直想在現在項目中推行敏捷，但是大家都不願意擁抱變化，敏捷最大的一個特點就是“擁抱變化”。因此本次項目就採取了迭代開發的模式，用敏捷的思維進行測試
- 當面溝通，減少信息誤差
- 持續改進，及時反饋問題
- 響應變化，停止推脫抱怨
4、有效管理缺陷，縮短項目進度
敏捷中注重處理bug 的效率，發現問題快，修復起來也較快；我在實際的測試中採用了傳統與敏捷結合的方式處理缺陷，減低了bug修復的成本，有效縮短了項目週期；具體總結如下：
- 頁面缺陷，集中反饋，提供截圖說明 ；
- 需求缺陷，雙方溝通，達成共識後記錄缺陷，可降低時間成本；
- 面對面溝通，主動重現解釋bug；
- 重視缺陷的成本，高時間成本，低價值的缺陷建議口頭通知解決，低時間成本，高價值的缺陷需要記錄追蹤；
- bug及時跟進：及時驗證、及時反饋、及時關閉；
總而言之：主動溝通、當面溝通、耐心溝通、持續溝通·····
測試猿: 嘿，下午茶來了，吃個香蕉休息一下吧
程序猿: 謝謝啊
測試猿:有幾個bug，現在給你重現一下吧
程序猿：好啊
測試猿：今天必須解決這幾個問題哈
程序猿：我很忙啊，沒空處理啊
測試猿：別吃香蕉了，立刻、馬上處理······
程序猿：@#￥%&*^~#