我是怎樣做測試管理的？
我們公司開始也是沒有測試的。
公司是創業公司，我空降的時候連賣什么東西都不確定。公司的創業僅僅出于老板對原公司的一口氣，覺 得還不如自己單干快活，公司要成為什么公司，可能想法很多。咨詢？培訓？認證？通信？數據挖掘？我從老板的書架上找到過這些書。但是真正賣什么？賣這不好 賣，賣那不好賣。誤打誤撞就進了軟件這一行當，但軟件這行是否可以持續走，是否要持續走，老板還不確定，如果賣的不好就不做軟件了，改做別的，現在是生存 階段，就顧不了許多了，有項目就接上。上面有老板關系搞定，下面有老實的干活人努力加班，項目也就過得去。
沒想到，軟件這條路，居然走下去了，還接了一個大活兒，安裝的點很多，涉及的用戶很多，從海南到新疆，從深圳到山東棗莊。
公司發動了所有實施顧問來測試，只有他們通過，才能去實施。
實施顧問大多來自剛剛畢業的應屆畢業生，對企業管理，對軟件，對行業領域，都一無所知。對測試更是一竅不通。
測試并沒有分工，每個人都測試軟件。也沒有什么測試方法，也沒有什么測試計劃，也不知道該測什么。反正也是對軟件不了解，就當是深入學習軟件吧。
開始并沒有測試報告，大家發現問題，就用電話或QQ或郵件，把問題發給開發人員。誰認識那個開發人 員，就發給那個開發人員，如果不認識一個開發人員，就發給老板了。報告中盡是不好用，不能用的詞匯。但什么功能不好用，是怎么操作導致不好用，不好用的具 體表現是什么，都沒有。
老板急眼了，怎么這么多問題。
我說有五個原因：
1、很多問題都是每個人都反映了，其實只有一個問題，只不過大家沒有分工，都測試，于是都報告
2、不少人見一個問題發一個郵件，所以看起來很多。
3、有的人測試只是隨便亂點亂輸入，咱們軟件還沒有做這種破壞性操作兼容防范。
4、不少人不了解功能，不了解行業，不了解業務，本來是對的，按他的理解是錯的
5、有些人偷懶，今天發的是這些問題反饋，后天又是同樣
我說，基于現狀，我給大家一個測試方法：
1、分工測，幾個人測試一塊功能
2、不全部測，只測試那些很常用的重點功能
3、不要電話、QQ、郵件來報告給單獨的開發人員，給我一個人發就可以了，我來判斷衡量安排。也不要隨時報告。每天下班的時候來統一發送，由各個測試小組的負責人來匯總自己組內的測試，并且把重復的問題合并掉
4、每個測試小組的每天的測試報告要連續在一起，不要今天發今天的測試EXCEL，明天是明天的測試EXCEL，這樣沒有連貫性
5、每個問題，要標好功能模塊，有測試人，有測試版本號，有測試時間，有測試操作過程，有測試輸入數據，有報錯截圖
6、先測試正常的數據輸入，正常的操作流程，是否能全部流程走通，是否數據保存正常，是否保存后的 數據還能正確的取出來。那些臨界條件測試先不要做。對于功能不易操作、界面不好看、起的窗口標題是否得當，字體是否加粗這些需求不要提。咱們目前階段的重 點是測試問題，不要把需求和找問題混在一起。
方法執行下去，問題少了許多。
前幾天大家還在抱怨這樣的軟件簡直是爛軟件，讓他們拿給客戶，肯定會被客戶打死。
現在呢，才幾天功夫，實施顧問已經覺得可以去實施了。
這就是有方法和沒方法的區別。
第一批客戶的實施終于啟動了，實施顧問奔向了全國。
到了真實的客戶那里，才發現自己的測試，自己對軟件，對業務的理解是多么的膚淺。過去發現的問題原 來都是小兒科，真正復雜的問題根本沒有測試到。給客戶一講解，客戶一問，發現原來很多功能細節沒有理解，不知道怎么給客戶解釋。于是紛紛打電話回來問。而 能回答的人只有我，我成了接線生。
我當然不能成為接線生。我一方面仍然要求他們按照過去的測試問題報告流程和方法來報告實施現場中發 現的問題，另一方面我自己寫了FAQ給實施顧問發出去。但是實施顧問仍然問，一個問題重復的問。我說你看FAQ的第XX行。他說他看了，但沒看明白（其實 是對客戶業務不了解，所以也不明白功能）。我就給他再解釋。經過多次解釋，我也了解了實施顧問的理解思路和理解層次，于是不斷修正FAQ，使 FAQ1.0、FAQ1.1.1這樣不斷發布，幾乎天天發布。我現在回過頭來想，幫助文件寫的好不好，不能你說你自己已經寫的很明白了傻瓜才看不懂，不要 這樣認為，這樣根本不解決問題。唯一的方法就是用戶理解能力有多低，你就要把幫助寫的有多低，讓他理解是目的，要不你還能怎樣呢，就這樣的人，問題還得解 決。
隨著項目的實施，公司漸漸攏回來不少錢，但是面臨了一個瓶頸，這個大項目快做完了，以后有什么活能 養活現在這么多人呢。所以，最好的做法就是把現在這個項目產生的軟件改改，變成一個產品，賣給其他的客戶，賣的越多越好。但是，其他客戶我們有關系的并不 多，所以要想銷售給其他客戶，必須拿產品說話。于是，研發部陸續加入了專職的測試人員、文案人員、美工人員，旨在提高產品的質量和包裝，希望能賣個好價 格。
所以說，專職的測試人員是這么來的。
很多軟件公司沒有測試人員，其原因就是老板搞定關系，程序員老實干活，項目質量雖然不行，但也能將 就把錢結了。既然能賺錢，干嘛要測試人員呢。除非由于質量問題，簽不到單子。除非由于質量問題，客戶不驗收不給尾款。除非公司所有人都測試還是無法達到客 戶滿意的質量。只有這樣，才會招聘專職的專業的測試人員。
測試人員一來了，開始工作。但怎么開展測試呢？文檔在哪里？
文檔只有很老的設計文檔，現在軟件和文檔已經毫無關系。為什么？原因有二：
1、都是程序員，誰來專門寫文檔。為了公司生存，我身兼數職，到處開會做項目經理或做售前，還管開發人員，還有實施人員給我打電話問軟件中某個功能怎么回事，我也分身無術。
2、都是根據實施人員、客戶、銷售人員、老板反映的需求和BUG修改。那些BUG和需求EXCEL表格倒是有，但沒法作為測試案例編寫的根據。
測試人員硬著頭皮，開始學習軟件。
幫助在哪里？沒有？
對，沒有，因為沒有寫幫助文件的人。只有打單的時候講解的PPT。
測試員暈倒。
暈完繼續學習軟件，什么是正確的什么是不正確的，測試人員也不知道，當然也不知道BUG究竟是什么樣。軟件質量仍然沒有改進。
老板問：這個測試人員是不是沒啥能力？要不要裁掉？
我說：不是他能力不行，而是咱們過去為了生存欠了太多東西。我們這會是在補過去的課。現在的文案人 員正在補幫助。有了幫助，就有了什么是正確的標準。但現在的問題是，文案人員也不了解軟件，她寫出來的也是自己猜測，所以我已經分出來一個開發人員做項目 經理，他目前專門負責把幫助文檔建立起來，但是他開發人員出身不擅長寫文檔，但他熟知軟件，所以只有他們兩個人搭配才能搞定。但這種磨合，需要時間。
就這樣，一邊測試人員瞎學習瞎測試，一邊項目經理和文案人員不斷講解不斷編寫不斷審核不斷修改。
測試人員終于可以編寫測試案例了。但他對軟件也是初步了解。由于幾年發展，軟件加入了大量客戶的需求，很多細節的東西在幫助中也沒有看到，測試人員也不知道有這個功能。所以測試來測試去，其測試結果和實施人員的測試沒多大區別，都還是在門外轉。
老板又開始沉不住氣了，旁敲側擊想裁掉測試人員，覺得他的存在沒多大意義，還是實施人員測試好。但是由于專職測試員的招聘是我提出來的，也是我的直接手下，而且這個測試人員也老實，干活勤勤懇懇，老板實在找不出什么把柄把這位開掉。
我說：他來自著名的外包公司，專職做測試，我相信他是專業的。只不過咱們過去缺的太多，所以他想測試，也是巧婦難為無米之炊。咱們可以繼續看看。
果不其然，測試人員有其獨到的軟件測試方法、軟件理解方法。很快，測試人員對軟件的理解不亞于那些多年的實施顧問，也不亞于程序員。找問題也越來越準確，越來越深入。
當然，其原因也在于這個團隊的成長，有專職的項目經理開始書寫現有功能需求修改的設計文檔。過去 的，沒有的，就讓它過去，就讓它缺失吧，但未來，不要成為過去。現在也有專職的文案，不斷在修改幫助，加深了許多。測試人員現在比文案人員理解功能更細， 更深入，經常提醒文案人員應該把某句話寫進幫助中，否則容易被用戶忽略，是個不小心就會絆倒的坑。
為了使測試人員更快速的了解客戶應用操作方法，更細節的了解特個性的功能，我讓測試人員也兼任研發 部的技術支持。有服務部的小姑娘無法解決的問題，轉到你這里解決。否則，在過去，服務部小姑娘老把電話轉給開發人員，本來就幾條槍，被客戶電話吵的無法安 心開發。而且客戶發現開發人員接聽電話處理問題更有效，所以很多客戶都是直接給開發人員打電話，服務部成了虛架子，而開發人員的開發進度被拖累，叫苦不 迭。現在有了測試人員兼任技術支持，這下解放了開發人員。開發的質量和速度提高許多。
但測試人員并沒有做技術支持的經驗，過了段時間就來和我訴苦，說現在服務部小姑娘啥也不干，都直接把電話轉到他這里來，所以他現在已經無法測試了，成了專職的服務支持人員。如果再這樣下去，軟件質量無法保證，以后的技術支持壓力更重，開發部就會成為開發+服務部門。
我給測試人員出了三個方法： 1經常遇到的問題，就做成FAQ。下一次還有小姑娘問，直接讓她看FAQ，拒不回答。 2交給他們方法和思路，不替他們親自做。親自看著她，讓她服務支持客戶。一次不會，再繼續這樣做第二次，必須讓她自己親自會了。 3每個星期六定期培訓，疑問解答。并且考試。如有講過后考試還不會者，扣錢。
另外，我也對服務部下了一個考核（當時我已經統管的服務部）：你接待了多少客戶問題，解決時間多長，多少個問題轉給開發部技術支持了，這些問題的難度級別多高。根據這些指標來衡量服務部小姑娘們的技術解決問題能力。能力差的就辭退。
這幾招后，服務部的技術支持能力蹭蹭的提高了。真是沒有鞭子不干活。測試人員兼任技術支持越做越輕松了。
我還把版本管理、打包發布交給了測試人員。起源在于有時候客戶報告了某個BUG，程序員一看好改就 直接改掉了，改完后就直接聯系客戶更新了，但是并沒有更改軟件版本號，也沒有做新的打包。于是出現了同一個版本號軟件功能表現卻不同。而且，由于項目組多 了，每個項目組組長都各有各的原因，有時候自己就打了一個包給了客戶，隨便定個版本號，起的都稀奇古怪，有的叫beta版，有的叫 6.0.20050203。這種情形導致了測試人員做測試的時候，開發人員說改了，測試人員說沒改。開發人員說已經沒有問題了，測試人員說我這里還能重復 出來。于是兩個人一起查，耗費了兩天時間，才查出來測試人員手里的和開發人員手里的不一致。
我又下了幾招：
1、開發人員絕對不能接觸客戶，不能接聽客戶電話，也不能解決客戶問題，更不能給客戶更新
2、開發人員不能沒有任務分配和設計文檔就擅自修改軟件，否則記過處分
3、大家一致使用版本管理工具、BUG管理工具、需求管理工具、任務管理工具。用工具把項目經理、開發人員、測試人員、文案人員綁定在一起，按固化流程推進流轉。
4、打包發布統一交給測試人員來做，測試人員來控制是否可以發布，發布的版本號的命名。質量達不到，有權不能發布。
現在，我們的測試已經能做邊界測試、版本兼容性測試、系統兼容性測試、壓力測試、安全測試、集成測試、破壞性測試。也已經在項目中應用全程測試，測試人員主要參與需求驗證、設計驗證、代碼驗證、文檔驗證、打包驗證。
但是，我們現在還沒有實現單元測試，開發人員就這些人，項目卻多。而且測試人員沒有編程能力。我們也沒有做更多的回歸測試，畢竟測試人員數量配備太少，而項目并行太多。
看機會吧。老板越從軟件上賺錢，他才會越舍得投入軟件。成本永遠嫌多，利潤永遠嫌少。
如果你是一名開發主管，你的老板還沒有從你負責的軟件中賺錢，而且是很快樂的很大規模的賺錢，而不是他靠他的人際關系和送禮吃飯支撐著，我想，他不會給你一毛錢的。你抱怨也沒有用，因為你沒有價值，所以投入也是沒有意義。
先去證明你的價值吧。
