1 / 25

Enhancing UI Testing with Modern Software Development Techniques

Join Christopher Taylor and Michael Longin as they explore how to leverage modern software development techniques to enhance UI testing for agile and resilient applications. This session will cover the pitfalls of traditional record/playback methods, the benefits of Acceptance Test-Driven Design (ATDD), and how to refactor tests for improved maintainability. Attendees will learn practical tools like SWAT and FitNesse, enabling them to create high-quality, automated tests that evolve with their software, thereby increasing overall testing efficiency and effectiveness.

deon
Télécharger la présentation

Enhancing UI Testing with Modern Software Development Techniques

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Applying Modern Software Development Techniques to Automating the Web UI

  2. Who we Are Christopher Taylor – Ultimate Software QA Automation/Tester Certified Scrum Master Michael Longin – Ultimate Software Software Engineer Certified Scrum Master Project Lead - SWAT

  3. 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 • “Recorders are the training wheels of the automation world” • Loosely translated from Jason Huggins @ AA-FTT 2009

  4. 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

  5. Outline • What is wrong with the record\playback technique • Applying Acceptance Test Driven Design • Refactoring • Pair testing • Comparing new methods to record\playback

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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”

  11. User Story #1: Prototype

  12. 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

  13. 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|

  14. 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|

  15. 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

  16. 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

  17. 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”

  18. User Story #2: Prototype

  19. 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:

  20. 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 shorten manual\exploratory testing phase when integrated with the creation of automation

  21. 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|

  22. 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|

  23. Recorded vs New Way (An Example) • Recorded • Unreadable • Unorganized • Not useable as documentation (concept of testable documentation) • New way • Easily readable • Robust • Testable documentation

  24. 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/

  25. Questions

More Related