軟體測試的目的，是找出其實際行為及期待結果之間的差異。
(定義來源：Auerbach Publications, 2008, 《Software Testing and Continuous Quality Improvement, Third Edition》)
一般來說，所謂的「差異」指的是較負面的「缺陷」；不過若積極一點想，也應該包括較正面的「驚喜」。以這個定義來看，可以想像測試就像是在比對兩張重疊的描圖紙上的同一幅圖畫上的線條般，透著光、瞄著眼，指出這裡有出入、那邊要修正…之類細瑣繁複的工作。
畫有同一幅圖畫、重疊在一起的兩張描圖紙，其中一張是所謂的「原稿」；另一張就是「描稿」。假設原稿上的圖畫，其線條清晰俐落、運筆傳神，在工具足夠的情形下，例如：有舒適的座位、燈線充足的透寫台、粗細相同的繪筆，那麼理論上可以讓描稿趨近於原稿的難易度應該不會太高。這樣的工作也相對顯得單調、不需要創造性思維，只需要足夠的耐心及細心。
但是，現實世界裡會發生的事，真的有那麼簡單嗎？或說，有那麼單調嗎？
在軟體的世界裡，原稿從來都不會太清晰，甚至原稿大多還不是作者畫的！作者只提供異常抽象的概念、世界大同般的期望。如果作者是台灣風的，還可能加上想殺人滅口的成本要求。所謂成本，可能是時間、金錢或品質。
那麼誰來畫原稿呢？應該是畫家吧？很不幸，通常也不是。通常原作者就是最不懂得畫畫方法的那個人。而畫原稿的人，可能很懂得藝術史、對於名畫的歷史背景如數家珍、對於名畫的價值也很瞭解。但是，就像古典音樂聽再多次、再熟的人也無法進行任何一種樂器的演奏般，那負責畫原稿的人，通常畫技水平可能和他最後一次交中學時代美術作業的程度差不了多少。但是他長大了，經過多年看畫的經驗，他可能以為自己能以炭筆畫出噴畫效果了？或是認為灰階鉛筆畫就能充分呈現色彩氛圍？
所以實際產出的原稿到底和原作者想像的原稿，是否一致？很不幸的，通常就算可以審核，也經常性地被忽略。因為，真正的產出是「描稿」。沒人想在「原稿」上浪費時間。
在軟體的世界裡這並沒有任何值得大驚小怪的地方，因為就軟體而言，若「原稿」畫得是飛機，那麼「描稿」就是一架應該真的可以飛的飛機。
所以，現實世界裡的軟體測試，沒那麼簡單、沒那麼單調。因為「原稿」可能和作者的期望非常不一致，畫「原稿」的人的技法可能非常粗略、粗略到無法真實反應原作者的期望：即使那期望已經說的夠明白了。
「描稿」的人，一般來說，是真的畫匠。有些畫匠會自行想像原稿不清楚、不合理的部分，有些畫匠會把模糊、無法想像的部分當作什麼都沒畫上去，就直接留白下來。哪種風格比較好呢？答案在原作者身上：剛好符合的就好，不符合及根本沒畫上去的，一定不好。
所以應該自行想像，然後外加運氣是比較好的組合方式嗎？不是，當然不是。如果蓋的是一棟101大樓或是大型客機，誰敢賭這種運氣呢？沒有，我想幾乎沒有。
以往，我們會在「描稿」出圖後，找一位「審稿」的人，由對方來挑三揀四、說明哪邊的線條曲度不足、哪裡的勾勤又不夠有力。這樣的「審稿者」通常和「描稿者」不會交情太好。因為兩者經常會主觀地自行詮釋某些線條該有的樣子，而忘記去問原作者到底要什麼樣的線條？或者，「審稿者」無法具體描述某線條到底哪裡不好？只反應：怪怪的、我想不是這樣、就是缺少了點什麼。「描稿者」無所適所，可能覺得對方只是在找麻煩。
到了敏捷迭代式開發的流程裡，「審稿者」在心理上、工作內容上都應該變得幾乎完全不同。原作者的期望是什麼？和「原稿」符合程度能多少？如果提出疑問，讓該問題的答案能引導「原稿」更接近原作者的期望，變成「審稿者」的工作之一。
「原稿」和「描稿」之間的差異有哪些？該如何追查出？差異量是否能被作者所接受？這也是「審稿者」的工作了。所以「審稿者」的工作，並不是「描稿」出現後才被啟動，而是打從作者開始描述「原稿」時就開始了。「審稿者」要能輔助讓「原稿」更接近「期望」、讓「描稿」與「原稿」之間的差異在壞的方面降至最少、在好的方面被突顯。
為了達成上面的目的，「審稿者」必須參與至整個圖畫描製的整個流程、與作者、原稿畫者、描稿畫者都充份合作才行！非常不簡單！非常不單調！
回到軟體開發的故事，審稿者就是測試人員。他負責與作者(客戶)、原稿畫者(PM、分析師、架構師)、描畫者(開發單位)進行協作，其工作內容就是最終產出物與客戶期待結果之間的品質管理。
測試人員要做好以上事項，很明顯地：必須善長思考、溝通、對高質量的挑剔、善於學習並懂得團隊合作的務實者。工作內容絕對不比任何角色來得輕、人格特性更是得要有點難能可貴才行。
測試人員是專案成員中最關注品質的成員之一 (另一者為架構師)，他們是專案要順利進行的有力盟軍，絕對不是以往那種在交付前負責找麻煩就可以的角色。
沒有留言:
張貼留言