1 引論
在51CMM的質(zhì)量保證論壇中，Robinzrb 的一帖 “做QA,并且感到郁悶的請進(jìn)!”，引無(wú)數英雄竟折腰。這些英雄包括思想活躍的hjhza，樂(lè )于傳道授業(yè)解惑的wtswts，喜歡指點(diǎn)江山激揚文字的vvvvvv……。為什么郁悶呢?還是先讓我們來(lái)討論一下QA的何去何從吧!
2 QA的由來(lái)
我們知道，國外很多的大公司，QA的職責就是測試(主要是系統測試)，比如IBM、CA、PeopleSoft等。其實(shí)在最初，幾乎所有的公司都是這樣的。后來(lái)，由于缺乏有效的項目計劃和項目管理，留給系統測試的時(shí)間很少(注：我以前做的一個(gè)項目，項目經(jīng)理就明確告訴我系統測試就1天，沒(méi)得商量)。另外，需求變化太快，沒(méi)有完整的需求文檔，測試人員就只能根據自己的想象來(lái)測試。這樣一來(lái)，測試就很難保障產(chǎn)品的質(zhì)量，事先預防的QA職能就應運而生。
事先預防其實(shí)是借鑒了TQM的思想，而且也符合軟件工程“缺陷越早發(fā)現越早修改越經(jīng)濟”的原則。這些思想的淵源還可以追溯到中國古代的典故中，比如曲突徙薪、扁鵲論醫術(shù)等。特別是扁鵲論醫術(shù)這個(gè)典故，我偶然在國外的一篇文章中看到了(后來(lái)在林銳的文章中也看到了)，常感嘆我們國人連祖先的思想文化遺產(chǎn)都丟的差不多了。
3 QA的現在
目前，實(shí)施CMM的企業(yè)越來(lái)越多了。CMM模型就要求建立QA角色。這里的QA類(lèi)似于過(guò)程警察，主要職責是，檢查開(kāi)發(fā)和管理活動(dòng)是否與已定的過(guò)程策略、標準和流程一致，檢查工作產(chǎn)品是否遵循模板規定的內容和格式。在這些企業(yè)中，一般還要求QA獨立于項目組，以保障評價(jià)的客觀(guān)性。從國內來(lái)看，多數的QA沒(méi)有技術(shù)背景，檢查出的偏差多為雞毛蒜皮，再加上自己沒(méi)有令人信服的背景，領(lǐng)導也不支持，當然做起來(lái)就很困難了。
缺乏信任和支持只是一個(gè)方面，QA工作本身就很具挑戰性。它要求QA具有軟件工程的知識、軟件開(kāi)發(fā)的知識、行業(yè)背景的知識、數理統計的知識、項目管理的知識、質(zhì)量管理的知識等等。
我們常常遇到這樣的問(wèn)題，改進(jìn)到一定程度就很難突破，感覺(jué)心有余而力不足了，就開(kāi)始郁悶了。后來(lái)通過(guò)學(xué)習、培訓、交流，思想和技能得到升華，又發(fā)現了木桶中最短的那塊，然后又開(kāi)始改進(jìn)，然后又遇到了玻璃天花板，然后……就這樣處于郁悶的循環(huán)中。
假使我們掌握了所有的知識，能突破所有的玻璃天花板，那是不是QA就可以一帆風(fēng)順了。答案是否定的。QA角色定義本身就有很大的局限性。QA充當的是過(guò)程警察的角色，無(wú)論是否有意義，都專(zhuān)橫地強制過(guò)程的執行，容易在項目組中造成敵對的關(guān)系，受到排擠，而且這種警察的姿態(tài)也破壞了團隊精神。如此一來(lái)，QA工作還需要的是人際關(guān)系技能，就如我以前寫(xiě)的《質(zhì)量平衡》和《QA應該獨立于項目組嗎?》一樣，藝術(shù)化地處理這種關(guān)系。
4 QA的未來(lái)
從某種程度上說(shuō)，獨立的QA審查機制是瀑布模型的產(chǎn)物。隨著(zhù)現代軟件開(kāi)發(fā)技術(shù)的演變，螺旋模型和迭代模型的興起，QA機制正在悄然發(fā)生變化。這種變化就是從獨立專(zhuān)職的QA向貫穿過(guò)程的兼職QA演變。在CMMI模型中，這種兼職的QA也是被允許的。為什么會(huì )發(fā)生這種改變呢?無(wú)論是XP、RUP還是其它先進(jìn)的方法論，都是先產(chǎn)生架構，然后再增量開(kāi)發(fā)，直到完成。這種模式中，需求和設計缺陷在各個(gè)迭代周期被所盡早發(fā)現和修復，質(zhì)量也內建于架構和過(guò)程中，項目的成本和進(jìn)度也得到保障。
到那時(shí)，是不是獨立的QA就不復存在了呢?有些成熟度較低的企業(yè)還是需要的，主要是保證過(guò)程執行的有效性和評價(jià)的客觀(guān)性。
《 質(zhì)量平衡》
前幾日，我有幸聽(tīng)了唐駿①關(guān)于“成功軟件企業(yè)的經(jīng)營(yíng)模式與文化”的演講。在會(huì )上，他談到中國目前靠軟件盈利(一定規模)的企業(yè)最多不超過(guò)5家。這一結論深深地震撼了我。難道國內成千上萬(wàn)家軟件企業(yè)都在虧損嗎?而為什么虧損呢?我想，一個(gè)個(gè)的軟件項目延期、超出預算、質(zhì)量低下是虧損的原因，而最根本的不是技術(shù)問(wèn)題，而是管理問(wèn)題。質(zhì)量管理也是很重要的方面。
從理論來(lái)看，質(zhì)量管理應該屬于項目管理的一部分。我們在實(shí)際運作過(guò)程中也不要把項目管理和質(zhì)量管理分離開(kāi)來(lái)。有些項目經(jīng)理認為“提高質(zhì)量就意味著(zhù)成本更高、延遲交付”，這是一個(gè)比較片面的觀(guān)點(diǎn)。多數情況下，質(zhì)量和進(jìn)度不是矛盾和冤家，而是可以協(xié)調和統一的。舉例來(lái)說(shuō)，移動(dòng)網(wǎng)管維護項目為完成一個(gè)約20人日的維護需求，在設計和編碼階段比計劃多花了0.5人日，測試階段就比計劃少花了6.5人日完成。這說(shuō)明質(zhì)量不但提前了進(jìn)度，而且降低了成本。在有些特殊情況下，比如規模較小、需求變化較快、進(jìn)度較緊的項目，我們可以采取更為靈活、敏捷的開(kāi)發(fā)方式，但是這些方式應該在不影響產(chǎn)品質(zhì)量的前提下進(jìn)行。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
