到底該不該做UI自動化?

先從軟體交付來講,如果說TDD是讓人降低發現BUG的機率,加快軟體交付時間,那麼BDD就應該是讓人交付對的軟體。如果TDD做得很確實,軟體也都沒有BUG,但也可能交付出錯的軟體。如果最後沒有交付出對的軟體,TDD可能就變成讓你fail early, fail fast的工具。

所以在Specification by example書中提到

第一個key process pattern就是 Deriving scope from goals

201201091509065851.png

用中文翻剛好呼應某位大大寫給我的

File_000.jpeg

以Business goals的角度去設計才能使交付錯的軟體的機會降到最低

.

.

.

跳到第五步 Automating validating without changing specifications

書中就有提到如何去automate user interfaces 如何把提升UI的維護性

其中的Three levels of user interface automation

Business rule level—What is this test demonstrating or exercising? For example: Free delivery is offered to customers who order two or more books.

User workflow level—How can a user exercise the functionality through the UI, on a higher activity level? For example: Put two books in a shopping cart, enter address details, and verify that delivery options include free delivery.

Technical activity level—What are the technical steps required to exercise individual workflow steps? For example: Open the shop home page, log in with “testuser” and “testpassword,” go to the “/book” page, click the first image with the “book” CSS class, wait for the page to load, click the Buy Now link, and so on.

其實就是呼應cucumber 的格式

Feature – business rule level

Step – user workflow level

implement of step – technical activity level.

所以作者Gojko Adzic部落格多了一篇文章來教大家注意UI testing 的事項

2017-08-10_16-07-27.png

可見UI test automation是個讓人又愛又恨的工具..

回到BDD,先從BDD發明人 Dan North的定義來討論。

BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

如果要做到outside-in, multiple-stakeholder. 讓stakeholders都能看得懂的方式是,Given-When-then,把這些做成自動化,用來他們來描述可交付的東西。

回到Agile methodology,如果每個Sprint的review,要做demo的時候,直接去用 automation 去run cucumber的feature(living document),讓PO, stakeholders直接能夠從UI的角度去確認PBI是否完成 (End to End),或許可以省去不少的驗收時間,但如果用unit test物件的方式去跑automation,可能除了RD之外,stakeholders可能會對測試結果存疑。

Dan North下的結論

The vision is to have a round-trip editor so that BAs and testers can capture stories in a regular text editor that can generate stubs for the behaviour classes, all in the language of the business domain.

我的結論是 case by case

不論用GUI tests或Unit tests的角度來寫 acceptance tests都各有優缺點。

  1. 如果UI會不斷更動就真的不適合從UI切入 automation
  2. 很多邏輯是不會再UI出現,所以UI automation可測範圍還是有限
  3. 如果以驗收測試(acceptance testing)的角度,我覺得UI automation還是很好的工具
  4. 如何讓UI automation做到可維護性高,耗時短也是解法之一
  5. 以始為終,能幫助團隊做出對的軟體都是好工具!
廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s