2015/5/18

測試員需不需要知道系統是怎麼做的?

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

  • 如果你是專案管理者
  1. 空降的測試員
    在一個大型專案中,比較會有可能配置專門的測試員,大部分的時候,或許是由專案管理者自己兼任測試工作,這時候,沒辦法對測試員期待太多,能按照測試計畫做完就算是很好的狀況了。

  2. 產品測試在那個階段?
    產品的生命週期,會經過系統開發,beta release 測試,系統驗收,終端客戶使用這些階段,不同的階段,會有不同的測試焦點,例如開發時期,通常由開發者自行測試,beta release 可能會有專門的測試者進行測試,驗收後,開始會有更多前期使用者進行使用,系統上線後,終端客戶,也就是實際的使用者,在使用時,也是在測試及驗證系統的強度。

    不同的角色,伴隨著不同的能力,對產品的認識程度也不同,最重要的是終端客戶的使用順不順利,但這些人,就不大可能會去了解系統是怎麼做。

  3. 測試員是消耗品,專職的測試員不適合測試同一個產品太久
    要說專職的測試員是消耗品,並不是刻意貶抑或是看輕測試員的意思,而是認為測試員在反覆進行產品測試的過程中,慢慢地會因為不斷地重複,而麻痺了自己測試時的感覺。

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

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

    換句話說,有個能寫程式,將能夠自動化測試的自動測試機制做起來的人,有個長期的專案要做的話,就趕快做吧,要做這樣的測試工作的人,必須要懂得並知道系統是怎麼設計的。

  4. 產品推出後,人人都是測試員
    愛你的產品的人,會常常使用你的產品,甚至會一直主動地回報系統的問題,或是希望你調整或增加某些功能,有著這樣的使用者是很幸福的事。回報問題時,就要小心地應對。

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

    所謂的地位,意思就是要知道自己能做什麼,能講什麼,能處理什麼事情,在能處理的範圍盡量做吧!

  2. 到底熟不熟悉這個產品
    測試員首先一定要知道的是一個產品或系統的功能規格,選單上每一個功能會對其他功能產生什麼附帶的影響,輸入什麼資料後得到什麼資料,要知道這些基本的功能,基本上才能正確地測試這個產品。

    對產品的熟悉程度,最終就是要知道程式是怎麼寫的,模組跟模組之間的關係是重點,系統整合就可能會產生一些問題,必須設計出對應的測試項目。

  3. 有沒有開發過其他系統
    有時候因為不是實際的開發人員,勢必是無法掌握開發的細節的,就算是這樣,有開發經驗的測試人員,可以用自己的經驗去猜測實際上會是怎麼寫的,有沒有闕漏的地方,進而找出測試項目,然後發現 bug。

    講起來測試員就很像是個 hacker,hacker 是個高明的測試人員,他們能夠利用各種方式,取得可能的突破口,找出並利用 bug,破解進入系統。

  4. 跟開發者的合作關係如何?
    如果一個開發單位,測試員跟開發人員之間的交流是順暢的,這也是一個取得系統內部資訊的方法,拿到資訊就更能掌握系統的變化。

  • 如果你是開發者
  1. 一邊開發就要一邊測試了
    系統開發人員是系統最初的測試者,系統是程式設計師堆積程式取得的結果,當然在設計完成後,就要進行基本的測試。能把握最初的關卡,程式設計時就能減少產生 bug 的機會。

  2. 對功能越熟悉,反而會產生測試的盲點
    某個功能如果在撰寫時,一直產生 bug,而且是不知道原因的 bug,為了解決問題,程式設計師難免得一直面對 bug 持續奮戰,當視野從整個系統面,為了 bug 逐漸縮小自己的焦點後,coding -> debug -> testing 的過程,會讓自己陷入在某個測試的盲點中。

    這是人之常情,產生失誤並不是故意的,只能夠靠自己在每一天開始的時候,試著規劃並整理自己該做什麼事情,減少失誤發生的機會。

  3. 花一點時間跟同事 code review,會事半功倍
    程式碼是很笨拙的,必須一行一行地靠程式設計師輸入程式碼,而程式的邏輯,通常是線性的,必須靠每一行程式完成線性的邏輯,寫程式的時候,會因為這樣的邏輯循環,陷入可能的失誤。

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

  • 到底要不要知道系統是怎麼做的?
  1. 有經驗的開發者,可以找到更多問題,但也不是全部
    有經驗的開發者,即使不是系統的開發者,可以透過自己的經驗,找到可能發生的問題點,雖說並不一定會有幫助,但總是一種發現與解決問題的方法。

    透過開發者的說明,也是一種 review,也可以幫助整個系統,朝更穩定的方向前進。

  2. 想像自己是開發者
    如果你的工作是程式設計師,想像自己是開發者,會怎麼去實作這個功能,就會有另一種視野來看這個資訊系統。揣摩實作的過程,在查看系統時,測試時,會有不同的想法。

  3. 想像自己是使用者
    使用者通常是沒有耐心的,系統開發時,內部測試時,會因為了解系統的一些問題與限制,而不會用使用者使用系統的方法去使用系統。

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

  • 結論

總結一句話,能力越強,責任越大,知道越多,就越能找到更多的 bug。不管如何,如果系統出了問題,只要抱持著正面的看法,堅持下去做就對了,會逐漸變好的。

沒有留言:

張貼留言