今天
工作中碰見一件事情，讓所有人都覺得有點郁悶。
我們產品是一個底層的安裝框架，對上層要支持平臺軟件，再上層還要支持產品軟件。每個都是獨立開發，每個產品都定時在貨架服務器上上傳新的相對穩定的版本，來支撐其他子域的測試和驗證，整大產品的主要客戶是電信運行商，規模比較的大。
我們的產品應為涉及到很多個平臺（linux，solaris，windows）且每種系統上還有多種不同特征的版本（單機雙機多機....），一個正常的轉測試流程下來，涉及到的測試場景有10多種，平均每個測試人員要分配2-3個場景，而且不包含各種專項測試，任務量比較繁重。
一般情況的轉測試，都只使用平臺軟件來配合，不會涉及到產品軟件，偶爾零星的也會使用產品包，如果涉及到產品包，我們就稱之為“聯調”。進這個項目三個月以來，只見過幾次聯調，每次都是那個幾個老員工來做。
每次轉測試的各種包，都是開發的CMO從貨架拿版本然后再轉到測試，經由測試經理和TSE制定好測試策略以后轉發給測試員測試，整個流程測試人員基本不會接觸到貨架，雖然一開始測試經理一直在強調每個測試員都需要熟悉怎么從貨架獲取最新的版本，但是一直都沒有特別的測試要求從貨架取版本，再加上測試任務繁重，新進的測試人員基本都不知道如何從貨架取其它域的軟件包。
這次的轉測試，是星期六早上，測試員需要花大約一天的時間來準備測試環境，迭代開發的原因，轉測試流程非常緊湊。周一晨會，測試經理宣布本次測試的所有場景都需要聯調，所有測試員都要從貨架上獲取版本。幾經周折以后才發現，包括測試經理，TSE在內的10個人，只有3個會從貨架取平臺包，只有一個會取產品包。于是所有的測試進度都停滯，等待產品包。偏偏不巧，產品的貨架包又存在不確定因素，需要和產品域的人溝通，而產品域的聯系人正巧又在開會，于是整個測試進度從上午到晚上下班，一直停滯。
導致這個個時間的根本原因就是技能儲備不充分，總結一下自己對這個事件的看法以及解決辦法：
1、對于測試策略傳達不到位；
測試經理在轉測試之后的第二天晨會才開始說明本次測試的策略，及特別注意事項，這忽略了測試人員應對新的測試需求的學習期。
再轉測試之前的一天或者轉測試后的第一個例會上，測試經理應該明確的指出本次測試涉及到的場景，功能點，所需要的配套軟件，任務分配，測試周期，測試注重點。需要注意新的測試需求是否每個測試員都能理解和操作，雖然此類文檔在服務器上都有，但是每個人的理解都是不一樣的，是需要測試經理做說明解釋。如果有三成以上的測試員對新需求不理解，需要預留時間，并組織專項培訓。確保每個測試員都能獨立動手操作。
2、技能儲備不即時，不充分；
之前的多輪轉測試中，沒有特別檢驗過一些必備的技能，是否每個測試員都具備。
在測試的過程中對于測試員技能的儲備，是一項非常重要的工作，不能總之把希望寄托在測試員本身，必須要有一些方法來強制性的讓測試員對測試過程中需要用到的測試技能充分理解和運用，比如定期的組織測試員在一起討論，實現將測試所需技能按照優先級羅列，要求每個員工說出自己對技能的理解和運用。只有這樣才能確保每個測試員都把基本的必備技能吃透，而不是莫林兩可。
3、測試員對于學習缺乏主動性，存在依賴思想
測試員總是這么想：我只是個測試員，按照測試經理提出的要求做事情就是，不需要特別的去學習，就算在測試過程中遇到不懂的事情，還是可以找老員工幫忙解決。我在這里學到的業務知識，到下一個項目就完全沒用了，所以沒必要那么認真。
如果存在這種思想，那測試員就一直是測試員，不會有提升。不可能一輩子只做一個項目，所以總會有心的開始，業務知識帶不走，但是學習知識的方式方法卻可以帶走。只有經歷這個學習業務的過程，你才能發現自己適合什么樣的學習方式。如果養成了一個良好的學習習慣，無論做什么項目，你都會是優秀的。還有要相信一個道理，除了自己以外誰都靠不住，因為這個世界，你能控制的就只有你自己。
以上言論屬個人想法，僅供參考。