先問一個問題，BUG是怎麼出來的。估計會有很多人回答，是測試人員測出來的。如果測試人員連BUG都測試不出來，那還叫啥測試人員了。再繼續深入問下去，如果BUG本身就不存在，測試人員能測出來嗎？這個時候的答案應該是“不能”吧。換個角度講，測試人員只是使BUG浮出了水面，使一些人（開發人員、項目經理等）知道了他的存在。
繼續問，BUG是怎麼出來的？或者說BUG是怎麼產生的？是什麼原因使他深藏在地下？
暫時拋下這個問題，先回顧一下項目的生命週期，簡單點兒說，就是有了一個想法想做些東西出來，一直到這個東西出爐投入使用，簡單的劃分可以分爲這幾個階段。需求獲取、產品設計、實現、測試。
項目目標：攤子想支多大，產品要達到一個什麼樣的標準。
需求獲取：有了想法之後就會設定用戶羣，也有可能是反過來的。接下來就是獲取用戶的使用（如果你足夠厲害，不怕一下子就被拍死，可以自己閉門造車也可以），即需求調研。用戶的使用環境、使用場景、使用目的。。。。。恨不得自己能鑽進用戶的大腦，把用戶想要的，不想要的，所有的一切一切都弄出來，但是這是不可能的，有的時候用戶真正想要的東西可能是一，但是他表達的可能是二，獲取的過程中可能理解的是三，結果偏差了，有可能回來後整理的時候遺漏了，結果丟失了，還有可能自己沒思考，用戶說什麼就是什麼了，結果用戶拿到產品使用後說這個樣子的不是我想要的，那個那個樣子的纔是我想要的，。。。。。結果的結果，完蛋了。
產品設計：得到了用戶想用什麼，怎麼用，達到什麼樣的目的。需求獲取人員高興了樂的屁顛屁顛的向公司反饋，然後設計人員開始設計（流程設計、UI測試、架構設計。。。），等會兒，先別高興的太早，再靜下來想一下，需求獲取人員向設計人員傳達的與用戶向他講述的有偏差嗎？如果有，那就可能會失之毫釐，謬之千里，按照這樣的設計實現出來的產品不被用戶血罵那就怪了。假設需求人員向設計人員傳達的與用戶要求的是沒有偏差的，設計人員按照這樣的要求來進行設計。設計人員怎樣設計能清晰明瞭表達出用戶的真實想法。如果一味的追求完美、高口味，時尚，可用戶去偏偏是一羣土老冒，產品拿出去給人用了，結果還是捱罵。不管“界面設計的有多完美”、“交互設計有多易用”、“架構設計有多良好”，用戶用着不順手，不習慣，那用戶就是不買帳，一羣設計師們在家罵娘也沒用。
產品實現：在很多人眼裏這是一個至關重要的環節，如果沒有開發人員，就沒人把想法做成實物。事實確實是這樣的，但是開發人員總會有個很大的硬傷，喜歡沉浸在自己的世界裏，喜歡說一些只能開發人員才能吃得懂的語言，自然，他們也把這些“良好的習慣”帶到了實現上。實現時考慮正向流程，逆向和異常很少考慮，有人對此提出異議，他們會說，誰沒事兒會這樣用呀，操作還沒完成呢，就突然中斷不做了。如果界面上的說明性文字由開發人員自己來定，那結果可能就是外星文字，別人看不懂是什麼意思。
流程管理：在一個流程比較規範，而且執行的比較好的團隊，那你是幸運的。但不幸的是，這只是一種假設，這樣的環境太少太少，更多的是有流程無執行，或者啥都沒有，大家閉着眼睛做吧，東西應該是什麼樣子的，不知道，現在做到哪裏了，不有關係，做到什麼程度了，不知道。。。。。。。只知道下週一要交給用戶使用，週一交付什麼呀？呵呵，你懂的。
測試：對於測試有兩個極端的看法，一是測試的啥用都沒有，這戳戳點點的活，是人都會做。另一種看法是有了測試的，產品質量就有了保證，結果產品投放到市場，反饋回來了問題，然後說，測試的怎麼連這個都沒測出來？對測試態度從天堂轉到了地獄。說的極端點，測試不能對產品質量負責。測試只是一種驗證和確認。保證軟件以正確的方式做了這件事（do it right）和軟件做了你希望的事（do the right thing）。
產品生命週期：投入市場的產品已經過了他的生命期，這個產品就像一個老人，還一定要讓用戶買帳，那不問題多多就怪了。
總結一下，亂七八糟的說了這麼說，最想說的是每一個環節都會引入BUG，如果各個環節不能緊密相扣，最後依靠測試來BUG不是測試出來的，想要依靠測試來保證質量是不可能的。
在公司裏，如果你是一名測試人員，當產品提交測試時，某個領導笑着對你說，XXX啊，一定好好測測，多多找BUG出來，別讓客戶投訴呀。聽到這話的時候，請你的心先哆嗦哆嗦，這不是什麼好事，測試以外的環節他們可能沒有好好處理，最後把寶壓在了你的身上，你離背黑鍋不遠了。
如果你是一處於領導層，你的手下有一個很好的測試團隊，你就認爲你這個項目組做出來的產品的質量就有保證了，當你有這種想法的時候，也請你的心先哆嗦哆嗦，先看看其他的團隊，項目的各個環節、公司的內部環境、外部環境等等。
