上午——QA技能小組需求收集大會
會上暴露出的主要問題：
- 大家對QA的定位、認識和獨特價值有很大的疑惑，大多數問題都和此有關。在意識上首先退守到檢查流程執行沒有的警察角色上，這樣的工作似乎沒什麼價值，充滿了疑惑。這個問題，後續不能以研討的方式進行，而是拍板訂釘，直接宣講，否則被引導到錯誤的方向。
- 原有的收集需求的目的並沒有完全達到，不過了解了整體水平，但爲後續工作思路很有幫助。不少人還停留在no know no know（不知道自己不知道）的地方，所以提不出一些具體的需求，都是非常大，如系統瞭解流程、瞭解質量工具和方法。
下午前半截——某產品測試代表介紹測試工作思路
通過前期的接觸，感覺到該測試代表一直強調測試的獨立工作，不想參與到系統設計的工作中去，認識上有明顯的偏差。所以會議上提了幾點建議：
- 當前公司的測試流程是自底向上發展整理的，並沒有和系統設計流程進行有效的結合，雖然解決了部分問題，但是重複勞動、產品整體開發效率低的問題並不能得到有效的解決。公司已經意識到這個問題，已經有人在進行改進的融合。（題外話：有一種情況很不喜歡，就是測試討論參與開發的討論與檢視甚至設計的時候，總是得到這樣一個藉口“我們需要從客戶的角度出發進行測試設計”。關鍵的問題是，這根本不是不參加開發設計活動（討論／檢視／場景分析等）的理由，這句話的潛臺詞就象是“開發從來不從客戶的角度考慮問題”，可是事實是這樣嗎？開發進行設計的時候，不從客戶的角度考慮問題，那設計的是什麼東西，很明顯，整個產品開發的過程中，所有的角色都是從客戶的角度考慮問題，不僅僅是測試，只是更細的考慮問題的維度和方法不一樣而已。所以，這句話根本就不可以作爲一個理由、藉口。而應該是，在設計討論、檢視的過程中，就及時的將自己的專業技能貢獻出來，在問題還沒發生之前就讓開發人員改正。況且，完全不理開發，只管自己做，那是一種什麼情況：開發、測試都是從客戶的角度出發，可是得到的對系統的理解卻完全是兩回事，對系統的設計和測試居然會是兩套標準，那測試發現N多的BUG、開發和測試之間永無止境的吵架也就不足爲奇了。關鍵是，這樣的後果很嚴重，開發不停的改BUG，測試活動永遠不能結束…… 只有一個角色對系統應該是怎樣的有決定權，那就是SE（當然可能不是一個人也可能是一個組織），測試代表應該積極的參與到系統設計組中對產品應該是什麼發揮力量，而不是在旁邊等着，然後說產品不應該是這樣）
- 測 試僅等系統工程師輸出設計需求後，才進行測試需求的分析，在對產品系統的瞭解上已經落後於系統設計人員，系統設計活動最重要的一點並非僅是其輸出的需求和 文檔，而是在設計的過程中大家的討論、交流，這中間傳遞了大量的知識，不是緊靠文檔輸出能夠學習和體會得到了。測試團隊一定要參加到系統設計的討論中去， 而不是在一邊埋頭學習協議、標準，何況當前有大量的新員工，參加討論無疑會極大的提高學習的速度和質量，並且有利於激發大家的積極性。（此 處非會議所提，而是自身感想：另外，無論是開發人員還是測試人員，在產品的開發中都要面對大量的糾纏在一起的問題，只有讓大家學習到有效解決這些問題的方 法，才能提高大家的積極性，也能讓大家感到學有所成，富有成就感。在這方面，我有強烈的感覺，因爲近期聽到的離職員工反饋的是“工作了兩年，啥也沒學 到！”，這種感覺在我工作的前兩年也有深刻的體會，所以感觸很深，所以轉而探尋Why走上了軟工的道路。幸運的，去年末一位資源部門的老大和我說，一位員工離職時還記得的我，當然說的是好話， 讓我很高興。更是加深了這方面的體會。這些日子，SE一直和我說，現在大家熱情特別高，而且已經可以放心交給下面的員工獨立進行工作，一旦大家學會了可以怎麼做，不再象開始那麼亂了，最近輕鬆多了，可以寫寫總結了：-））
- 澄清大家對流程活動的一些誤解，統一術語
下午後半截——另一產品研發會議
得到兩個可以作爲案例的題材，後續可以再調查整理
有人提到目前提交系統組裁決的問題單分析描述不足，我的第一反映就是把問題單打回，不過開發代表說了一句後續開會的時候一起看一下，說幾次以後，大家就知道該怎麼寫了。這點做得確實精彩，值得學習：）
晚上——某產品系統設計階段活動清理
討論明確包需求、設計需求、設計規格以及需求跟蹤之間的區別
fasiondog
2007年8月16日