無論是大型軟體公司，還是小新創公司，軟體主管常會面臨到時程壓力。畢竟快速交付產品並且到市場驗證，遠比花個數年慢慢搞出一個可能沒有市場的產品來的有用。速度絕對是成功的關鍵因素。再者，孫子兵法有云：兵聞拙速，未睹巧之久也。似乎都在說速度比任何事重要。
然而，做完軟體主管，唯一不能做的事情，就是犧牲品質，現在犧牲品質，下一個犧牲的就是自己和開發團隊，接下來就是公司本身。
兵聞拙速，未睹巧之久：指的是快速決定一個方向，並不指隨便打一場品質低的仗。品質低劣士兵前往戰場只有死路一條（或者只能期待對方更差）
為什麼不能犧牲品質？
(1)如果PM/Sales/BD說可以不再太在乎品質？我需要在乎品質嗎？
當然要在乎品質，事實上，負責任的人會是決定的人。當軟體出現問題的時候，難道PM會負責改code上patch？最終負責的人就是會真正感受到痛苦，並且付出代價的人。軟體品質有問題，會付出代價的一定是軟體開發團隊。其他人既然不能承擔代價，當然就不能決定品質。
(2) 這次改動範圍大，但是有環境上的時間限制deadline-driven的開發，難道我能說品質不好就不上線嗎？例如耶誕夜12/24要上線，無論如何耶誕節都會來，已經做得差不多了難道就不上線嗎？
品質是可以有範圍定義，畢竟不能可能期待大型系統完全沒有bug。但是，即便是有環境上時間限制，如果品質真得無法達到要求，上線只會讓事情變得更糟糕。最近的例子是7 pay，而我們其實可以輕而易舉地找到很多過去的例子。
那麼，為什麼還是會被「逼」上線？許多時候軟體專案主管會認為「這是上面高層交代」他們應該理解時間這麼短，大家工作這麼拼，每天都加班，品質要是有問題應該「高層能理解」！ 這絕對是錯誤的認真，品質有問題的話，「高層」只會知道你們做得不好，更糟的是，你自己已經知道做得不好，連自己的良心也都過不去，而使用者拿到品質差的軟體，當然只是浪費他的時間，這會是個lose-lose-lose三輸的決定。相反的，直接說品質不好無法上線，高層也是知道你們做得不好，但起碼你不會對不起自己的良心，最起碼不是雙輸決定。
(3) 真的沒有時間怎麼辦？
時間資源，品質，規模範圍：這三個軟體開發的要素最多只能要兩者。不可能三者兼具。要三者兼具的話，會自動犧牲品質。然而，其實品質是可以控制，但絕對不能犧牲，因為一旦犧牲，整個軟體不能做出本來該做的事情，有再多功能，用再快時間上市都沒有意義。
因此，其實最應該考慮的是規模範圍，簡單的說就是盡量減少不必要的功能。這其實完全符合Lean-start-up（精實創業）的精神。
任何軟體專案或產品，達到高品質是開發團隊必然的目標。不過高品質並非垂手可得，它需要團隊的共識和努力才能達成。
確保品質有很多方式。過去常見的方式是瀑布式開發方式(waterfall)中，在程式設計師確定code complete之後，靠QA/QT/QC(註1)來執行測試，並且在測試週期中，驗證是否符合設計規格，並記錄追蹤問題(bug)，有時候甚且扮演催促修復的角色。因而，特別是大型團隊，專門「處理」品質的QA角色十分重要。很多時候，團隊可能面臨沒有QA的狀態，此時要如何確保品質呢？
為什麼會沒有QA
有時候，環境造就沒有QA的局面。例如，新創公司可能也只有5個人，無法有專責QA。又例如，大型企業中因資源分配不均，導致某些專案無法有專責QA。
但更多時候，沒有QA指的是，沒有能做「真正QA工作」的人。也許團隊裡面有許多人持有QA的職稱。但很可能僅做到QC/QT的工作(註1)。實務上，在軟體開發團隊中，實際做的事情其實比職稱來的重要。就品質的角度而言，QA大部分的時間應該花在開發循環「前期」或者「中期」。以Scrum中的Sprint來說，在kick-off時，QA應該花最多時間在定義DOD，決定產出的評斷標準，在sprint每天活動中，QA應該花時間在檢視產生的程式碼(code review)並且透過每個工作產出，主動改善現有品質。換言之，QA應該比單純的程式設計師，更會程式，更知道系統的交互作用細節，並能透過直接或間接修改程式，直接影響開發過程中的品質。因為，開發前中期的品質修正，效果好，成本低，遠比開發「後期」再來幾個測試循環來的有效！
簡要的說，能真正做QA工作的人，必須能比程式設計師團隊更會寫程式。起碼也要是「曾經」非常會寫程式。
如果團隊不巧沒有這樣的人，有三種方式可以在沒有QA的情況下確保軟體開發的品質：
方式一：Scrum
Scrum方法論中，概念上每個Scrum成員都是「同樣質量」。換言之，Scrum進行中重視的是產出，每個SPRINT的結果是「可交付的東西」。而Sprint中間要完成的細項，應該將品質涵蓋入內，而由自行取得該任務的人，完成其保證。
有許多作法和上面這段熬口的說明有關。首先，DOD (definition of done) 除了涵蓋unit-test之外，其實應該也涵蓋整合測試。如果不涵蓋整合測試，就應該另外有一個任務是專做測試。並且，每個story完成中，必定涵蓋這個story應該要有的使用測試(用以檢驗規格)以及回歸測試(用以檢驗是否有副作用)。這些測試，可以單獨成為一個工作，也可以作為DOD的一部分。
無論如何，基本概念是：「人人應該都可以生產程式碼，當然人人應該都可以測試」。實際執行時，或許有些人比較常「拿到」測試工作，但這並不代表這些成員就只是進行測試而已。有些人比較常拿到「寫程式性質」的工作，但並不代表這些人不負責品質。
Scrum的團隊重視每個Sprint的共同結果，此結構也讓沒有QA也能達到高品質。因此Sprint的長度不能太長，太長就會落入「團隊中自行區分QA和Engineer」的後果。
方式二：Pair Programming
Pair Programming是指兩個人一起用一台電腦，一個鍵盤來共同寫程式。這作法在2000年左右發展的Extreme Programming被大大推崇，不過能有決心推動的團隊並不常見。
由於Pair Programming讓每段程式碼至少都會被兩個人看過，而且在頭腦中想過。它可以避免大部分的低級錯誤(拼錯字)，也可以避免懶人錯誤(程式風格，漏寫unit-test)，然而，更重要的是它讓兩個程式設計師的真實想法，在執行同件事情的時候被「好好溝通」。而這更大幅避免對設計或需求的誤解。
Pair Programming似乎有效率和產能上的疑慮，但無論如何，它確實是在沒有QA的情況下，確保開發品質的絕妙方式。強烈建議閱讀一下wiki上的Pair Programming最下面的參考論文。
注意！
前兩個方式雖然符合敏捷開發的精神，並且能從系統結構層面，解決問題。然而，這兩種方式都必須要有結構性的改變，除非是剛剛成立的新團隊，要造成結構性的改變很困難，而且，即便做的好，也得花上其他心血才能有「能見度」，有能見度，才有所謂的功勞。
有兩個古時候的例子：
(a) 鶡冠子扁鵲：扁鵲曰「長兄最善，中兄次之，扁鵲最為下。」魏文侯曰：「可得聞邪？」扁鵲曰：「長兄於病視神，未有形而除之，故名不出於家。中兄治病，其在毫毛，故名不出於閭。若扁鵲者，鑱血脈，投毒藥，副肌膚，閒而名出聞於諸侯。」
(b) 孫子兵法：故善戰者之勝也，無智名，無勇功，故其戰勝不忒。
然而，對於一個軟體專案的主管而言，這些結構性的改變才是自己真正的價值。即便價值很難被衡量，但價值會永遠存在自己的手上。
如果短時間難以改變環境，可以考慮以下的方法三：
方式三：Part-time & Automation
工讀生(part-time student)和自動化測試(automation)似乎是兩個不同主題，但就確保軟體開發品質而言，把他們當做「一件事情」來處理，會有驚人的效果。
簡單的說，就是雇用3至4個優秀的工讀生，每週上班2-3天，組成工讀生團隊，執行測試任務，並且在熟練測試任務之後，開始進行測試自動化撰寫，並且在小組長(team leader)帶領下視情況參與更多品質管理的事情。這聽起來是個繁複的事情，但執行起來，遠比方法一二簡單。
其步驟如下：
(a) 選定一位以後想要朝專案經理或主管方向前進的優秀資深工程師，讓他作為工讀生團隊小組長
(b) 到各大學相關科系徵求大四以上的長期工讀生，一般來說，只要能妥善說明對他們未來就業的好處，通常可以找到足夠優秀的人。工讀生至少需要在職6個月以上。
(c) 組成團隊後，第一個月僅只需要熟悉目前軟體系統，第二個月才開始讓他們執行測試計畫，回報並記錄問題
(d) 在此過程中，由小組長指定測試內容和範圍，換言之，這段期間，其實小組長才是扮演QA的角色。而其他成員都可以將繁瑣的測試交給工讀生。然而，程式的品質仍然是所有成員負責，工讀生不在Scrum的範圍內，因此不「負擔責任」。
(e) 當測試進行2個以上SPRINT，工讀生應該已經開始覺得測試是很煩人的事情，但也應該知道品質對產品的重要性。這和在學校做專案計畫有天壤之別。因此，就可以開始由小組長領導工讀生進行測試自動化。
(f) 測試自動化並不期望把所有整合測試/回歸測試，100%統統自動化。只要把「簡單瑣碎」的測試自動化，通常就能節省一半以上的時間
(g) 通常六個月後，3-4人的工讀生團隊就能完成部分整合測試，和大部分的回歸測試。而下一輪的新工讀生，可以選擇從頭開始打造新的測試自動化，也可以接手前期工讀生做到一半的自動化。打造新的自動化通常可以用新的工具，新的角度來測試既存系統，可以讓品質在一次提高。接手前期工讀生的自動化，可以讓自動化範圍更廣，空出時間來做其他的事情
工讀生進行自動化測試的開發，對組織，對小組長，對工讀生有三贏的效果。(參考：實習生的三贏)
組織：讓沒有QA的團隊，能確保高品質的產出。除了要花些微的工讀費用之外，讓團隊成員能把瑣碎的事情下放給優秀的工讀生，使團隊成員能集中心力，但又同時負責個人生產的品質。同時，由於利用工讀生來培養小組長，讓組織能了解這個資深工程師，適不適合作為領導者，萬一不適合，頂多也是犧牲工讀生而已。
小組長：沒有人生下來就會當主管，當主管必須要有經驗，而工讀生團隊是主管最容易讓資深工程師測試自我的地方。因此小組長可透過這獨立運作的團隊，練習各種管理技能。
工讀生：大部分優秀的大四以上學生，都猜得到業界和學界的差異。許多人可能會在暑假應徵summer intern，然而其實短短兩個月，通常會做比較獨立的專案，雖然都很有趣，但是和在學校有很大的不同。加入實際開發團隊，即便只是做測試，也能了解「現實和學校」的差距，並且體會到軟體專案開發時，品質的重要性。讓有此六個月經驗的工讀生，更容易在未來找到更好的工作。
註1：關於Quality Control, Quality Test, Quality Assurance, test engineer, SQA的各種工作角色的區分，請參見wiki。然而，誠如前所述，工作角色名字不重要，做出事情才重要。
