亂亂寫 Blog

上一篇寫了有關於 Test 團隊的重要性 和 基本新工具 介紹
和 GiPi 大大討論過後就覺得這個題目很不錯，所以有這一篇文章的！

很多開發團隊 對於 QC 這個部分

要如何和開發流程整合？收集什麼資訊？分析什麼？

可能都不太了解

 

最後就會變成 QC 只是一味地找軟體中的 Bug

只要認為 軟體不會被「按壞」就是代表我們做出來的是好品質

但…  事與願違

往往 公司所面臨到的是更嚴峻的考驗

 

導入前…

由於不了解需求、 也沒有參與開發過程討論，所以可能是等到開發完才看得到畫面。

要從那裡開始？欄位要輸入什麼？

都可能不太清楚，只知道客戶最後要看到 下訂單後庫存就要扣除其數量。

因為發現 Bug 都是馬上口頭跟 開發人員講發生了什麼問題

變成常常要到開發人員那裡 操作一次給他們看以便確認問題 ( PG 通常無法搞出問題來 XD  )

一來一往其實會浪費很多無謂的時間。

而且通常遇到「資料庫」「系統效能」等等的問題 這也是讓測試人員束手無策的。

 

大家都是做事的人，但老闆要看的是 KPI   一切的投入都是要有效果的。

 

若是沒有成效的話，大家的努力也是白費！

若是拿不出數據，空口說白話也沒用！

 

 

所以，我們要找出 QC  的核心價格！

不單單只是為了要測「功能」更是要測「商業邏輯」和「隱性品質」

接下來看看應該要導入流程 和 工具 後會得到什麼效益 
( 不能只靠 QC 也 需要 PM , PG 彼此之間的協助才行 )

 

	工作 / 流程	主要對象	相依的相關工作	成效
1	建立 Bug 單	PG , QC	版本管控 Task 管理	可以知道每一個版本的品質情況 分析數千個 Bug 中要先改那些重要的 Bug 單 和 程式碼 建立關聯 ( 經驗承傳 ) 產生各種報表 ( 處理 Bug 的速度 ，請試著分析看看 ) 可 和 工作單建立關聯 工作有記錄，避免影響開發團隊的工作流程
2	效能分析 (VS 2010)	QC , PG	壓力測試   知道那一個的測試最慢時	QC 可以先產生「效能分析的報表」以大幅減少開發人員的時間 ，顛覆都一定要開發人員找效能因素 非常詳細的分析資料和數據   包含 多執行緒 / CPU / Memory / IO  連 開發人員自行寫 log 都難以分析的報表都有 提升 QC 可以產生資料的範圍 可完全不需要會寫程式
3	Test Plan Test Case ( VS Test Professional )	PM , QC , PG	需求管理 版本管控 工作單管理	可隨人手增加時 經驗移植  ( 人員異動時亦同 ) 單一 Dashboard 整合  開發進度、測試結果 自動錄製 手動測試過程，提升測試記錄品質 整合 Hyper V 可隔離測試環境 手動測試過程可以「自動重複操作」 模擬各種環境 …
4	Web Test Code UI Test	QC	Bug 單	依實際操作案例進行錄製 可節省「回歸測試」時間 可以知道網頁所有執行時間 支援 「介面驗證 」 「Monkey Test」可以完全自動化
5	壓力測試	QC , PG	一定要搭配 Web Test 單元測試	驗證系統實際人數上線使用情況 分析最慢的操作情節 分析最慢的SQL 語法分析 分析各種系統指標 驗證系統、硬體架構 …

 

 

測試只是開發流程中一個的環節，多看看有什麼解決方案可以符合測試團隊的需求。

節省測試時間才能有更多的精力確保新的功能 和 客戶需求、操作經驗 都能被驗證到

並且測試經驗都可以一直延續下去，都是導入的目標。 ( 遠目 )