自動化軟體測試&非自動化軟體測試

前言：
撰寫了許多Code，還需要人為一項一項測試嗎？可能非常的耗費人力、時間，而且“也不能確保每次的”再現性、重複性。這時候利用軟體本身的優點，使用軟體進行軟體的測試就是一種必須行為。網路上討論自動化軟體測試的文章千千百百種，以下參考另一篇文章所提及的關鍵點。

三個原因：Regression, Some tasks cannot be done manually, Parallel testing.

其中第一項的『Regression』，利用軟體自動化地去重復複雜、重復的行為，以得到低誤差性的測試，是很關鍵的一點，因為人為測試總是會無法百分百遵行“（精密）標準操作流程”，而軟體則可以使程序依照所傳寫好的法則去運行數百數千萬次以上而有著非常低的誤差（正常條件下＊）

第二項與第一項其實也是有點相似，但著重在測試項目的複雜性質，文中提出類似影像判別（某方面而言也是一種極大量數據）。

第三項則是建立虛擬的使用者，而非真實的使用多測試者去進行測試。

以上三點是大多建議、推崇、遵循自動化軟體測試中的幾項，其它還有更多原因就不在此討論，不過同時我想提出的則是相反的建議：什麼情況下則不適合自動化軟體測試。

1. 沒有被妥善定義的最終需求。

2. 沒有被良好設計的精密與精確標準操作流程(PPSOP)。

第一點的提出，則是衍生於醫療器材的發展，醫材法規專家林秋雄博士曾說：『Drug by discovering; Device by designing』，而推廣醫療開發領域的Stanford教授-Dr. Mochly-Rosen，在其衍生的Bio-design課程裡面也提到，『Intended Need』，在還沒被妥善定義的需求前，設計與做過多的自動化軟體測試是不恰當的。

第二點我特別定義PPSOP則是一般SOP著重在儀器/設備/實驗的成熟操作流程，但一個成熟的SOP早已經過不斷的測試與驗證，但在專案開發初期，其實定義這種SOP容易疏忽掉細節(魔鬼藏在細節裡)。所以我認為開發初期，更重要的是精密與精確標準操作流程(PPSOP)，而PP的意思是包含所有操作流程的細節外，如基本的順序、時間、數量外，還有與前後相同試驗的相關性、先後順序、測試者/研究者的操作習慣等等，都必須被記錄下來。而這就回歸到Design of Experiment (DOE)的設計是否正確、測試者/研究者是否遵循以及回饋等等。

其實第二點與第一點有重復到，都是著重在需求（Intended Need or DOE）的定義，而這兩點則分別屬於兩個不同開發階段，而這兩個階段與自動化軟體測試的交集仍然有一段距離。

此篇文僅描述一些方法概念，如何進行則又有許多眉眉角角。希望藉此記錄下來提醒自己也提醒自己參與的團隊，勿過度技術化，所謂Garbage in, garbage out，設計不良的架構/DOE，用了再好的自動化軟體測試，得到的也只是一堆”無用的大數據“而已。

*不考慮撰寫不良的程式碼、錯誤的演算法等等

Ref:
1. 3 reason to automate software testing
2. Biodesign

敏捷 or 穩健 開發??

接觸軟體工作一陣子，接觸了蠻多敘述與實際案例的開發訊息。其中有幾個如精實開發，敏捷開發或者比較傳統的穩健開發類型。在互相比較之下，可以看到各有其優缺點的觀點。

我對兩者個粗略概念如下：(以下概念不單只是存在於軟體開發)

A：敏捷開發是早期設計與取得雛型並得到實際的使用者(非開發者本人)的回饋，而不斷的精實修改朝向正確的方向。

B：而穩健開發比較著重在於完善的規劃，從大方向到小細節都定義完整在進行專案。

以上很粗略也可能不是針對其各家領域的核心思想，而我的看法以及應用的方向則是：

A：敏捷開發的應用是建立在"精實團隊人數"、"開發工具熟練度"、"未有正規化流程"三個點。(可能還有其他，有想到待補充)

B：穩健開發則是建立於"專業分工度"、"系統複雜度"、"已有正規化流程"等三個點。

只先各提出三點，而其中的定義套用在這兩種開發則可以簡易的敘述如下：

1. 團隊人數-有些團隊可能會受限於經費或者其他原因，希望/必須維持小型團隊
2. 開發工具熟練度-對於開發工具的熟練度，是否有深度與廣度的實際實力
3. 正規化流程-這點很重要，因為這包含了是否需要有對系統的"分析"、"設計"、"整合"等三大能力
4. 系統複雜度-複雜度建立在"跨領域的廣度"，以及"單一領域的深度"。
5. 專業分工度-與[開發工具熟練度][團隊人數]有交互涵蓋，這邊會想表達的是分工需要切割到多細。

以上，是對於一個系統進行開發時，其團隊所採取的方式所需考量的點。我的經驗只在於狹隘的幾個領域中，所以可能還需要在遇到新的專案或者在汲取新的概念消化後，進行增減的修正。後面會繼續記錄以上有提到的延伸文章。

軟體不軟體，硬體不硬體

我很幸運有些機會去過不同的工作工作過。想提出一些可能不應該提的檯面下問題，只是好奇心可以殺死一隻貓(若在While/ for loop內可以設定殺死無限多次)。

關於軟體的正版問題，因為我待過的某間公司，當初在推行自動化時，前一年並不是購買正版軟體(買什麼就別問了，跟我工作相關)，然後我曾經接案的公司也是如此。再來要提的是使用"流行版本軟體"本來就不是什麼不能說的秘密，學生時期或多或少都會使用到這類型的，而且現在大多數的學校都願意買校際版或者系所版本。只是一間公司營收數億到數十億，公司副總可以開千萬跑車，卻不願意花個幾萬到十幾萬的軟體，有點可笑。而在我待過的公司之間，曾經跟曾經為前主管的人討論過，他說了這麼有趣的一段話:

若公司要整合系統不買硬體那就是太過分了，而軟體還好。

所以軟體可以"偷用"(因為Copy & Paste即可)，而硬體不行，這樣說反而驗證就是因為幾乎沒有哪間公司可以跟廠商借儀器，然後一晚就可以複製出一台一樣的能力。

只是想說，同樣在評估專案計畫，軟體就如此隨性，硬體卻可以變通。硬體有所謂的租借日期，軟體一樣有試用日期。若硬體可以在短時間(租用日期內)可以評估是否可以使用，那軟體應該也行。當然!在台灣普遍不注重軟體的氛圍之下，很多公司都是從舊有人員去轉軟體(換領域很好，多學習也很好)，但是整體上根本不利業界的發展。(從此可以在衍生討論很多其他相關的問題!!!)

更甚者，當初一年多沒買正版軟體的前公司，卻願意花十幾到幾十萬讓員工去上教育訓練(一些教育訓練的價錢都很有"價值")，這種錯亂的價值觀念只能說令我啞口無言。

那時候沒想到，事後才想到想對那位先生說的是:
下次要評估新的系統，可以先去跟某某公司"借"一台儀器，借個一兩年等到系統可以使用後，再跟那間公司說我們想要跟你們買正版整套的儀器。不知道業界哪間儀器商可以說沒問題的，以後我要買儀器一定跟您們買(當然也會先借個一兩年評估啦，最好可以借了就不必付費，連租金都免!)~

PS:此文原本發布在其他專業論壇，稍微修正一些用詞遣字，重新發布在此，希望也有不同/相同想法的人回饋，以及有共同經驗的人可以提出。

當然我朋友是說:反正就是老闆貪小便宜心態.....