顯示具有 沒有QA 標籤的文章。 顯示所有文章
顯示具有 沒有QA 標籤的文章。 顯示所有文章

9/14/2019

絕不犧牲品質 (軟體主管的31堂課)



無論是大型軟體公司,還是小新創公司,軟體主管常會面臨到時程壓力。畢竟快速交付產品並且到市場驗證,遠比花個數年慢慢搞出一個可能沒有市場的產品來的有用。速度絕對是成功的關鍵因素。再者,孫子兵法有云:兵聞拙速,未睹巧之久也。似乎都在說速度比任何事重要。

然而,做完軟體主管,唯一不能做的事情,就是犧牲品質,現在犧牲品質,下一個犧牲的就是自己和開發團隊,接下來就是公司本身。

兵聞拙速,未睹巧之久:指的是快速決定一個方向,並不指隨便打一場品質低的仗。品質低劣士兵前往戰場只有死路一條(或者只能期待對方更差)

為什麼不能犧牲品質?

(1)如果PM/Sales/BD說可以不再太在乎品質?我需要在乎品質嗎?


當然要在乎品質,事實上,負責任的人會是決定的人。當軟體出現問題的時候,難道PM會負責改code上patch?最終負責的人就是會真正感受到痛苦,並且付出代價的人。軟體品質有問題,會付出代價的一定是軟體開發團隊。其他人既然不能承擔代價,當然就不能決定品質。

(2) 這次改動範圍大,但是有環境上的時間限制deadline-driven的開發,難道我能說品質不好就不上線嗎?例如耶誕夜12/24要上線,無論如何耶誕節都會來,已經做得差不多了難道就不上線嗎?


品質是可以有範圍定義,畢竟不能可能期待大型系統完全沒有bug。但是,即便是有環境上時間限制,如果品質真得無法達到要求,上線只會讓事情變得更糟糕。最近的例子是7 pay,而我們其實可以輕而易舉地找到很多過去的例子。

那麼,為什麼還是會被「逼」上線?許多時候軟體專案主管會認為「這是上面高層交代」他們應該理解時間這麼短,大家工作這麼拼,每天都加班,品質要是有問題應該「高層能理解」! 這絕對是錯誤的認真,品質有問題的話,「高層」只會知道你們做得不好,更糟的是,你自己已經知道做得不好,連自己的良心也都過不去,而使用者拿到品質差的軟體,當然只是浪費他的時間,這會是個lose-lose-lose三輸的決定。相反的,直接說品質不好無法上線,高層也是知道你們做得不好,但起碼你不會對不起自己的良心,最起碼不是雙輸決定。

(3) 真的沒有時間怎麼辦?


時間資源,品質,規模範圍:這三個軟體開發的要素最多只能要兩者。不可能三者兼具。要三者兼具的話,會自動犧牲品質。然而,其實品質是可以控制,但絕對不能犧牲,因為一旦犧牲,整個軟體不能做出本來該做的事情,有再多功能,用再快時間上市都沒有意義。
因此,其實最應該考慮的是規模範圍,簡單的說就是盡量減少不必要的功能。這其實完全符合Lean-start-up(精實創業)的精神。



12/24/2017

沒有QA?如何確保軟體開發品質



任何軟體專案或產品,達到高品質是開發團隊必然的目標。不過高品質並非垂手可得,它需要團隊的共識和努力才能達成。

確保品質有很多方式。過去常見的方式是瀑布式開發方式(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。然而,誠如前所述,工作角色名字不重要,做出事情才重要。