slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Applying Modern S oftware D evelopment Techniques to Automating the Web UI PowerPoint Presentation
Download Presentation
Applying Modern S oftware D evelopment Techniques to Automating the Web UI

Loading in 2 Seconds...

play fullscreen
1 / 26

Applying Modern S oftware D evelopment Techniques to Automating the Web UI - PowerPoint PPT Presentation


  • 96 Views
  • Uploaded on

Applying Modern S oftware D evelopment Techniques to Automating the Web UI. Ultimate Software: Mission Statement.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Applying Modern S oftware D evelopment Techniques to Automating the Web UI' - werner


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide2

Ultimate Software: Mission Statement

To provide United States and Canadian businesses with 200 or more employees the highest quality, most complete, and well-integrated suite of strategic human resources, payroll, and talent management solutions.

slide3

Who we Are

Christopher Taylor – Ultimate Software

Lead Process Engineer

Software Test Engineer

Certified Scrum Master

Michael Longin – Ultimate Software

Software Engineer

Certified Scrum Master Project Lead - SWAT

goals for this session
Goals For This Session
  • Attendees will gain a better understanding of how to apply modern software development techniques for UI testing in an effort to create more agile and resilient tests, as well as improve overall quality.
  • “Automated testing done right is Software Development”
    • Elfriede Dustin and Marcus Borch @ GTAC 2008
tools you will see today
Tools You Will See Today
  • SWAT
    • Simple Web Automation Toolkit
    • C# library for writing tests against a web UI
    • http://ulti-swat.wikispaces.com/
  • Fitnesse
    • Wiki based requirements test tool
    • www.fitnesse.org

Both are open source and can be used either

together or stand alone

outline
Outline
  • What is wrong with the record\playback technique
  • Applying Acceptance Test Driven Design
  • Refactoring
  • Pair testing
  • Comparing new methods to record\playback
record playback technique weaknesses
Record-Playback Technique Weaknesses
  • Brittle
      • Easily broken when features change, even when the feature is not part of the test
  • Very hard to update without re-recording
  • Not Agile
      • Can only be done when code is complete
  • Only tests what you record and not what you expect
  • Requires cleanup post recording
  • Time consuming
  • Hard to read and understand
acceptance test driven design
Acceptance Test Driven Design
  • A way of writing software where the test is written before coding has commenced
  • Not just for testing below the UI
  • A passing test demonstrates satisfaction of requirements
  • Allows both positive and negative test case scenarios
atdd as part of ui development
ATDD as part of UI development
  • Test defines the user experience
  • Programmers can code the user interface to a prewritten test
  • Automated tests are written alongside the test cases and coding effort
  • Turns vertical slicing into completed automation
how to use atdd with the ui
How to use ATDD with the UI
  • Starts with well written conditions of satisfaction
  • Automation script is developed alongside test case creation
  • Consistent naming standards are key*
      • txb -> Textbox
      • btn -> Button
      • lbl -> Label

*if naming is wrong, can be easily updated

  • Once test is complete, developer can start running the test against code
  • Once test runs green, the story is complete
user story 1 login
User Story #1 : Login
  • As a user I want to provide my username and password to login
  • Conditions of Satisfaction
    • Login and password boxes are present
    • Title should read “M&C Life Insurance”
    • Valid login should lead to homepage
      • Example login: ctaylor/password
    • Homepage should read “Welcome”
applying atdd continued
Applying ATDD continued
  • Example User Story #1
    • Title should read “M&C Life Insurance”
      • Title means an H2
      • Text reads: “M&C Life Insurance”
    • Login and Password boxes are present
      • Two text boxes
      • Login - >txbLogin
      • Password -> txbPassword
      • Login button -> btnLogin
demonstration of code
Demonstration of Code
  • Conditions of Satisfaction (Test underneath)
    • -Test Setup (Open the browser and navigate)
  • |OpenBrowser|
  • |NavigateBrowser|MCInsurance.com|
    • -Login and password boxes are present
    • |AssertElementExists|id|txbLogin|INPUT|
    • |AssertElementExists|id|txbPassword|INPUT|
demonstration of code continued
Demonstration of Code (continued)

Conditions of Satisfaction (Test underneath)

-Title should read “M&C Life Insurance”

|AssertElementExists|innerHTML| M&C Life Insurance |H2|

-Valid Login should lead to homepage

|SetElementAttribute|id|txbLogin|value|ctaylor|INPUT|

|SetElementAttribute|id|txbPassword|value|password|INPUT|

|StimulateElement|id|btnLogin|onclick|INPUT|

|AssertElementExists|Expression|innerHTML:Welcome|H1|

refactoring
Refactoring
  • Why refactor?
    • Less time to write automation
    • Less maintenance
    • Creates reusable code
    • Creates a domain specific language
  • What is refactoring?
    • For our purposes
      • Turn frequently used blocks of code into single line reusable entities
      • Use variables to make tests more robust
      • Creates an easily readable test by using English named functions
