問：我過去在另一家公司，從調研、設計數據庫設計功能、開發、測試、寫文檔、實施推動上線協調各方、培訓、修改客戶需求、接聽客戶電話都是開發部一夥人自己做。
現在這家公司還好點，有實施部，有客服部。測試就是他們在做。但也都是糊弄事，他們又不懂編程，深層次問題都測不出來，只能測些表面問題。況且，我們過去沒有詳細文檔，他們測試也只能隨便點幾下，錄幾個ABC看看能不能保存，保存後再查詢能不能出來數據，數據出來後對不對。他們又不使用系統，而客戶是每天要使用系統的，一使用問題立刻出來了，客戶說我們都把他們當測試品了。客戶抱怨很大呀，實施部對我們意見也很大，說我們質量很差。雖然說實施部應該好好測，因爲畢竟客戶出了問題先找他們，但是他們畢竟不是使用者，要麼亂點，要麼簡單敲幾個字母。怎麼測也測不出來。
我們測試確實很有問題，那測試應該怎麼做呢？
答：測試應該僱傭熟悉數據庫操作並且有客戶實施經驗的人。因爲測試不僅僅是表面的測試，而且數據庫內部變化也要測試。測試還要針對不同的測試目的，有不同的測試方法，需要準備不同的測試數據，所以讓一天在外出差培訓的實施部去臨時兼任測試是不可取的。
測試必須是開發部的一部份，是開發部的人員，而不要單獨再成立一個部門，否則又多了一條裂縫，還需要分散精力去搞定他們。
測試從開發設計的第一階段就在全程參與。從設計測試到編碼測試到幫助文檔測試。
首先，業務能不能走通，業務有沒有什麼矛盾？業務組長在設計業務功能，測試組就在測試是否有問題。
技術大牛也必須在產品設計第一階段就要全程參與。如果他一門心思就在考慮技術擴展，通用，那麼有個通用功能交給他，他根本不知道這個功能未來會如何發展，他又怎麼能設計出適合未來變化的接口呢？這也就是很多大牛學習了很多OO技術都改變不了軟件變化的問題，因爲他們根本不知道軟件會怎樣變化，只能罵中國社會變化太快也解決不了問題。
只有這樣，技術大牛在設計數據庫的時候，才能知道怎麼擴展並且結構更靈活，性能更高，並且爲編程方便、查詢方便、以後多維統計也方便。
在這裏，有一個關鍵點，就是數據庫設計由業務組長出初稿，而技術大牛出終稿的方法。爲什麼要這樣。因爲技術大牛承擔着通用功能和接口的開發，而業務組長只想着自己這個模塊的方便，所以業務組長設計的數據庫結構就有侷限性。並且業務組長是業務型人才，所以設計的結構未必能承擔以後的多維統計複雜報表的需要。而且各組組長思維不一致技術層次不一致，設計的數據庫就千奇百怪了。所以，數據庫設計必須採用這樣的方法。
技術大牛設計完數據庫結構，就需要業務組長評估測試，全程業務跑一遍，看看業務設計是否能全支持，並且非常方便的支持。
對於編碼測試，在編碼過程中我們就必須同步測試。我們不能把一切都投入進去，然後到了最後才說：我們看他能不能正常運行。當然，這樣的結果往往大半都是不能正常運行。而這時候開發人員已經以爲開發已經完成了，而且開發人員已經很疲憊心累了，早就想逃跑了，你根本無法再讓他們花100%的精力去改正錯誤。所以我們要全程測試。
測試，非常有要求。
首先，測試什麼功能。這個功能的設計界面、功能描述、輸入要求、輸出要求、數據庫存儲更新文檔都要從設計階段就參與、熟讀、評估、建議。
第二，測試什麼方面。測試有好幾個層次：
1正確的操作，正確的輸入，得到正確的輸出
2正確的操作，不正確的輸入，是否能阻攔
3不正確的操作，不正確的輸入，是否能阻攔
4速度壓力測試。錄入速度，點擊速度快，是否正常
5併發壓力測試。多人併發，是否正常
6數據量壓力測試。單筆數據量是否正常。總體數據量大，是否正常。
第三，測試人員根據測試層次以及設計文檔，設計測試數據。所以，測試人員要求有客戶經歷，至少做過客戶實施。只有這樣，才能設計出合理的測試數據，而不是亂敲幾個字母，或亂點擊，沒目標，沒層次，沒計劃。
然後，開始測試。測試完畢後，記錄下測試的時間，測試的人，測試的模塊，測試的模塊版本，測試的類型，測試的數據，測試的操作過程，測試的結果，有錯誤截屏幕下來。並且當時的數據庫數據
對於幫助文檔也要測試。因爲設計也對了，編碼也對了，但是最後客戶的使用方法錯了，那豈不是可惜。所以對幫助文檔必須測試。就按照幫助文件的做法去操作，測試是否走的和過去的設計文檔一致。
測試部門測試完了，就需要讓實施人員和客服人員內部測試了。他們對系統內部不瞭解，他們也不是開發人員的思路，他們完全是一個普通的使用者，用戶，他們會再次檢查出很多開發人員意想不到的操作引發的錯誤。
但其實，經過公司內部測試完，其實這個產品仍然是實驗室裏的產品，沒有經過客戶現實的檢驗，到底設計的功能是否真的是客戶實際操作，是否真的能解決客戶問題，客戶真的這樣使用這個功能，這些都沒有答案。我們需要去檢驗，怎麼去檢驗，我們會在下面幾講中講到。