This presentation discusses building a web test automation framework using open source tools including Google WebDriver. It covers understanding the current testing scenario, identifying pain points, an overview of the proposed framework including its architecture, onboarding process, and what was achieved. The framework uses a page object model and testNG reporting. It allows for structured, reusable, and multi-contributor automated testing across browsers and operating systems.

1. Web Test Automation Framework with Open
Source Tools powered by Google WebDriver
Kapil Bhalla & Nikhil Bhandari
Intuit Inc. (Bangalore)

2. What we will be doing?
Understand Present Scenario
Look at Pain Points
Framework
Q&A Discuss

3. Agenda Understand Present Scenario
ü
Present Scenario
ü
Product
ü
Development
ü
Customer
ü
Agreement
ü
What can we Do ?

4. Present Scenario - Product
Decade Old Product
Java HTML
Script
Fle Interleaved with multiple
x
technologies
DOJO
Focus on new development technologies and
framework
Web
Services
Increasing team size with newer
people
REST SOAP
AJAX

5. Present Scenario – Development
Need for Speed
Agile Development
Shorter Release Cycles
Long Testing Cycles…growing continuously with every release.
No Automation Yet !!

6. Present Scenario – Customer Expectation
FireFox 3.7
Internet Explorer 7
Should work on my current browser ! FireFox 3
Google Chrome
Internet Explorer 8
10 / 10
Internet Explorer 6 No Compromise on Quality !
Windows XP SP3
Windows XP SP2
Reliability is a must for us!
Windows Vista Should work on Operating System I use!
Windows 7
Even higher expectation from Customer Support

7. We are in agreement !

8. What Can we Do ?
Automate 
We know That!
Then What ??

9. Agenda Pain Points
ü
Pain Points in Automation
ü
Agreement

10. Pain Points
Absence of Single “Silver Bullet” tool.
Learning Curve for new automation libraries, frameworks.
Enabling multiple contributors to automation projects.
Expected Low maintenance in long run .
Poor Ease of automating test cases. (The coding way)
Diversified domain / functional knowledge among team members.
Always expensive to switch to a different automation tool/framework.

11. We are in agreement !

12. Agenda Framework
ü
Overview
ü
Onboarding
ü
Architecture
ü
What did we achieve

13. Framework an Overview
Object Oriented way to test a Web Application
It is a mechanism to enable
•
Structured testing effort
•
Multiple team members to contribute in automation
•
Leverage work done by others
Separation of concerns
•
Test code
•
Web Page Objects (Page modeling code)
•
Suite Formations
Loose Test-Tool Coupling
On demand Test Launch

14. Framework On-boarding : Page
Object
A Page Object is Object representation of a Web Page in Java Programming World.
All elements seen on the web page can be interacted with using the respective methods in the page
object. Page object uses information in Web Element Repository to interact with an element.

15. Framework On-boarding : Web Element
Repository
Refers to XML based collection of meta information about elements seen on
the Web Page. Framework uses this information to identify the Web Element
and then interact with it.
<element key="SAVE_BUTTON" findBy="ID" id="save" tag="input" name="“ xPath=""/>
Here this button is identified by using the ID and the id is "save".

16. Framework On-boarding - Tests
Test Cases : Test cases are assertions/verifications made on compilation of
workflows using one or more real web pages. Interaction with the web pages is
done using Page Objects. Example- Hit the login page, assert that the page
loaded completely and it is login page indeed.
Test Suites : These are collection of 1 or more test cases.

17. Framework On-boarding -
Packaging
It is an attempt to enable multiple contributors to contribute to the automation
project aligned with the team structure. An product area based segregation
helps both in division of work/impact areas and gives liberty to the area owner
to experiment with different ways of automating his/her area.
Packages aligned with common functionality provided by framework, like
utilities, logging features, framework code, etc.. should be clearly demarcated.

18. Framework On-boarding …
Reporting : The users can write messages to logs using the APIs exposed by the
framework. These messages are displayed in the final reports generated by the TESTNG
report engine.
Browser : Browser is a place where most of the noticeable action happens.
Test Engine :Test Engine takes in test cases and test suites and execute them.

