只是隨便的聊天中的一部分：
飛雪連天 21:08:49
你還真有時間搞這些，我現在看專案管理的資料，把專案管理的很多東西運用到外包測試的專案管理中
zee 13:08:59
職位不一樣，想法不一樣。這些是現在我要關注的。不過專案管理的東西，我也應該看看了。未雨綢繆。
飛雪連天 21:10:56
呵呵，很多東西，在測試專案中使用，要具體化，根據測試專案不同於研發專案
zee 13:11:17
說實話，測試專案，我一直對這個專案管理搞不太清楚。可能對所有的專案管理都搞不清楚。
zee 13:11:28
這個不做還真不容易感覺到。只是知道個大概。
飛雪連天 21:12:34
很麻煩
飛雪連天 21:12:40
沒有成型的東西參考
zee 13:12:35
只能按公司的情況慢慢的裁剪了？
zee 13:12:47
就像rup流程的裁剪一樣。
飛雪連天 21:14:54
不光是裁剪，針對外包測試要做出很多東西來
zee 13:14:45
外包測試和公司內部的產品測試最大的差距在哪兒呢？
飛雪連天 21:16:00
差別還是很大的，專案管理、進度控制，風險控制等都不一樣
zee 13:15:50
是執行過程，還是內容都不一樣了？
飛雪連天 21:18:59
執行過程也要嚴格的多，測試是一種服務性質的工作，如何把工作成果展示出來，並控制進度和風險，這些都是很麻煩的事情
飛雪連天 21:19:23
需要工具，也需要模型，方**的支援
zee 13:19:24
其實說到控制進度，我還有點概念，但是風險這個我就搞不大清楚。怎麼去判斷風險？
飛雪連天 21:21:01
這個太多了，不斷的要識別風險的存在，規避風險，減少由於外部，內部，專案，技術，組織上帶來對專案的風險
zee 13:21:35
打個比方說，如果有一模組，本來認為一周可以完成，然後中間因為技術或者人員流動帶來了時間的滯後，這怎麼判斷？
飛雪連天 21:22:33
做好服務不容易，測試是一種看不到，摸不到的工作，測試能給客戶帶來多大的信心，需要下功夫
飛雪連天 21:23:26
意識到技術或組織上的風險，要預先判斷
zee 13:23:41
但是技術上的，怎麼判斷呢？只能看經驗了。
zee 13:23:43
？ 飛雪連天 21:24:47
對自己的人員要了解，通過溝通等可以獲得
飛雪連天 21:24:59
經驗，技能等
zee 13:25:01
我覺得這一塊很難搞，肯定得是很有經驗的人。去判斷這些東西。
zee 13:25:27
就像測試度量一樣。現在很多度量標準都感覺不大對。
飛雪連天 21:26:18
我們要做外包專案的測試管理規範，要考慮很多的東西的
zee 13:26:19
你們現在已經形成一套體系了嗎？
zee 13:26:26
大體的框架。
飛雪連天 21:27:41
大概的 是有了。
下面大概的內容就是，吃飯，有時間再聊的話了。
通過聊天，讓我對外包專案有了些許的了解。
關於兩個外包專案的經驗
自自己的舊space。今年 2007年 因為導師的原因從同一家小外包公司那裡接手了兩份外包的工作。結果乙個成功 至少在我這邊看來 乙個失敗。總結一下還是很有好處的。外包公司在美國，不過老闆是中國人，真的很小，常駐員工據說只有7個人。拿到的外包專案通常也都是轉了幾手的了。第乙個是在5月底接到的，歷時乙...
專案的使用者手冊和測試
1.每完成乙個整體的部分，例如乙個小功能，都要把測試寫好。2.或針對於測試來寫功能，先測試後功能。功能 的程式設計和手冊的書寫盡量由個人完成，好處自然是創作人對自己的作品更了解，書寫完成當然也可以找個不了解產品的使用者進行體驗，改善手冊。手冊的編寫和測試一樣，要及時，半年後可能創作人也對自己的作品不...
微服務專案的整合和測試
1 掌握微服務專案的整合使用 2 掌握swarrger ui的簡單使用 本專案模擬的是乙個簡單的 管理系統，其專案整體結構如圖所示。由於microservice orderservice 訂單微服務 和microservice userservice 使用者微服務 都涉及了mysql資料庫的連線使用...