1. 程式人生 > >測試人員分配之我見

測試人員分配之我見

一個主管,多個小組模式

測試主管:
設立一個配置管理系統,根據提交的每日產品工作日誌,更新配置引數資料,根據
實際情況變更調整人力或資源配置,參與產品的驗收測試以及需求評審設計方案評審。接受非本部門的工作合作需求,更新計劃配置,轉化需求,分解任務。把關產品的釋出以及產品中缺陷的級別和性質審定,測試管理系統的系統管理員。
一個人作為中轉站:
負責管理產品的需求與產品設計方案,要求該人熟悉測試能設計到的所有產品的基本架構和業務邏輯,有可能的話,該人蔘與產品的使用者手冊
編寫。該人負責整理和分解客服反饋資訊,可參與部分技術支援。該人負責記錄與
統計各類產品的進度以及缺陷管理狀況,每日定時向主管提交報告日誌。另外可抽調該人做產品的驗收測試。

其他人根據實際情況劃分為:
一個公用組:
負責效能測試,該組的工作計劃個進度表應有改組的負責人和主管協商確定。
多個功能組:
每各組一個專職專案負責人,該負責人負責一個主要專案和幾個其他
多個專案,需要注意一點,該人負責的所有專案都不應與其他組的專案有所交叉 ,
也就是說最起碼他除了本組專案外不允許參與其他組的任何專案的任何工作。
組員:多個組可以擁有相同組員,但測試初期為測試同一性質的產品的組成員互調使用。到驗收測試時,為不同產品性質的組成員互調使用。

相關推薦

測試人員分配我見

一個主管,多個小組模式測試主管:設立一個配置管理系統,根據提交的每日產品工作日誌,更新配置引數資料,根據實際情況變更調整人力或資源配置,參與產品的驗收測試以及需求評審設計方案評審。接受非本部門的工作合作需求,更新計劃配置,轉化需求,分解任務。把關產品的釋出以及產品中缺陷的級別

軟體測試質量保證我見^-^

隨著網際網路進入開源的時代。市場上的各路產品就競爭進入了一個更加嚴峻的挑戰時代。各個產品各個理念像奇蹟一樣不斷的充斥著市場,分割著市場。人們的選擇性更多,要求越來越高。隨著資料不斷的增長,對於軟體處理這些龐大資料的整體性結構就給出了一定的挑戰。面對龐大的資料和複雜的結構,如

SAFe 從概念到實踐 開發人員的“敏捷”我見

  敏捷開發並不是一個新概念,在過去十多年裡,敏捷開發方法論已成為國外開發團隊的主流思想。敏捷開發真正走進中國,是從5年前開始。因為敏捷方法論中提到了一些在傳統軟體開發方法中沒有注意到的思想,這些思想是真的可以為軟體開發帶來顛覆性的力量,甚至可能會掀起開發領域的一場革命。

技術人員何去何從四:對測試人員的忠告

 隨著軟體規模化程度的不斷加深,軟體測試崗位的需求越來越多,甚至連續兩年被某機構評選為十大需求最大的職位之一,在我們的客戶中,相關職位也的確不少,但當我和很多測試人員交流的時候,我發現他們中的大多數對自己的職業發展都比較迷茫,充滿了無奈的情緒。對於這種情緒,我非常能夠理解。從

軟體測試我見

當前還存在著這樣一種問題,公司一般不會讓軟體測試人員在專案的初期就參與專案,一般要等到軟體的雛形出來後才會讓軟體測試人員著手進行測試。對這種情況,測試人員可以通過已經建立的軟體的雛形,揣摩產品說明書,然後也是同上段所說一樣,向相關人員請教,擬定一份書面的完整的、準確的、一致的、合理的產品說說明書。值得注意的是

移動端自動化測試我見

   從事網際網路行業已有5個年頭,其中也做過一段時間產品崗,對這個行業的總體感覺就是發展變化相當快。 就網際網路測試領域來說,怎樣有效地提高工作效率,提高產品的質量,是測試工程師都要思考的問題。初

測試工程師工作定位我見

        好久沒有寫blog了,主要兩個原因,一是因為新換了工作,事情比較多,抽不出時間來寫。二是對自己的工作定位有些迷茫,一時搞不清楚軟體測試工作的定位,所以不知該寫些什麼。不經意間我工作也快五年了,除了剛開始編寫了一年左右的程式碼外,其他時間一直在做軟體測試工作,而

【蟲師--系列03】效能測試知多少----效能測試分類我見

來自:http://www.cnblogs.com/fnng/archive/2012/06/09/2543274.html  作者:蟲師 從這一篇開始,蟲師向性能方面發力。翻看自己的部落格,最早的時候熱衷於jmeter,於是寫了幾篇圖文並茂的文章(其實,主要是操作截圖

