軟體測試經理是這樣煉成的!(連載4)--從整體上掌控一個測試項目

                   測試空間旗下大頭針出品                    如何從整體上掌控一個測試項目     這幾天一直在一家公司做Team Building，一直想一個問題，就是如何為一個中小型公司建立測試部門。如何在這樣的公司做測試經理，也就是在實際工作中如何從整體上把控一個測試項目，這個可能也是我們學員共同面臨一個問題。    對于小公司，建立測試部門最重要的是什麼？最重要當然是公司上司的支援，公司的CTO、項目經理、以及開發人員認識到測試的重要性，并給予支援。    下面我們進入我們讨論的話題，在小公司測試一個項目是從何開始的？     盡快的熟悉公司的業務流程，通過項目經理交流或教育訓練了解公司的體系結構，然後要求公司項目經理派公司内專門懂業務的人（比如說技術支援，測試人員）與我們交流業務細節方面的知識。 這是非常重要的，這是測試的最開始部分。為什麼這麼說呢？我們以前不是說根據公司的需求文檔，生成軟體測試需求文檔，然後根據需求文檔再寫測試計劃，測試用例。現在軟體公司特别是中小型軟體公司的現狀根本不允許我們這樣做。可以說如果這樣做，黃花菜都涼了。     進公司後，盡快的熟悉公司的業務流程，盡量每個細節都要了解。然後一邊了解公司的業務流程，一邊使用公司的軟體。 通過這種方式，我們在作什麼呢？我們是了解公司的需求，現成的軟體，現成的公司業務流程，就是客戶的需求。因為既然軟體已經成型了，已經能夠使用。（ 這是我對需求的了解：公司的現有産品就是需求，但具體的實作可能有錯誤，而我們隻需要找出這樣的錯誤即可）如果我們再從需求規格書開始進行測試，那根本不太可能。有如下理由： 1。根據我對這家公司了解，軟體的需求是通過産品經理得到客戶的需求後，把需求告知給開發經理，開發經理在原來産品的基礎上，添加新功能來滿足客戶新的需求的。這樣的需求産生以及實作根本不是1天兩天的一個事情，隻憑測試人員幾天的了解和分析就能夠通過需求進行測試了，這不是天方夜譚嗎？ 2。公司的基本上沒有對需求進行文檔化，沒有比較詳細的需求規格說明書。 3。公司好不容易已經有了自己的産品，而且這個産品的主要的功能都已經實作好了，這個時候你對項目經理說，你們某幾個功能不符合需求的定義。這時項目經理非要暈菜不可。小公司都有一個特點就是要求穩定性，因為公司本身的開發流程，就不是很規範，如果你讓他從需求上，也就是從根本上改變軟體的功能，這下牽一發而動全身。對于公司來說，他們肯定是不會做的。  從以上幾個方面說明，在我們測試的時候，有一個這樣不合理的了解： 現成的軟體産品就是大體上滿足需求的産品，或者說我們要根據開發人員的了解來了解需求。我們要測試的就是找出1。功能實作有錯誤的地方2。界面或者使用習慣不符合我們使用軟體的規範的地方。3。找出軟體重要子產品中潛在的錯誤。既然這麼說， 我們測試人員該怎麼進入項目呢？ 1。首先我們根據現有的軟體産品，确定要測試子產品。 2。與公司這邊以前曾經作過簡單測試或者懂業務的人交流确定下面幾個方面：（1）那些功能子產品需要重點測試。 （2）需要什麼樣的測試政策即測試方法如功能測試，界面測試等等，可能公司還需      要比如負載測試和穩定性測試方面的工作。 （3）以前開發的進度和測試的時間安排，關于開發進度可以與項目經理交流，根據      整個開發進度來決定測試的進度。 （4）根據以上三個方面确定一個切實可行的測試計劃。 （5）有了測試計劃，下面我們就開始測試了，關于編寫測試用例最好給懂業務的人      評審一下。 二。我們能為公司帶來什麼呢？ 1。規範的各類文檔模版。 2。提供開發人員和測試人員交流的平台，如bugzilla，通過這個缺陷管理軟體，實作公司管理和解決bug的規範化的流程。當然本身這個軟體是需要給開發人員進行簡單教育訓練的，讓開發人員會使用這個軟體。 3。為公司建立了測試計劃，測試用例，缺陷報告，測試報告等等文檔庫，這個其實也是公司極其缺乏的一個方面。 4。對軟體測試正确的了解，公司的人對軟體測試的最基本的概念比如說白盒黑盒測試，最基本文檔如何編寫比如說bug報告等等   通過對這個項目的測試，基本上公司建立了内部的文檔庫，建立公司内測試和開發人員交流的平台，到下次我們再要測試的時候，再告訴公司的項目經理，測試應該從需求開始，我們需要對需求進行測試。通過這樣逐漸漸進的方式實作公司整個測試流程的規範化。也就是像我們書上所說的那樣建立公司測試的V模型。 軟體測試經理是這樣煉成的!(連載1) 軟體測試經理是這樣煉成的!(連載2) 軟體測試經理是這樣煉成的!(連載3)--淺談測試計劃