Maxkit: 測試員需不需要知道系統是怎麼做的？

測試員通常會需要知道系統規格，要知道功能項目，然後才能知道要怎麼撰寫測試計畫。好一點的測試者，能夠從使用者的角度，設計測試情境。換句話說，越懂得如何去「使用」軟體的測試員，就越能勝任測試的工作。但是測試員需不需要知道更多事情，需不需要知道系統是怎麼設計出來的呢？知道更多，能不能幫助自己找出系統更多的問題呢？

如果你是專案管理者

空降的測試員
在一個大型專案中，比較會有可能配置專門的測試員，大部分的時候，或許是由專案管理者自己兼任測試工作，這時候，沒辦法對測試員期待太多，能按照測試計畫做完就算是很好的狀況了。
產品測試在那個階段？
產品的生命週期，會經過系統開發，beta release 測試，系統驗收，終端客戶使用這些階段，不同的階段，會有不同的測試焦點，例如開發時期，通常由開發者自行測試，beta release 可能會有專門的測試者進行測試，驗收後，開始會有更多前期使用者進行使用，系統上線後，終端客戶，也就是實際的使用者，在使用時，也是在測試及驗證系統的強度。

不同的角色，伴隨著不同的能力，對產品的認識程度也不同，最重要的是終端客戶的使用順不順利，但這些人，就不大可能會去了解系統是怎麼做。
測試員是消耗品，專職的測試員不適合測試同一個產品太久
要說專職的測試員是消耗品，並不是刻意貶抑或是看輕測試員的意思，而是認為測試員在反覆進行產品測試的過程中，慢慢地會因為不斷地重複，而麻痺了自己測試時的感覺。

越接近產品 release 的階段，測試的感覺就會慢慢地麻痺後，接下來就會慢慢地忽略最基本最常做的測試項目，認為這些項目都是最基本的，不會有問題，不需要注意測試。

這些問題並不是一味地強迫測試員一直努力測試就可以避免的，因為重複的動作，人性就會自然而然地慢慢地麻痺了，如果可以的話，當然可以自動化，而避免這個問題，所以，如果成本夠，人員夠，就及早把能夠自動化測試的部份補起來吧！

換句話說，有個能寫程式，將能夠自動化測試的自動測試機制做起來的人，有個長期的專案要做的話，就趕快做吧，要做這樣的測試工作的人，必須要懂得並知道系統是怎麼設計的。
產品推出後，人人都是測試員
愛你的產品的人，會常常使用你的產品，甚至會一直主動地回報系統的問題，或是希望你調整或增加某些功能，有著這樣的使用者是很幸福的事。回報問題時，就要小心地應對。

如果你是測試員

要知道自己在公司的地位
在每個組織內，都有先來後到，每個人在工作上也有能力的高低，職務上被分配承擔的責任多少不同，自然而然就會形成某個程度的地位分別，這是多人組織自然就會產生的人際關係，不管再怎麼想消弭都是會存在的。

所謂的地位，意思就是要知道自己能做什麼，能講什麼，能處理什麼事情，在能處理的範圍盡量做吧！
到底熟不熟悉這個產品
測試員首先一定要知道的是一個產品或系統的功能規格，選單上每一個功能會對其他功能產生什麼附帶的影響，輸入什麼資料後得到什麼資料，要知道這些基本的功能，基本上才能正確地測試這個產品。

對產品的熟悉程度，最終就是要知道程式是怎麼寫的，模組跟模組之間的關係是重點，系統整合就可能會產生一些問題，必須設計出對應的測試項目。
有沒有開發過其他系統
有時候因為不是實際的開發人員，勢必是無法掌握開發的細節的，就算是這樣，有開發經驗的測試人員，可以用自己的經驗去猜測實際上會是怎麼寫的，有沒有闕漏的地方，進而找出測試項目，然後發現 bug。

講起來測試員就很像是個 hacker，hacker 是個高明的測試人員，他們能夠利用各種方式，取得可能的突破口，找出並利用 bug，破解進入系統。
跟開發者的合作關係如何？
如果一個開發單位，測試員跟開發人員之間的交流是順暢的，這也是一個取得系統內部資訊的方法，拿到資訊就更能掌握系統的變化。

如果你是開發者

一邊開發就要一邊測試了
系統開發人員是系統最初的測試者，系統是程式設計師堆積程式取得的結果，當然在設計完成後，就要進行基本的測試。能把握最初的關卡，程式設計時就能減少產生 bug 的機會。
對功能越熟悉，反而會產生測試的盲點
某個功能如果在撰寫時，一直產生 bug，而且是不知道原因的 bug，為了解決問題，程式設計師難免得一直面對 bug 持續奮戰，當視野從整個系統面，為了 bug 逐漸縮小自己的焦點後，coding -> debug -> testing 的過程，會讓自己陷入在某個測試的盲點中。

這是人之常情，產生失誤並不是故意的，只能夠靠自己在每一天開始的時候，試著規劃並整理自己該做什麼事情，減少失誤發生的機會。
花一點時間跟同事 code review，會事半功倍
程式碼是很笨拙的，必須一行一行地靠程式設計師輸入程式碼，而程式的邏輯，通常是線性的，必須靠每一行程式完成線性的邏輯，寫程式的時候，會因為這樣的邏輯循環，陷入可能的失誤。

把自己的程式講給別人聽，是一種檢視自己程式的邏輯最直接的方法，一邊講就等於一邊 review，沒有考慮到的邏輯錯誤也會因為這個過程，自己就浮現出來。

到底要不要知道系統是怎麼做的？

有經驗的開發者，可以找到更多問題，但也不是全部
有經驗的開發者，即使不是系統的開發者，可以透過自己的經驗，找到可能發生的問題點，雖說並不一定會有幫助，但總是一種發現與解決問題的方法。

透過開發者的說明，也是一種 review，也可以幫助整個系統，朝更穩定的方向前進。
想像自己是開發者
如果你的工作是程式設計師，想像自己是開發者，會怎麼去實作這個功能，就會有另一種視野來看這個資訊系統。揣摩實作的過程，在查看系統時，測試時，會有不同的想法。
想像自己是使用者
使用者通常是沒有耐心的，系統開發時，內部測試時，會因為了解系統的一些問題與限制，而不會用使用者使用系統的方法去使用系統。

最常見的狀況是，當自己是使用者時，點了一個按鈕，是不會知道要等待的，點了一個按鈕，如果可以點其他地方，就有可能會產生問題，除非系統本來就是設計可以多工執行的。