FEC我見

ack 長時間 服務器 恢復 阻塞 設計理念 你是 連接 qos 顧名思義,FEC前向糾錯,根據收到的包進行計算獲取丟掉的包,而和大神溝通的結果就是 糾錯神髓:收到的媒體包+冗余包 >= 原始媒體包數據 直到滿足 收到的媒體包+ 冗余包 >= 原始

軟件測試人員有多細心?

學習 大堆 標準 顏色 意思 進化 總結 完全 如何   軟件測試人員有多細心?比如你有一個泡茶的過程:1、燒一壺開水。2、找一個杯子,放一些茶葉到杯子裏面。3、將開水倒入杯子中,稍等片刻便可。你覺得這個過程完全沒有問題?在測試人員那裏可能就是問題一大堆,比如說:1、燒一壺

測試人員溝通任務

進行 測試 一個bug 之前 例如 私有 文檔 場景 主動 與開發人員的溝通 測試與開發是天生的冤家,與開發者一起工作需要註意的3個方面。 1.定義自己的角色,首先應該在bug還沒出現之前就消除掉 私有階段:給開發人員的問題和改進的建議,bug會自己準備文檔詳細記錄下來,不

從功能測試到性能測試的轉型

小強軟件測試瘋狂講義 性能測試 小強測試品牌 接口測試 引子以下內容選自《小強軟件測試瘋狂講義》一書正文 在測試行業也有兩年了,兩年的時間對於一個人的職業生涯來說不算長。但是從職業發展的角度來看,這兩年卻是非常重要的。有的人抓住這兩年的機會,會快速的從行業新手變成行業的高手,但是

作為一個測試人員的素質(如何做好測試

腳本 lsp 規劃 接口測試 自己的 做什麽 cells 工作任務 前端 1.產品評審:   ①發表自己的意見;②評審的時候不能只停留在ui,盡量讓產品說清楚(交互,排序方式,刷新規則,分頁處理) 2.測試計劃,測試方案:   測試計劃:描述了要進行的測試活動的範圍、方法、

測試人員代碼走查基礎要點

異常 業務邏輯 類型 找到 錯誤 都沒有 發生 數據庫連接 有效 測試人員代碼走查基礎要點  代碼走查,是測試人員了解代碼邏輯,進行測試設計的重要環節。並且有很多bug並非需要到運行程序進行測試才能發現。通過合理的代碼走查方法能提前發現相當多的BUG。除常見的業務邏輯與程序

讀書筆記 ~ Python黑帽子 黑客與滲透測試編程

alt nbsp too 管理 return cps 工具 transfer args Python黑帽子 黑客與滲透測試編程之道 <<< 持續更新中>>> 第一章: 設置python 環境 1、python軟件包管理工具安裝

測試人員如何避免背黑鍋

最大的 產品經理 混淆 較差 信息 這一 郵件 任務 效率 系統上線後發生故障在所難免,但本文不討論出了事故以後如何通過“詭辯論”讓自己脫身——職場混久了,大家都不傻。即使僥幸“脫身”一次,在同事心中難免留下不可信的印象——本人來談談個人關於“預防”背黑鍋的幾點看法

自動化測試測試人員的遮羞布?

要去 下載 可能 現在 key 通過 其他 space 說了 如果有一份自動化測試和一份功能測試,相信大多數測試人員想都不想的肯定選擇自動化... 自動化啊!高大上啊!接觸代碼!錢多啊!現在都要會啊!會代碼了感覺自己就很厲害了!等等心態。。。當然。。。我也是。我覺得這些心態

怎樣才幹成為一名優秀的軟件測試人員

popu 成功 優先 content 時間 下一步 溝通 變化 ont 近期在和一些公司的軟件project師和管理人員交流時,發現他們常常發出這種感慨:尋找一名優秀的測試人員這是太難了。那麽。具備哪些要素才成成就一名優秀的測試人員,以下是我覺得比較重

測試未來發展,測試人員的發展方向,測試趨勢

而且 腳本語言 脈脈 必須 如果能 國內 培訓機構 成本 消失 最近在脈脈上看到某某公司斬掉測試團隊啊,某某開發嘲諷測試人員啊╮(╯▽╰)╭,轉個測試行業看法聊以自慰,至少現在還有碗飯吃。 測試行業的趨勢有這麽些: 功能測試依然存在,但是會變得越來越難找工作 功

對於軟件開發中開發人員測試人員關系的理解

我不知道 統一 選擇 好聽 dash 過去 思路 排查 定位   在軟件開發中都會有開發人員(以下簡稱開發)和測試人員(以下簡稱測試),在一些小型公司可能並沒有測試,僅僅是開發兼任測試。在這裏我僅針對於有專業的測試和專業的開發的項目。   每個公司應該都有考核機制,對於開