曾經對軟件測試很輕視，因為我那時很無知，只是一名普通的中國程序員，這也是那時絕大多數程序員的心態，那時中國程序員最講究“編程才是硬道理”。
如今卻非常熱愛軟件測試，包括軟件測試工具，方法，理論，技術。因為我在3年的測試工作中，深刻體會到軟件測試的重要性和趣味性。此時，我已經跳出了“小程序員”的圈子，以軟件系統工程的更大視角審視軟件測試這項工作。
很長時間以來我一直被下面的問題而困惑，有些問題至今仍然只是具有膚淺的認識，而且，我感覺我做的測試項目越多，閱讀的測試書籍越多，我越感到我對軟件測試理解的越膚淺。因為我越來越感受到軟件測試的廣度和深度的無限性，它像大海寬廣，像宇宙那樣深邃。 為什么要進行軟件測試？軟件測試的前途如何？軟件測試的工具和思想誰更重要？軟件測試的最高境界是什么？
軟件測試是保證軟件質量的重要活動，是軟件項目實施的不可缺少的環節。軟件測試的直接目的是發現軟件中存在的缺陷。此為測試的有效性。
在軟件項目沒有結束之前的全部軟件缺陷主要由軟件開發人員負責，因為軟件缺陷來自程序員的編程。軟件項目結束后的軟件缺陷主要由軟件測試人員負責，因為軟件測試人員沒有在軟件發布之前的測試中沒有發現隱藏的錯誤。 但這不是絕對的，因為軟件項目是一個系統工程，軟件質量牽扯到多個部門和人員，以及需求分析，設計，編碼等各個環節和過程。軟件測試只能證明軟件存在缺陷，不能保證軟件沒有錯誤。
軟件測試不是萬能的，因為不可能發現全部的軟件缺陷，而且軟件的功能和性能不是由測試決定的。此為測試的有限性。
軟件測試目前主要以手工測試為主，自動測試工具雖然很多，但實際應用的廣度和深度還有很大潛力，自動將有很大的發展空間！。
軟件驅動開發的觀點說明了測試與編程的關系，測試應該貫穿于軟件開發的整個生命周期，編程只是軟件開發的一個環節。但往往大家非常重視軟件編程，把測試作為編程后的一個輔助環節。這是典型的本末倒置。 軟件測試的缺陷管理流程非常重要，報告的軟件缺陷的質量，應該由他人驗證，做到責任明確，方法簡便可行。
軟件測試技術不斷進步，但總體來看，國內的測試重視程度還不夠，但已經發展很快。差不多兩年之前，國內計算機書店中關于軟件測試的書籍非常稀少，如今卻琳瑯滿目，異彩紛呈。
軟件測試是個可以很快入門的職業，門檻不高，但是，不要認為什么人都可以做好軟件測試。因為會做和做好是兩個概念。軟件測試人員最好具有軟件開發經驗，理解軟件工程的知識。這是提高軟件測試能力的基礎。對于剛剛畢業的學生，如果希望今后從事軟件開發，那么，先從事一段時間的測試可能更有利于今后的編程。而對于具有多年編程經驗的程序員，如果改行做測試，更容易提高技術。 軟件測試不是孤立的活動或過程，需要開發和市場人員的參與和交流，需要軟件質量保證人員SQA的積極配合和溝通。
軟件測試的技術不斷進步，與具體測試技術相比，掌握測試的核心思想比具體技術更重要！測試的最高境界在于運用最簡單有效的測試技術，最大限度的發現軟件缺陷!
應當承認，目前國內的軟件測試工程師的地位和待遇仍然很低，而且不少測試人員存在浮躁的心態（我甚至感到整個軟件行業始終存在著浮躁的泡沫）。如何改變這種局面，這應該是個漫長的過程。當整個IT業真正以客戶為上帝時，當軟件質量成為決定企業生存和發展的決定因素時，當軟件測試工程師的測試工作給軟件企業帶來更大的經濟效益時，軟件測試工程師才會得到應有的尊重！
軟件開發是一項復雜的、創造性的協作式游戲。作為游戲它自然存在著樂趣，所以程序員們才會樂此不疲，前仆后繼。首先、這種快樂源于一種創造事物的快樂。其次、這種快樂來自于一種開發出對別人有用的東西時所帶來的滿足感。第三、快樂源自開發過程中，親眼看到軟件按自己預先設想的那種效果運行時所帶來的迷人魅力。第四、快樂源自開發過程中持續學習的快樂。最后、快樂源自開發過程中，我們能象詩人一樣，僅憑自己的想像，來建造自己的城堡時帶來的快樂。編程的快樂在于它不僅滿足了我們內心深處進行創建的渴望，而且還喚醒了每個人內心的情感。不幸的是，同樣作為游戲它也有苦惱的一面：首先、苦惱來自追求完美主義。其次、苦惱來自總是由他人來設定目標、供給資源、提供信息。第三、苦惱來自于尋找瑣碎的BUG卻是一項枯燥的、重復性的活動。第四、人們通常希望在項目接近結束時，能收斂得快一些，然而，情況卻是越接近完成，收斂得越慢。最后、苦惱來自當投入大量的辛苦勞動后，產品發布時卻面臨著陳舊過時的危險。作為軟件開發者，我們別無選擇，只有適應它們，就這樣痛并快樂著地面對每一天。
來自領導的信息只有25%被下級知道并正確理解，從下到上的反饋信息不超過10%，平等交流的信息則可達到90%以上。平等造就信任，信任增進交流。有效地進行適當的意見交流，對一個組織的氣候和生產力會產生有益和積極的影響。使顧客滿意并和他們面對面地交流，才是蠃得市場的關鍵。
管理是一種控制性游戲，在游戲面前，你只有二種選擇：或者，你確信自己能蠃，于是投入足夠多的能量來蠃得一切；或者，你不進行這個游戲，放棄它。然而，作為軟件項目管理者，你也應該知道，早投入、高風險才會有高回報。逃避風險是致命的，因為這也會讓你得不到與風險同在的利益，久而久之，你就會面臨著被市場淘汰的危險。風險是"遭受損失的可能性"，由條件、結果以及周圍的環境構成。風險和問題的區別在于：風險是尚未發生的問題，而問題是業也成真的風險，昨天的風險可能會是今天的問題。風險管理主要包括下面幾個方面：
第一、風險識別：
從頭腦想像中抽取出各種風險并加以篩選，再加上在整個開發過程中，保持持續不斷的風險發現機制，以發現新的風險。
第二、風險分析：
對風險出現的可能性和潛在的危害性進行量化分析。
第三、應急計劃：
如果識別出的風險真的出現，你將采取的應急措施。
第四、風險緩解：
為了使應急計劃得以有效實施，必須在風險轉化為真之前所采取的措施。
第五、持續的監控：
跟蹤需要管理的風險，尋找風險出現的跡象。
項目面臨的某些風險可能是致命的，發生時會使項目嚴重滯后或直接廢棄。這類風險是最需要管理的，但有效的管理它們也許會使你與你的上級發生沖突(如時間上最后期限等)，對于這類風險往往超出了你的管理權限，可以先將它們列為項目假定風險，然后把它們轉交給上級來管理。風險可能出自技術、政治、經濟、資源或其它各個方面，幾乎無所不在，并且會對項目開發、市場占有率或是達到項目目標(如進度、預算、質量等)造成災難性后果。但在所有軟件項目中，通常會共存五大核心風險，分別如下：
第一、缺乏合理的進度安排
這是導致項目滯后的最主要的原因。首先、它源于開發人員們普遍存在的樂觀主義精神，我們總是期待在實現過程中不會碰到困難，然而我們的構思是有缺陷的，因此總會發現BUG。
第二.它源于一種錯誤的認識，人員數量和開發時間是可以互換的，既投入兩倍的人數會在一半時間內完成開發工作。然而，這種理論卻忽略了隨著人數的增加，相應的也會增加新人培訓和人們相互交流所需的負擔,另外，還有任務重新分配所造成工作中斷帶來的負擔，正如Alistair Cockburn所說："最有效的交流方式是面對面的交流"當3、5個人的時候很容易做到這種交流方式，隨著人數的增長，再也很難做到這種交流方式。交流成本的增加與培訓新人所需時間成本的增加、以及任務重分配導致工作中斷成本的增加，直接導致一種結果：向進度落后的項目中增加人手，只會使進度更加落后。
第三、源于空泛的估算，管理人員特別是高層管理人員為了滿足顧客期望的日期而造成的不合理進度安排。如果分配的時間一開始就不夠，不管高層領導威脅有多么嚇人，工作也無法按時完成，如果人們察覺到管理者可能濫用權力來懲罰自己，他們就會感覺到威脅，沒有安全感。安全感的缺乏會讓人們反對變化，而在所有成功項目中，變化是唯一不變的要素之一，除非感到安全，否則人們就不會去迎接變化，只會按部就班，這樣往往喪失了很多走捷徑的好機會，而這些機會原可以大大縮減時間進度的。第四、如果你沒有認真估算產品規模，那么你預計的進度就是空中樓閣，唯一的依據只是你的希望。在估計產品規模時，除了正常的時間計算以外，不但應該將"可能需要做"的事情所需工作時間加上，還要將某些"可能不需要做"的事情所需工作時間加上。項目的超期不應歸咎于開發者的低效率。
最后、項目的滯后不是一下子造成的，而是在一天天的不知不覺中造成的，有無數種方法可以浪費一天的時間，但是沒有任何方法可以拿回一天的時間。高層管理者的不良反應肯定會對信息的完全公開造成壓制；相反，仔細區分狀態報告、毫無驚慌地接收報告、決不壓制下級，將能鼓勵誠實的進度匯報，而這會使你在第一時間掌握實際進度，把握先機，及早做出正確的修訂，從而避免了晚期才獲得這些實際信息時，那種無力挽天時的無奈。此外、也可以在項目管理中設定一個合理的進度安排和一個具有挑戰性的期望目標完成時間。期望目標和合理進度不同，期望目標完成時間，可以設為項目完成的成功率在30%左右時的日期，這樣很具有挑戰性，但不能強迫要求必須完成此期望目標。畢竟，合理進度安排才是更合理的時間安排。另外、需要指出的是現代敏捷方法論對此進行了有效改進，如XP(極限編程)中，就利用用戶素材與CRC卡，進行優先級劃分并進行快速增量迭代開發，針對原來開發的產品或第一次迭代開發后的原型完成的功能量，來計算功能點，從而估算每個CRC卡的功能點，得到總功能點來推導出比較準確的進度安排。
第二、需求的變化
從項目的角度來說，需求總是向著膨脹的方向在變化。就連去掉某些已經做好的東西，也是一種膨脹，因為它增加了工作量。開發人員交付的是用戶滿意程度，而不僅僅是實際的產品，用戶的實際需要會隨著程序的構建和使用而變化。要知道，一個活著的軟件必須面對變化，只有死掉的軟件才不會有需求變化(沒人用了)，我們應該盡早面對現實，而不是逃避，事先為它們做好思想準備。變化是好事不是什么壞事。同樣，現代敏捷方法論強調對需求變化的快速響應，如XP(極限編程)就采用快速增量迭代開發，來在短時間內開發出功能不斷增強的原型軟件提交給用戶使用的方法，來快速響應需求的變化。
第三、人員的變更
在我們有些管理者中，總是假設開發者都是可以隨便替換的，新員工馬上可以取代離去的老員工，多么愚蠢的假設。解雇員工或高的員工替換率最大的影響，是使軟件項目失去了連續性。這是在抱著這種假設的團隊文化中，大量員工會在項目進行到一半時離開，新來員工往往需要1到3個月的上道時間，在這段時間內，他們做不了什么，還經常需要其它老員工的幫助，從而浪費了其它老員工很多不必要時間，導致項目進展更加緩慢，最終造成項目的很大損失。
另外、還有一種現象在中國軟件事業中普遍存在，當正在進行一個項目時，另一個項目由于進度落后或最后期限等原因所致，高層管理者就會從你的團隊中抽掉一些人去到另一個項目中補墻。這種拆東墻補西墻的作法，往往導致的結果是兩個項目都會落后，因為它不僅十分錯誤作了團隊人員可以隨意替換的假設，而且還作了將開發人數與開發所需時間可以互換的錯誤假設。盲目的認為，投入大量人數后，新人馬上會投入新的工作，這樣項目開發所需時間就會成倍縮短。在這種組織文化中，是不會形成一支穩定的團隊的，成員整天只會忙碌著補自已的墻或為別人補墻，充當著類似消防員的角色，那兒有火那兒就有我們的身影。
同樣，現代敏捷方法論非常注重人的能力，如XP中通過權力下放、教練角色、將團隊緊密圍在一起并結對編程、小團隊組成等方式，來組成一個強有力的團隊，由于有凝聚力，所以很少有大的人員變動，他們往往可以完成兩倍于他們人數所能完成的任務。非常小的團隊能夠產生非常大的物質生產力，有時候，小團隊可以在很短時間內創造奇跡，而大型團隊極少能做到。但是，小團隊卻往往得不到足夠的政策支持，從而導致任由團隊超編，這是一種病態組織文化所致。作為管理者必須明確知道，擁有一支穩定的、有凝聚力的開發團隊是組織最大的財富，而不是障礙。
第四、規約崩潰
這種情況只有兩種結果：要么發生，要么不發生，不會有不同程度的影響。但它真的發生時，它會直接毀滅你的整個項目。在項目啟動之初，項目各方需要通過一系列商談來確定需求的范圍，規約崩潰就是指這個談判過程的崩潰。在商談期間，很多時候當遇到嚴重沖突時，由于雙方都不愿意讓步，但又不想放棄這個項目，從而導致這些沖突被掩蓋起來。最終項目便朝著一個帶著缺陷的、含混不清的目標前進了，被掩蓋的問題暫時不會打擾你，但不是永遠。盡管你可以含混說明一個產品，但不能含混構造一個產品，所以，最終在項目晚期這些問題將發生，在大半甚至所有預算時間和金錢都已付出的時候，此時，任何一方不再全力支持，都將使項目被取消。任何規格文檔中的含糊標志著不同的系統參與者之間存在著未解決的沖突。只要在開發過程中有多個參與者，就一定會有沖突存在。談判困難而調解容易，如果兩個人的利益是完全或部分相斥的，預先做好安排，準備好請雙方通過調解來解決沖突。同樣，現代敏捷方法論通過客戶的積極參與勝過合同談判的方試，來盡早發現和避免規約崩潰。
第五、低效率
對于項目成功而言，項目人員的素質、人員的組織和管理是比使用的工具或采用的技術方法更重要的因素。團隊質量是項目成功最大的決定因素，對人的關注、激勵和培養勝過一切。項目管理人員的職責不是要人們去工作，而是給人們創造工作的可能。創造力來自于個人，而不是組織架構和流程，項目管理者面臨的中心問題就是如何設計架構和流程，來提高而不是壓制人們的主動性和創造力。通過權力的向下委派，從而產生了改進的質量、提高的生產率、高漲的士氣，進而使中心的權威實際上得到了加強。就整體而言，組織機構會更加融洽和繁榮。增加加班時間只會降低生產力，壓力之下的人們無法更快地思考既也會降低生產力。使用壓力和加班的真正原因是為了在項目失敗時讓人們看上去能好受一些。
正式的過程改進程序需要花錢、花時間，特定的過程改進工作還會延緩項目進度，盡管最終會體現生產力上的收獲，它們也不可能抵消花在過程改進上的時間。多種技術的改進程序(如CMM提級)很可能讓項目比不實施這些程序完成得更晚，對于人員超編的項目，標準過程會為多余的人們制造出足夠的工作，讓所有人都忙個不停，盡管很多是無用的，這也導致生產率低下。人員超編的團隊往往生產率低下，因為它們團隊內部耦合度提高，會議時間、重復勞動和無效工作都會增加。理想的人員安排是在項目的大部分時間里由小型核心團隊來做設計工作，在開發的最后階段再逐漸加入大量人手。如果不大幅度減少調試的時間，就沒辦法讓項目大幅度提前完成，而要成比例減少調試時間，就需要成比例增加設計所需時間，因為絕大多數的錯誤源于接口缺陷，編碼前進行的正規而完善的設計，可以大幅度減少錯誤。同樣，現代敏捷方法論通過注重人、快速迭代開發、自組織的團隊和提倡可持續的開發速度，來避免跑的過快導致團隊精力耗盡、出現短期行為而導致崩潰的問題，從而保持了穩定的生產率。
精兵簡政是失敗公司使用的辦法，它讓員工負擔失敗的責任。成功公司的目標應該正好相反：興旺、發達、而人性化。
企業的最大風險則與價值相關：在低價值的項目上浪費資源，付出高價值的機會成本，就這是企業最大風險。勇于承擔風險是好事，但必須由收益來導航，愿意承擔多少風險，必須取決于能獲得多少收益。真正的項目評估不是傾向于不斷削減成本，來提高價值，而是在風險與價值之間取得平衡點。通過不確定的價值和不確定風險組合效果的凈收益圖，來指導你把資本投入到最適當的地方。我們每個軟件從業人員都必須明白：顧客真正需要的，是我們能夠給他的、某種他想得到的利益。