開發與測試的關系似乎總是那么的微妙�！皬妱荨钡拈_發，“弱勢”的測試，這種狀態似乎一直沒有轉變過，也一直成為測試行業內最想扭轉的一個目標。如何有效的擺脫開發的控制?
在討論這個問題之前，我們首先來談談一個公司的發展。一個公司的起家模式基本都是先有開發，后有測試這么一個過程，總之一句話，就是測試不可能在開發之前成立(專門的測試公司除外)。公司的發展模式決定了開發的優越感，也因為公司發展的初期依賴的是開發，加之公司發展初期為了自身發展，“效率優先”的原則在很大程度上影響了“一代人”(一代人：指公司創業初期的元老，這代人通常都是設計領域或者開發領域的“強人”，這代人里通常不會有測試領域的“強人”)，這一代人在公司初期項目中的習慣影響到了后續的項目，進而形成一個非常牢固的“外殼”，要想打破這個“外殼”，所需要花費的時間和精力是很難評估的。這就像我們從小形成的習慣，明知這個習慣相當不好，可是就是改不過來一樣的道理。
公司需求發展，發展需要可靠的質量保證……，這個過程是公司向正規化方向邁進的關鍵一步，而測試也是在這個過程中誕生的。測試的存在，總是讓一些人感覺非常的不舒服，因為開發在觀念上會不由的認為測試是在為難開發(這些開發可能不是很成熟)，雖然測試也一再強調我們是在協助開發完成項目，而不是為了為難開發。開發與測試是不可分離的，只是在項目中承擔各自不同的職責而已。
公司的發展有一個過程，測試部的發展同樣需要過程。測試部發展的初期，需要依賴開發的各種支持，但依賴開發的支持不能代表測試就應該喪失自己的原則。這個過程中，妥協的可能往往是測試，但妥協不代表就喪失了測試的原則。我常常對我們的測試人員說，做到心中有數，在適當的情況下，我們需要妥協，妥協的目的是為了把項目繼續下去。
測試成立的初期，首先介入的是系統測試。這個階段的測試主要是屬于功能性測試，也就是在外人開來“這里點點，那里點點”的這么一個過程。這個過程往往被外界所輕視，但在我的眼里，這是一個測試部自我能力提升，以及完善最為關鍵的階段。這個階段直接影響到后續的發展。這個階段測試部需要解決3個問題。第一個問題是學會整理“文檔”，這個過程非常重要，文檔是依據，這個階段需要的就是不恥下問，進而形成測試的依據。第二個問題是測試環境必須獨立于開發，而且必須是測試自己維護自己的測試環境。第三個問題，整理測試部的工作流程。 這個階段是測試部最困難的階段，因為這個過程實際在一定程度上觸及到了開發的一些底線，這在任何一個人來看，都是所不能容忍的。這里我最想強調的一個就是測試環境由測試部進行維護的原則。這個是作為測試人的一個底線，如果測試連自己的環境都不能維護的話，這在我看來，測試就不能完全保證測試的質量一樣的道理，舉一個簡單例子，測試的環境由別人在維護，作為測試，你能說我真的完成了某個版本的測試嗎?如果測試無法把握自己的在測試版本，測試何以保證質量?隨著測試能力的提升，集成測試就會成為測試部的發展趨勢。這個過程中，測試部會逐步接觸性能測試，接口測試等等這方面的測試，這個過程也是測試真正開始擺脫開發控制的一個關鍵。記得我們有一個項目，先前開發總認為性能上絕對不會存在任何問題，甚至在測試部提交的測試方案中，開發也是非常強硬的用“時間允許的前提下，可以考慮做一下”。這次項目測試的前期開發是主導，后期測試介入了，測試用非常有力的證據證明了開發先前的錯誤后，測試順利的拿下了性能測試的權力。
測試需要逐步擺脫開發的控制，而不是一次成功。測試在自己的翅膀還不是很強硬的時候，需要“偽裝”自己，需要低調，在不失原則的過程中逐步壯大自己，在悄無聲息中成為基石。這其實何嘗不是適合自己的發展呢?
文章來源于領測軟件測試網 http://www.kjueaiud.com/
