1. 程式人生 > >測試工作效率低思考和改進

測試工作效率低思考和改進

引子

  彙總統計了一下專案組近期測試專案實際工作量與基線工作量的對比,發現一個嚴重問題。就是工作效率特別低下。下面簡單列舉一下幾個專案預期工作量和實際工作量以及時間耗費嚴重的地方、專案簡要背景。

  1、B版本測試。版本預期工作量15人天,實際耗費工作量在30人天。更為嚴重的是測試人員並沒有因為測試周期延長和工作量投入加大而測試的更輕鬆,反而是測試期間晚上加班嚴重,參與測試人員測得還極其難受。有一個背景提前說明,該版本是從同測試部其他專案組第一次交接給我們專案組,另外參與B版本測試的測試人員對手上測試項內容不熟,第一次執行,此為前提。

  2、S專項測試。預期工作量3人天,實際耗費工作量6人天。中間也是各種加班。對測試人員來說,該項內容也是新東西,但是對專案組來說,該專案是相對成熟的驗證內容。

 3、已知問題的重複又重複的諮詢、確認、溝通。雖然單次耗時不多,但是架不住頻率太多。

  測試人員加班多,活幹的還不爽,工作量產出與工作時長嚴重不成正比,自己也在思考這些工作現象和如何改進,否則如果這樣狀態長期下去肯定會出現人心浮動,身心煩躁、離職、轉崗等等問題。。

效率低突出的幾個問題

  1、測試人員接手新專案,沒有好用(容易理解、無歧義、有圖文指引、詳細FAQ)的文件。拿到一個文件不好用,理解費盡也無法Step by Step執行。可能也不知道誰熟悉這一塊,知道誰熟悉這一塊的人正好又忙的不可開交,三言兩語跟你說完了你還是雲裡霧裡,又只能回去繼續埋頭看,時間就悄悄過去了。過兩天測試內容要交付了,活沒幹完,靠,加班。。煩躁

  2、已知問題反覆溝通、確認。A問B解決,C不知道該問題,又問D,D不知道又問A,A可能沒記錄時間長了忘記了又問B。來回迴圈特別耗時,看著好像挺不可能的,實際在專案組工作中很常見。有時候就是這種小的不能再小的問題阻塞你工作大半天。過程中問問題的人很鬱悶(就這P大點問題搞半天),被問的也很鬱悶(咋天天問,我活也幹不完啊)。大家都鬱悶

 3、返工。舉幾個例子,環境切換後發現少了一個指令資料沒有收集,切換回來。半天過去了。切換前發現某個測試項沒有驗證切換回來。測試報告寫作時發現過程需要截圖發現忘記保留,加班從新測試一遍收集一下。累不。煩不。站著旁邊看我都覺著累、煩。

 4、習慣於手工操作。比如上百條的命令他可以一個個寫,幾十個指令的修改他可以一個個改。太可怕了。。明明可以寫個指令碼一會會可以搞定的,就算不會寫,隨便組內找個小夥伴幫忙搞兩下也就解決了。但是好像習慣了,還覺著很努力。。可能不是常態,但是見過不少了

 5、還有其他的,工具不好用、文件找不著、文件不成體系,遇到問題找不到FAQ等等。。

 6、策略問題。這個可能得專門說了。。不再這展開。

  這些問題不知道在大家專案組是否存在或者是否是突出問題,這裡應該還與專案區人員業務、技術成熟度有關,恰巧的是我們當前部門、專案組新人太多了。。可能不是問題的問題都成了大問題。。

效率低問題改進

  影響測試效率低的問題上面也簡單羅列了。不能光吐槽,總得想辦法解決啊,起碼讓自己或者和自己一塊幹活的少加點班啊。

 1、梳理收集組內現有經驗文件,形成知識體系。特別是經常搞的工具使用、專項驗證常規特性驗證、複雜特性驗證等。文件一定要清晰、易懂、規範、能多截圖就一張別少。能把點選選單按鈕路徑寫清楚就寫完整。為什麼是經常搞的,第一優先順序高,常用。另外,統計觀察過程發現,影響測試效率低最明顯的就是這些常搞的內容。另外,整理完後釋出在論壇上,隨版本測試實時重新整理。知會組內同事。如果組內同事都勤於重新整理這些內容,文件和FAQ就會非常詳細。另外,還有一個好處,就是可以知道誰搞過相關的事情,諮詢問題時就不用來回繞了。。直接找到相關人員解決問題。

 2、多總結,隨手記,多分享。上面說的是成體系的,這裡主要是隨手記一些文件,FAQ。寫完可以分享在自己部落格、論壇甚至發到工作群裡都可以。儘量不要都記在自己電腦上,一個自己可能不好找,後面就忘記了。。另外一個,別人就沒法共享你的勞動成功,資源浪費了。。好記性不如爛筆頭,多總結,隨手記,多分享。與己方便,與人方便。

 3、工具開發與維護。定期維護常用測試工具,讓它更好用,不影響測試。定期收集工具需求,開發。。用工具提升測試效率,讓工具替人幹活,這就是自動化最大的價值。所以,要儘量多思考,多想想自己手上哪些工作可以通過工具替代的。。不要埋頭手工搞,不是手工作業的時代了。。

 4、個人技能。這個重點就是要看個人了。。針對自己的手上工作有意識的去總結、拓展、去思考、去分享知識。業務和技能越強,依賴外部的機會就會少些,幹活自然效率就會高很多。。

 5、培訓。這個實際上是好辦法辦法,但是去年上半年做了半年培訓 實際效果並不好。大家都只是掛著聽聽。互動也不好,下來就忘記了。。可能是專案太忙,可能是大家沒有真實經歷某些測試項時並不願意主動花這個時間去學習,我有時候不願意參加原因是因為一個是我沒有太多時間提前瞭解,培訓時聽不懂。。可能是培訓形式和方法不太對,這個需要再思考一下

最後...

  上述的問題其實在很多專案組都經歷過,都很普遍,改進方法也都很簡單、很老套。只不過在新人多的部門和專案組暴露的更為明顯。目前改進的事情如知識體系建立、FAQ整理,常用工作開發和維護都已經在進行中了。。希望工作效率可以上一個層次,大家少加班,身心