在我剛開始接觸測試的時候，就一直沒有分清楚Testing和QA的區別，一直認爲QA的工作包括了測試的內容。直到有次去download一個測試工具的試用版，忽然發現填寫個人信息的職務選擇中就有Testing Manager，也有QA Manager，心裏已經感覺這兩者不能混爲一談。
它們到底有什麼不同呢？
首先讓我們來了解什麼是QA，軟件質量保證負責在軟件開發全過程中，監控，保證和改善實施的過程，確保所有經過協商同意的約定和流程被執行，達到其標準，並確保相關的問題被妥善處理。從某種意義上說，質量保證偏重於“預防”。
而測試是對系統或軟件進行檢查和評估，它偏重於“檢測”。也可以這樣認爲，軟件測試主要是負責“品質保障”，而軟件質量保證主要是負責“過程保障”。因爲軟件測試也是軟件開發過程中的一部分，所以QA也會檢查測試的過程是否按照規定的流程被執行。軟件測試和軟件質量保證的一個共同的目標就是兩者都是爲了提高軟件的質量。
在大部分的軟件企業內部，Testing和QA都是獨立的部門和彙報對象，負責不同的工作。這也是CMM中所要求的。但Testing和QA也是可以合成一個獨立的組織進行工作，其是否能夠發揮最大的優點視乎不同的組織和組織架構。
2）測試和調試
測試不同於調試，調試也不屬於測試。要理解這個道理很簡單，測試人員是從來不用進行調試的。測試的目的是發現錯誤，而調試則是定位和修正錯誤。調試可能發生在編碼開始之後的任何時間內，調試始終與測試是相聯的。
3）細心就可以做好測試
有些人認爲，細心的人就可以做好測試，甚至在不少招聘測試人員的要求中，也特別着重說明需要這個人細心。
首先，不管什麼行業，細心總可以看作是一個優點，沒有人喜歡丟三落四，粗枝大葉的員工。同樣，細心也是測試人員所必要擁有的條件之一。但是，細心並不代表全部，讓我們來從下面這個簡單的例子來說明。
假設有甲，乙兩個測試人員，都是剛剛開始學習測試，同時去測試一種應用軟件，除了細心程度外，兩人的其他知識和背景都完全相同。其中，甲比較粗心，乙比較細心。然後，甲和乙同時進行測試，也就是使用，操作這個應用軟件。如果這個應用程序總共有100個隱藏的缺陷的話，甲可能找到了其中的30個，乙可能找到了其中的50個。從這點來看，細心的人彷彿比粗心的人更適合來進行測試。
但仔細一想，他們兩個是在進行的不正確的測試。沒有測試計劃，沒有測試案例，即使是他們本人，如果重複進行一次測試的時候所能夠發現的問題都可能和第一次大相徑庭。測試沒有計劃性，帶有偶然性，隨便性，且不可重複。可以說，這樣的測試是沒有價值，沒有意義的測試，程序中還有大量的隱藏的問題，這樣的產品，用戶是難以接受的。
現在換成一個有經驗的軟件測試人員丙來指導他們進行測試，測試人員丙根據這個應用軟件的相關文檔和特點，制定了測試計劃，測試人員甲，乙也在丙的幫助和檢查中，完成了相關的測試案例。然後他們根據完成的測試案例去進行測試，各發現了90個隱藏的錯誤，軟件的質量得以較大的提高。這個時候的測試過程是有計劃，可以重現的測試過程，完全不依賴實際測試人員是否細心與否。此時，你就很清楚的瞭解到，做好測試，細心並不是主要的，講究方法和技巧，才能將測試真正的做好。
4）對測試人員的要求可比開發人員低
來自某招聘信息，招聘軟件開發人員和軟件測試人員各一名。學歷要求，開發人員：本科或以上，測試人員：專科或以上；來自某公司高層，“測試不就是找個人把程序安裝，運行一遍嘛”；看看軟件企業內部，開發人員的薪水明顯和測試人員不是一個檔次；來自軟件設計人員，“我們不把程序寫出來，測試能有東西測嗎？”。彷彿可以從各個方面來論證測試人員的能力會比開發人員差，事實是這樣的嗎？
如果把整個軟件企業比作一門大炮的話，銷售和市場肯定是那炮膛，開發和測試就是炮彈。如果沒有炮膛，那炮彈到的確沒太大用，當然如果你願意用手扔炮彈的話。但是如果沒有測試，開發出來的炮彈就很可能是啞彈，廢彈。輕者打中目標不會爆炸，嚴重的還沒有出膛就爆了。沒有通過檢測的炮彈，你不敢用，沒有通過測試的軟件，你就敢用嗎？測試並不是簡單的把程序安裝，運行一遍，涉及到相當多的方法，策略和技巧。在現實的軟件開發過程中，開發和測試各司其職，開發需要對設計，編程，調試非常熟悉，要有相當的知識深度，而測試就需要對書寫計劃，案例，編寫腳本，執行測試非常熟悉，同時因爲在測試中的接觸面比開發更廣，所需要的理解能力，綜合能力也要求很強，要有相當的學習能力和知識廣度。
如果開發人員的能力很強，而測試人員的能力並不相配的話，那最後也一樣會出現啞彈，只有兩方面人員的能力相當，協調一致，纔有可能做出優質的炮彈。
5）測試可以由開發人員進行
相信絕大多數的讀者都贊成測試不應該由開發人員進行。測試由專門的測試人員進行，相比之下會更快，更好，不管開發人員是自己測試自己的程序，還是和其他的開發人員進行互換測試。
測試工作需要客觀的態度和冷靜的頭腦。人們常由於各種原因具有一種不願意否定自己工作的心理，認爲揭露自己程序中的問題不是一件愉快的事情，或者自己認爲自己的程序已經沒有問題。這種心理狀態就成爲了測試自己程序的障礙。許多戶主都知道，揭掉糊牆紙（破壞性過程）是不容易的，若糊牆紙原先是由他而不是別人貼上的，他幾平會感到難以忍受的沮喪。所以，大部分程序員都由於不能使自己進入必要的精神狀態（不是抱着要揭露出自己程序中錯誤的態度），因而不能有效地測試自己的程序。在現實中，你經常可以聽到開發人員說，“不用測試了，我都測過來，不會有問題的”，也是具體的體現。
除了這個心理學問題之外，還有一個重要的問題：程序中可能包含由於程序員對問題的敘述或說明的誤解而產生的錯誤。如果是這種情況，當程序員測試自己的程序時，往往還會帶着同樣的誤解和慣性思維去測試，致使問題難以發現。
再者，可以把測試看做是寫文章，正如許多作者所知，校對或批評自己的思想，觀點是非常困難的。也就是說，在自已的工作中找出缺陷往往是人的心理狀態所不容的。
測試人員不光可以克服上述的問題，還可以以其他的角度和眼光來看到軟件產品，優秀的測試人員，還可以逼真的從客戶角度來考慮。軟件測試組織有着獨立的組織機構，可以在測試中減小軟件開發組織的干擾，獨立，專業，冷靜，客觀的測試和評估軟件產品。
所以，無論從技術上還是管理上，無論從過程還是目標的完成有效程度來看，軟件測試都應該由單獨的測試組織來進行，而不應該由開發人員進行。
6）測試可以發現所有的問題
有人認爲，只要使用正確的方法和給予足夠長的時間，就可以發現程序中所有的錯誤。這種認爲是錯誤的，除非這個應用程序足夠的簡單。
要保證一個應用程序沒有任何錯誤，一個必要要素在程序內部的所有路徑，分支，循環都已經被遍歷過。而這對於相當部分的程序是不可能的，舉例來說，一個只需要100行源代碼的C程序，其中包含了一個執行20次的循環，那麼它所包含的不同執行路徑數高達10的13方條。假設要對這麼的路徑進行窮舉測試，即使一秒鐘可以完成1000條路徑的測試，完成全部的測試也需要3170年。
以上情況說明，這樣的測試實施起來是不現實的。即使程序中沒有類似的情況，錯誤還是沒有可能完全避免。首先測試具有偶然性，輸入A數據是正確的，B數據卻可能是失敗的；即使在這次輸入A正確的，在下次另外一種環境下，同樣的A數據卻可能失敗。根據IBM的一項研究表明－一些錯誤運行幾個小時就表現出來，而其他一些錯誤要數年之後纔出現。
缺陷（錯誤）是不可以完全避免的，只能做到在允許範圍內足夠的少。