dc 18:38:14
呵呵，在**上碰到你。
青潤 18:37:55
呵呵。
dc 18:39:05
我是剛才搜了itsp群看到你的**號的。
青潤 18:38:59
呵呵。
青潤 18:42:36
最近都在忙什麼？
dc 18:44:58
……青潤 18:44:50
……dc 18:48:57
被客戶追著一天乙個念頭的改code真是煩，我現在聽到**響就渾身發抖不敢接。
青潤 18:49:14
呵呵。這就是無備有患的結果。
dc 18:57:04
是啊，但市場決定了，否則就不要我們的方案。
青潤 18:57:28
呵呵。這也是市場不規範的結果。慢慢來，在熬上十年，會有變化的。那時候，我們就是見證歷史的人了。
dc 19:08:13
我們公司讓乙個對技術不是很了解的女孩寫機頂盒spec，她一不了解市場，二不了解技術，有很多跟我的想法不一樣的念頭，跟客戶的要求也有違。
青潤 19:08:10
呵呵。這不是胡鬧呢？
dc 19:14:11
三個qa，都是女的，沒乙個對軟體工程有概念的。
dc 19:14:36
7個qt，做測試的，基本都屬於發現問題就問，不動腦子想想和總結的。
dc 19:14:47
7個也都是 女的
青潤 19:14:27
呵呵。南京聯創業在招聘qa，不過，他們是希望能夠從公司內部經驗豐富的高階技術人員和管理人員中轉換過來。也處於尷尬中。
dc 19:15:45
所以前兩天看到你乙個帖子裡說國內沒有象樣的qa，是很有感觸的。
青潤 19:15:48
呵呵。是呀，有人還在反駁我。呵呵，不知道那個人是做什麼的，到底懂不懂qa的實質。
dc 19:17:33
我有個疑問，研發人員的工作質量可以從qt的測試結果，bug list中反映出一些來，但測試人員的工作質量，誰去檢查呢？
青潤 19:17:31
呵呵，是的，這個問題，問的非常好。
青潤 19:17:57
不過，有個詞你用錯了，標準的說法應該是qc——而不是qt。
dc 19:18:37
我前兩天問qa/qt部門的人，他們說正準備由qa去檢查，可我覺得挺有難度的。
dc 19:18:59
哦？我是指測試員
青潤 19:18:42
因此有些公司採用了錯誤發現率的方式來衡量qc人員的工作質量，也就是說，你必須在每乙個模組中發現至少多少錯誤才算是合格。
對，測試人員就是qc。呵呵
青潤 19:18:50
屬於質量控制範疇。
青潤 19:19:13
不過，這種方式也有不合理的地方。所以，國內很多企業也就不再多要求測試人員的情況了。
青潤 19:19:39
實際上，qc的工作情況是通過使用者反饋獲得的。或者說，軟體的試用期來體現的。
dc 19:20:46
我是碰到，送測乙個版本，寫清楚了需要重點檢查什麼，但回報的結果我能看出來測試的很不認真，沒有去尋找問題出現的規律，對解bug沒幫助。但我又不能去跟誰說這個情況，只能任其繼續下去。
青潤 19:20:20
這個期限內如果使用者發現的問題，屬於qc人員應該發現的問題，則對qc人員的工作質量進行了一次反饋性審核，這時候，就應該考慮qc人員的問題了。
青潤 19:21:12
當然，即使這個問題不是終端使用者人員發現的，而是開發人員在使用者使用期間測試後發現的，也同樣屬於qc人員的問題。
dc 19:22:22
我可能是希望他們在發現問題的時候能進一步尋到其中的規律，對解bug提供更多的幫助，我不是一發現不對勁就興沖沖過來說，宕機了宕機了。
青潤 19:22:17
呵呵，這就是測試人員的水平和素質問題了。
青潤 19:22:59
測試人員的職責應該是發現問題，找到問題的根源，但不是解決問題。
至少發現了問題，應該說明問題是為什麼發生的，根源在**，是不是開發人員的錯誤，還是其他問題引起的。
青潤 19:23:09
如果測試人員做不到這一點，那，他就根本不合格。
dc 19:25:09
我們這的是差了一點，發現問題不知道通過對比等方法去進一步了解，
青潤 19:25:37
你們公司應該考慮對測試人員做一下真正的系統性培訓。讓它們知道什麼是測試。而不是看到問題，就屬於測試。
dc 19:26:54
我以前被派過培訓，回來也做了presentation，可帶不起來。
青潤 19:26:59
有沒有了解過是**出現的問題？
管理、人員素質、獎懲機制、領導重視程度……
dc 19:28:24
我跟那個部門的主管說過兩次，乙個測試部門全是女的，我就覺得氛圍不對，缺少對技術的鑽研和學習的精神。
青潤 19:28:27
嗯。這不是最關鍵的，如果所有的測試人員都是這樣的話，一句話：還是管理問題。領導的重視程度問題。
dc 19:30:27
哈哈，我是跟他開玩笑的。
是制度的問題，對他們沒有監督，一直把他們看做對程式設計師的監督。
青潤 19:30:38
呵呵。其實，男性女性不是關鍵，關鍵在於領導。
dc 19:31:32
我想在公司裡提出這個問題，希望對他們的工作情況也有個考察
青潤 19:31:35
是的。
dc 19:35:50
我們也試過用你前面說的錯誤發現率來評價，但實行不下去，量化似乎很困難。
青潤 19:35:59
是的。的確很困難。所以，我建議的方式是後者。
dc 19:38:27
我們還有乙個問題是測試人員在測試的過程中關注的問題和客戶關注的不一樣，就會產生這樣的情況：測試人員報bug，客戶也反饋bug，時間緊的時候我們只關注客戶報的，然後，測試人員就覺得勞動沒被承認。
青潤 19:38:36
呵呵。這就是管理問題了。
dc 19:40:17
我們是與客戶聯絡的視窗，往往我們知道客戶想要的是什麼，而qc/qa不了解這些。
我一直不明白為什麼不能把這個視窗轉到他們部門去。
青潤 19:40:32
你們公司的管理問題比較大呀。
dc 19:41:21
是啊，
dc 19:41:38
可能與不是純軟體公司有關，我們是做ic設計的。
青潤 19:41:21
呵呵。軟體公司也同樣存在類似的問題。
dc 19:42:56
有一年的時間我想在公司做流程改進的事，可最終公司沒有投入人力去做。
青潤 19:42:52
呵呵，是不是因為費用的問題？
dc 19:43:47
有這個原因，還有就是專案的壓力。
青潤 19:43:49
其實，又乙個很重要的原因，就是老闆看不到這種投資所能夠帶來的效益。
dc 19:44:29
……對，是的。
青潤 19:45:08
呵呵。南京聯創去年過了cmm3，今年準備設定二十多個專職qa，就打算從質量方面入手來做。這方面的問題，是小公司很難投入的。畢竟費用比較大，但是，如果長期來看，其實是有好處的。
dc 19:47:38
……謝！
測試人員如何管理專案與風險預警
在很多時候不少專案上線後出現的問題，或是專案沒有按時完成時，測試人員是很容易背鍋的。通常專案在實施過程中，如果需求變動了，開發技術變更等影響專案進度的時候，也往往會壓縮測試時間的。這樣的事情造成測試工作壓力非常大的，產生這種情況的原因有公司制度的原因，當然也有我們測試自己的原因。為了更好的完成測試的...
如何評價測試人員的工作績效
隨著國內 軟體測試 行業的不斷發展，軟體測試工作更加深入 規範。其中對測試人員的績效考核也越來越重要。目前，很多公司對測試人員的考核方面都不相同，有些公司仍然是以單純的問題單數量來對測試人員進行評價，這樣直接對測試人員工作方向產生誤導，影響到測試人員工作的積極性和穩定性。因此，為了能夠更好對測試過程...
scrum開發中測試人員如何工作？
scrum工具 leangoo擁有看板式的協作方式，簡潔直觀，能夠輕鬆拖拽任務卡和任務列表，並在團隊成員間實時同步看板變化。同時它簡潔實用的功能使它比其他軟體更輕量，能讓團隊在5分鐘內協作起來，無需耗費大量的學習和使用成本。它的免費 無成員和專案數量的限制更讓廣大團隊協作沒有了後顧之憂。所以，作為一...