Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

UI Automation Success: Keeping Pace with Product Evolution

75 views

Published on

Example driven talk on how evolving products break test automation code and how test automation code can be structured to handle such changes easily.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

UI Automation Success: Keeping Pace with Product Evolution

  1. 1. UI Automation Success: Keeping Pace with Product Evolution Example driven talk on how evolving products break automation and patterns to handle them. Narayan Raman http://sahipro.com
  2. 2. Business and Software • Software enables a business • Better quality software means low risk to business • In dynamic businesses, where software and business change, Software quality systems should ensure continuity of business • Our purview in this talk is automated tests which ensure quality of software
  3. 3. Can Automation Help? • When migrating a jquery application to Angular JS? • When migrating from Angular 1 to Angular 2? • When migrating from Salesforce Classic to Salesforce Lightning? • When migrating an applet or flex application to web? • When extending a web application to mobile?
  4. 4. Problem • Rapid development is the need of the day • Automated testing should ideally help. BUT – Automation scripts break easily when applications evolve – Fixing automation scripts steals time from quality testing – Automation effort stagnates and quickly becomes obsolete
  5. 5. What does it take to be in sync? • Time needed depends on effort/people • Automation tasks and effort – Creation (manual and machine) – Execution (machine) – Reporting (machine) – Analysis (manual) – Fix (manual, iterative) • Reduce Effort: Offload to machine as much as possible • Increase people contribution
  6. 6. Utilizing multiple stake holders • Maximize ability to contribute – Version Control • Use non binary files - eg. CSV instead of Excel – Smaller, role specific files • Excel like (non code) interface for BAs • Interaction code for dev/test • Simple mapping files for element repository • Also helps in better history, diff etc. • Don’t clobber other’s work, less merge issues – Minimize programming
  7. 7. Types of Changes • Business case has changed – Eg. ST and VAT replaced by GST • Application flow has changed – Eg. “Add Beneficiary” moved from “Transfers” screen to “Requests” screen and has validation step • Application UI has changed – Elements have changed • Eg. Textbox name has changed from “login” to “signin” – Text for assertions have changed • Eg. Message “Invalid Login” has changed to “Invalid Sign in”
  8. 8. Types of Changes • Business case has changed – Eg. ST and VAT replaced by GST • Application flow has changed – Eg. “Add Beneficiary” moved from “Transfers” screen to “Requests” screen and has validation step • Application UI has changed – Elements have changed • Eg. Textbox name has changed from “login” to “signin” – Text for assertions have changed • Eg. Message “Invalid Login” has changed to “Invalid Sign in”
  9. 9. Types of Changes - Responsibility • Business case has changed – BA*, QA • Application flow has changed – BA, QA* • Application UI has changed – Dev, QA
  10. 10. Layers of Automation
  11. 11. Business Layer • Expresses business intent • Agnostic of – web application itself – Testing tool – interaction code • Eg. – Create user, Approve user, Login user • Will change if business logic itself changes • Survives across UI implementations (web or mobile or desktop), survives architectural changes.
  12. 12. Implementation Layer • Understands interactions between different actions performed on UI – Eg. function login($username, $password){ _setValue(_textbox("user"), $username); _setValue(_password("password"), $password); _click(_submit("Login")); } • Library file with implementation of keywords used in Business Layer • Will change if interaction flow changes
  13. 13. Element Repository Layer • Central repository of all elements in the automation code • Changes when a particular element changes due to HTML/Javascript changes in the application UI
  14. 14. Demo • Demo of working application and automation code – Automation code broken into different abstraction layers • Demo of modification to application and corresponding changes needed in automation code
  15. 15. What Should Change? • When migrating a jquery application to Angular JS? • When migrating from Angular 1 to Angular 2? • When migrating from Salesforce Classic to Salesforce Lightning? • When migrating an applet or flex application to web? • When extending a web application to mobile?
  16. 16. Gyan • Automation code is most useful when there is a lot of change planned in your application – Acts as a safety net and guideline • Automation code should not be thrown away when application technology changes • Building the right layers and strictly following them helps in minimal maintenance efforts and long lived useful automation scripts • QUESTIONS?
  17. 17. Thank You narayan@sahipro.com http://sahipro.com @narayanraman @sahipro

×