19. Framework On-boarding -
WebDriver indirectly interact with the set of Web Driver libraries
Web Driver : Page Objects
to hook on to the Web Elements and to interact with them.
Some typical scenarios are finding an element, sending text to element, clicking
a button, reading value of an element, and so on..
User can use the libraries directly or through the APIs provided by the
framework (Recommended way is Framework APIs )

20. Framework Architecture
CONFIDENTIAL

21. Framework What did we achieve
•
Ease of use - Its only Simple Java APIs
•
Easy to extend
•
Reuse code and domain knowledge
•
Track execution flow.
•
Flexible and Powerful
•
Straightforward integration with other tools/libraries (Html Unit,
Selenium)

22. Framework is …
aggregation of various Open Source Powers enabling us to do:
§
UI testing on Multiple Browsers and Operating Systems
§
Business Logic layer testing using APIs
§
Profiling data (like page load time, first/last request, http timing, status, etc)
§
Integration with continuous integration build system with different Test Suits
classes
§
Integration Virtual Test Execution Lab and Test Case Management System.

23. Discussion

24. References
Google WebDriver Project homepage
http://code.google.com/p/webdriver/
Google Test Automation Conference (GTAC) 2007 Presentation on WebDriver
http://www.youtube.com/watch?v=tGu1ud7hk5I
Latest Revision of this presentation slides
http://docs.google.com/leaf?id=0B_NzEJt8br0aNzgzYjE5OWItMjJiZC00YjhmLWEyY2YtOWE0YmY4Z

25. Contact Info
Kapil Bhalla
bhalla.kapil.10@gmail.com
http://in.linkedin.com/pub/kapil-bhalla/7/a47/a21
Nikhil Bhandari
nikhil.bhandari@gmail.com
http://in.linkedin.com/in/nikhilbhandari

26. Why WebDriver?
•
Multi-platform support (Mac & Win)
•
Multi-browser support (IE, FF, Safari, Chrome)
•
Faster adoption of new technologies (Win7, new browsers, etc.)
•
Free. The test developers may have fewer hassles obtaining licenses
•
Tests are written in Java programming language
•
Connections to browsers are optimized for each browser (IE uses COM, FF uses
a plug-in, Safari uses AppleScript). Selenium executes javascript inside the
browser, which causes some testing complications and a risk of a "single
source error“
•
API is object oriented and "cleaner" than Selenium
•
Manipulates browsers directly (instead of hacking JavaScript code into the site)
•
Selenium and WebDriver merging! - Best of both worlds
•
Eclipse IDE

27. Browser Drivers

28. Decision Criteria – Web Driver
Developer Productivity
Good: Using tools like FireBug, IE Developer, Or source code directly (hit objects using Text,
Object/API discoverability
partial text, id - best way usually, xpath, etc...)
Training/Consulting available Active Web Driver Community, Internal Users
Simple Java Programming concepts, Normal Web Elements awareness - Buttons, Anchor, Tables
Ease of use
…
Language knowledge in team Java. Beginners 1 to 2 days are good to get going
Its GOOGLE Open Source Community - Google Web Driver. Issues get fixed and tracked. Have
Vendor responsiveness
seen post replys from simon stewart WD creator.
Cross Browser/Platform testing
IE 7/8 YES Both
FF 3.0/3.5 YES
Safari 4.0 Mac Should work
Tool/Language Features
Program Control (loops, decisions,
etc.) ALL Available, you can do almost anything
Ability to handle popups
Can handle pop ups that are certain, remaining need to be figured out.
One Time effort to build up Specific Infrastructure. (Tool Independent) Then equivalent to :
Incremental Cost
writing simple Java program.
License availability FREE (Open Source)
Other Tools Integration
Selenium, TestNG, Java Robots,
Fitnesse YES, Any tool with which Java can be easily integrated

29. Decision Criteria …
Criteria Selenium WebDriver Watir Sahi
All All Some (immature All
Browser/ Safari support)
Platform Support
Great Good Decent Small, not well
Development/Com known
Infrequent
munity
releases
Requires server Concept of Page Ruby learning manual proxy, no
Object, simple API curve frames + multiple
domains
Ease of use Hacky multiple-
domain support
Many! Java Ruby, Java JavaScript
Language Support coming
Coming? Coming… Limited Limited
Modal Dialogs