如何開始進行Test Automation

How to catch up on test automation
http://blog.crisp.se/henrikkniberg/2008/01/03/1199386980000.html

03, Jan, 2008
Posted by Henrik Kniberg
Published in Henrik Kniberg's blog


許多公司或專案, 想要採用agile, 但是通常她們都不是1.0版, 因此她們有許多legacy codes, 並且重點是缺乏test automation

如果缺乏test automation, 將會使你害怕change, 因為change之後不知道原先的東西是否仍然運作正確.
如果執意修改, 很可能到user手中, bug便會被找到, 因此一連串的hot fixes便會產生, support call也會接不完
但如果因此不敢修改, 可能會導致這程式越來越不好用, 越來越不滿足客戶的需求

所以我們該怎麼辦呢?

作者認為你可能有以下幾種方法
1. 裝死不知道這件事
2. 重新撰寫這個系統, 並採用TDD的方法
3. 找不同的team投入撰寫automation, 來增加test coverage, 直到滿足為止 
4. Let the team improve test coverage a little bit each sprint.

第三種聽起來很誘人, 但是effort還是很大

作者個人認為第四種方法是比較可行, 但是要怎麼做呢?

作者提供他的做法如下:

Step 1: 列出所有的測試個案
作者根據hypothetical online banking system來列出了一些測試個案:

Change skin
Security alert
See transaction history
Block account
Add new user
Sort query results
Deposit cash
Validate transfer


Step 2: 檢視每個測試個案
(1) Highlight the risky tests, the ones that keep you awake at night.

Test case                Risk
Change skin      
Security alert           X
See transaction history  
Block account            X
Add new user  
Sort query results  
Deposit cash             X
Validate transfer        X

(2) Now think about how long each test takes to execute manually.
Which half of the tests take the longest? Highlight those.

Test case                 Risk ManualCost
Change skin      
Security alert            X
See transaction history   X
Block account             X     X
Add new user  
Sort query results        X  
Deposit cash              X
Validate transfer         X     X

(3) Think about how much work it is to write a automation scripts for each test.
Highlight the most expensive half.

Test case                 Risk  ManualCost AutoCost
Change skin                                 X
Security alert            X                 X
See transaction history           X
Block account             X       X
Add new user  
Sort query results                X         X
Deposit cash              X
Validate transfer         X       X         X


Step 3: 根據priority order來排序

作者覺得要下decision來決定哪個priority高,實在不是件容易的事. 並且這件事情是context dependent, 不同狀況可能有不同的考量

作者這裡提供了三個基本的建議:
Which do you automate first? The high risk test that is easy to test manually, or the low risk test that is difficult to test manually?
Which do you automate first? The test that is easy to do manually and easy to automate, or the test that is hard to do manually and hard to automate?
Which do you automate first? The high risk test that is hard to automate, or the low risk test that is easy to automate?

以下是作者排出來的順序
Test case                 Risk ManualCost AutoCost
Block account             X       X
Validate transfer         X       X        X
See transaction history           X
Sort query results                X        X
Deposit cash              X
Security alert            X                X
Add new user  
Change skin                                X

當然你可以用一些公式來計算, 或是用一些方式來更清楚描述
以下是作者的範例:

Test case                 Risk   ManualCost AutoCost
Block account             high    5 hrs      0.5 sp
Validate transfer         high    3 hrs      5 sp
See transaction history   medium  3 hrs      1 sp
Sort query results        medium  2 hrs      8 sp
Deposit cash              high    1.5 hrs    1 sp
Security alert            high    1 hrs      13 sp
Add new user              low     0.5 hrs    3 sp
Change skin               low     0.5 hrs    20 sp
(SP: Story Point)

作者也提醒大家, 這裡主要是排出優先順序, 所以不需要把事情搞得太複雜, 不要弄出太複雜的計算方式來佔掉大家時間


Step 4. 在每次的sprint, 來自動化一些測試個案

作者認為要跟product owner談, 是否每次iteration中, 可否安排一些時間來做test automation
你可以有以下幾種方式
"Each sprint we will implement one test automation story"
"Each sprint we will implement up to 10 story points of test automation stories"
"Each sprint we will spend about 10% of our time implementing test automation stories"
"Each sprint we will finish the product backlog stories first, and then spend the remainder of the time (if any) implementing test automation stories"
"The product owner will merge the test automation stories into the overall product backlog, and the team will treat them just like any other story."

重點不在於有做多少, 在於你有持續進行, 逐漸地把這些事情完成

或許進行到某些地方時, 你會發現可能不一定要做這麼多automation, 很可能你會認為夠了, 這時候你就可以skip剩餘的部份, 然後再處理別的地方


所以作者認為這樣做, 會讓事情比較容易可以有progress. 不知各位看倌你認為呢?

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()