做測試快兩年了，雖然我去年才畢業，但是在此之前我已經做了9個月的測試，畢業后才成為正式員工，之前的9個測試，我從一個測試新手進步到初級測試人員，十分感謝照顧我的老大，呵呵。
在我們公司，因為我們是做自己公司的產品，所以我們就不存在與用戶溝通那些業務的事項啦。所以相對而言就不用折騰了，呵呵。當一個項目下來時，我們的測試 leader會參與一個meeting，這個meeting會有PE，相關的developer，其實就是一群老大了，參與此會的目的，了解該項目的起始到結束的時間，參與的人員，該項目能實現的功能，若你是參與測試這邊的測試人員，那么你只帶了一雙耳朵是不行，你首先要想到自己測試所需要的硬件及軟件這一塊是否充分，測試人員是否足夠，若是不夠的話，你就要說出來的，因為這些都會影響你測試的進度。所以在參加這個meeting前，大家一定要提前想想我們會遇到的問題，并且在會上適時的提出。
接下來，我們會有一個SPEC，這上面有該項目主要的功能，比方說我，我主要是測application，那么一般給我們的SPEC上會有安裝方法及路徑，功能實現，UI這些。那么這就是我們獲得最重要的信息了，然后你會根據SPEC開始寫你的Test Plan，Test Plan是真的需要經驗的，經驗越豐富的leader會能cover到很多場景的，這樣會減少我們的風險。
對于軟件的測試流程，我們會有兩個階段，第一個階段我們稱為beta階段，第二個階段我們稱為RC階段，可能每個公司說法不一樣。對于beta的階段，我們也可以分很多階段的，如beta1，beta2，ect。但是在beta前，我們的coverage應該cover到了很多的場景，并且軟件也是相對很成熟的，basic function是能正常工作的，當然，我們可能會遇到一些比較變態的bug，這時開發人員也解不了的，那不關我們的事，至于能否進入RC，還是老大們決定的，我們想管也管不了(測試人員身份尷尬的一面)。進入RC的軟件，一般都是相對穩定的，那么這時的測試著重點，就不在是basic function，這時我們的coverage要cover到我們沒涉及到的場景，基本上在RC最好不要在出現很嚴重的bug了，在我們公司，要是在RC 出現了嚴重的bug，是要挨批的(明明是開發人員開發出不好的程序，但是出現問題，是我們背黑鍋的，這也是大家一直爭議的問題，對于這個問題，我覺得若是我們在之前遺漏的bug，并且我們也做了那塊的function 測試，若沒發現，這部分挨批我們是可以接受的，畢竟我們自己工作的疏忽)。若是軟件很穩定了，就可以去認證了，我們公司都是拿到微軟認證的。
拿去認證后我們的任務就大告成功了，呵呵。
文章來源于領測軟件測試網 http://www.kjueaiud.com/