additional benefits of refactoring
Additional Benefits of Refactoring
  • Allows tests to be easily updated if core features change
    • If login changed for example, only one update needed
  • Allows those beginning to write tests to take advantage of previously created work
  • Makes tests much easier to read and debug
user story 2 view my name
User Story #2:View My Name
  • As a user, I want to be welcomed by my name after I login
  • Conditions of Satisfaction
    • My first and last name are correct
    • Title should read “Welcome ‘first name’ ‘last name’”
      • Example: “Welcome Chris Taylor”
a test refactored
A Test Refactored
  • Example:

|OpenBrowser|

|NavigateBrowser|MCInsurance.com|

|SetElementAttribute|id|txbLogin|value|ctaylor|INPUT|

|SetElementAttribute|id|txbPassword|value|password|INPUT|

|StimulateElement|id|btnLogin|onclick|INPUT|

|AssertElementExists|Expression|innerHTML:Welcome Chris Taylor|H1|

  • Becomes:

!define userName (ctaylor)

!define password (password)

!include .Macros.Login

|AssertElementExists|Expression|innerHTML:Welcome Chris Taylor|H1|

Example:

pair testing
Pair Testing
  • Benefits rival those of Pair Programming
    • http://en.wikipedia.org/wiki/Pair_programming#Benefits
      • (Yes, we did in fact just site Wikipedia)
  • Can be very effective for both writing automation and locating missing requirements
  • Two heads are always better than one
  • While automating you can also accomplish exploratory testing
  • Can replace manual testing phase with the creation of automation
recorded vs new way recorded
Recorded vs New Way (Recorded)

|OpenBrowser|

|NavigateBrowser|http://localhost/codecampwebsite|

|AssertElementExists|expression|innerHTML:M&amp.C Life Insurance|H1|

|StimulateElement|Expression|innerHtml:.INPUT id=ctl00_ContentPlaceHolder1_login_textBoxLogin name=ctl00.ContentPlaceHolder1.login.textBoxLogin.|onclick|TD|

|StimulateElement|Expression|innerHtml:.TABLE.[\r]+[\n]+.TBODY.[\r]+[\n]+.TR.[\r]+[\n]+.TD.User Name..TD.[\r]+[\n]+.TD..INPUT id=ctl00_ContentPlaceHolder1_login_textBoxLogin name=ctl00.ContentPlaceHolder1.login.textBoxLogin...TD...TR.[\r]+[\n]+.TR.[\r]+[\n]+.TD.Password..TD.[\r]+[\n]+.TD..INPUT id=ctl00_ContentPlaceHolder1_login_txbPassword type=password value="" name=ctl00.ContentPlaceHolder1.login.txbPassword...TD...TR.[\r]+[\n]+.TR.[\r]+[\n]+.TD align=middle colSpan=2..INPUT id=ctl00_ContentPlaceHolder1_login_btnLogin type=submit value=Login name=ctl00.ContentPlaceHolder1.login.btnLogin. ..TD...TR...TBODY...TABLE.|onclick|DIV|

|SetElementAttribute|id|ctl00_ContentPlaceHolder1_login_textBoxLogin|Value|ctaylor|INPUT|

|SetElementAttribute|id|ctl00_ContentPlaceHolder1_login_txbPassword|Value|password|INPUT|

|StimulateElement|Expression|id:ctl00_ContentPlaceHolder1_login_btnLogin|onclick|INPUT|

|AssertElementExists|expression|innerHTML:Welcome Chris Taylor|H2|

recorded vs new way new way
Recorded vs New Way (New way)

!define userName (ctaylor)

!define password (password)

!include .Macros.Login

|AssertElementExists|Expression|innerHTML:Welcome Chris Taylor|H1|

Login Macro

|OpenBrowser|

|NavigateBrowser|http://localhost/codecampwebsite|

|SetElementAttribute|id|txbLogin|Value|${userName}|INPUT|

|SetElementAttribute|id|txbPassword|Value|${password}|INPUT|

|StimulateElement|Expression|id:btnLogin|onclick|INPUT|

recorded vs new way an example
Recorded vs New Way (An Example)
  • Recorded
    • Unreadable
    • Unorganized
    • Not useable as documentation (concept of testable documentation)
  • New way
    • Easily readable
    • Robust
    • Testable documentation
where to get help
Where to Get Help
  • Questions
    • SWAT:
      • http://sourceforge.net/forum/?group_id=199701
    • Fitnesse:
      • http://tech.groups.yahoo.com/group/fitnesse/?v=1&t=search&ch=web&pub=groups&sec=group&slk=2
    • Email
      • michael_longin@ultimatesoftware.com
      • christopher_taylor@ultimatesoftware.com
    • Blogs
      • devXero.wordpress.com
      • www.agile-tester.com
  • Websites
    • http://www.fitnesse.org/
    • http://ulti-swat.wikispaces.com/