Recommended
More Related Content
Similar to Automation for masses or story of creation yet another automation framework @SeleniumCamp
Similar to Automation for masses or story of creation yet another automation framework @SeleniumCamp (20)
Recently uploaded
Recently uploaded (20)
Automation for masses or story of creation yet another automation framework @SeleniumCamp
- 1. Automation For Masses or story of creation yet another automation framework
- 2. About me Anton Smorodsky - work in IT since 2005 - since 2010 concentrate on Automation - was involved in develop of two Automation Frameworks - love linux and java skype : asmorodsky Gmail : edrozim@gmail.com
- 3. Agenda ● General thoughts about Automation For Masses (AFM) ● AFM 1.0 . First try ● AFM 2.0 . Wiping Excel with Java stack technologies ● Some handy features ● Future plans ● Questions
- 6. Our solution
- 7. AFM - Automation For Masses ● AFM Command – launchBrowser , click , setvalue , hoverElement ● IfCommand – conditional run ● RunStep – call to another AFM Command ARG1 ARG2 Element
- 8. Other important entities STEP AFM Command Test Case ARG1 ARG2 Element
- 9. Storage
- 10. Excel HELL ● Edit of book with 500 rows ● Endless switching between books ● Excel ODBC magic ● Test Cases sharing ● Versioning
- 11. AFM 1.0 Execution ● Shared network drive ● Windows Scheduler
- 12. New AGE - AFM 2.0 ● Replacing Excel with Java stack technologies – Excel data migrate to DB (MySQL) – Microsoft ODBC to Hibernate – Edit in Excel to edit in PrimeFaces
- 13. AFM 2.0
- 14. AFM 2.0
- 16. AFM 2.0 Execution ● Scheduling Settings – – Agent to use – Scheduler – ● BrowserType Domain RunEntity
- 17. Handy features
- 18. Sizzle locators ● jQuery locator not implemented in “pure” selenium (examples) : – .container-checkout2.clearfix.stored_cc>table>tbody>tr>td >input[type=radio] – .tab-head.clearfix:contains('Credit / Debit Card')>input – #dropdown_aria_list_4
- 19. Online tests results viewer
- 20. Online tests results viewer
- 21. Other worth to mention features ● ● ● Step warning Test Case keywords (TestNG groups analog) AFClipboard (buffer )
- 22. Integrations ● Test Link (manual test management system ) ● Jenkins AFM plugin
- 23. Future plans ● Versioning – ● StepHistory and ElementHistory Headless automation – HtmlUnit and Xvfb – PhantomJS !
- 24. Questions
Editor's Notes
- 1. Automation tests is tiny PROGRAMS written to test other PROGRAMS. Who usually write programs ? - Software Developer in Test (SDET) 2. As any PROGRAM automation tests should have : - reasonable architecture - obey general developers practice (code formatting , variables name conventions etc. ) 3. This will ease tests supportability and stability
- 1. Automation is QA responsibility 2. QA not always but very often don't have developer skills , so : - have poor understanding of OOP - ignore general developers best practices - don't have enough experience to design reasonable architecture 3. Companies don't want to invest into teach QA to achieve this skills , they just want job to be done.
- 1. Hide all developer work from QA - no need for learn any programming language - no OOP , basically we use procedure programming - no code formatting , naming conventions and etc. Test cases stored in special text format and can be viewed in “tables”
- 1. Main goal of AFM allow to write automation tests without developer skills at all 2. Basic AFM entity is Command . There are closed list of commands (99 currently ) supported by AFM , but we always extend it 3. Command has linked Element than it will be proceed against it (for example click) 4. Element is entity that hold info about physical objects on page. It has locator (By in Selenium). Also we support search within iframe 5. Commands can get input args this allow to control commands behavior 6. IfCommand allow to use conditions 7. RunStep allow to call another procedure
- 1. One command call happens during step . Step link command and element and input arguments 2. Steps are grouped into TestCases . You can run single TestCase or group several into Test Suite
- 1. 3 worksheets : case , element , step 2. each store one entity in pre-defined format 3. For example when need to run certain test case – we just read it name from case book , than filter all steps from step book that have same name in test case column
- 1. Tests became hard to read , because ALL elements that exists in system are spread only between 3 books 2. You continuously switching between 3 books 3. Excel fail to read opened file through ODBC driver 4. “Production” test cases was just in some shared folder , so we often re-write each other work . Or even delete it fully 5. No ability to have versioning (svn treat excel file as 'binary' so no diff's and etc. )
- 1. Fortunately decision was made to drop Excel usage and as replacement Java stack technologies was selected 2. Naturally that Excel tables was replaced with DBMS tables. 3. To access data we start to use Spring+Hibernate 4. To CRUD action we create web app based on Primefaces running under tomcat
- All entities organized into tables , for example here you can see Test Cases table . Edit happens by click on some test case name , button allow to view steps of certain test case
- And this is edit step dialog which you will see if you will click on some certain step
- 1. Server : consist of two separate apps Studio and Admin , have REST API which allow to do remote scheduling and get it's result . Also REST API allow to upload log/snapshots by agents. Server use hibernate to read data from DB .Server use raw sockets to communicate with Services on clients 2. Service used to update agents which actually run test cases , also periodically “ask” server for job todo . In case there is new job it will fire up the agent to run it. Clean up hang agents 3. Agent reads TS directly from DB (wrong!) . Agent translate commands in DB to exact Selenium actions
- 1. Scheduling Settings “store” answers on questions when/what/where to run 2. Because we have independent entity which store “where to run” tests are not tied with this info so it is really easy to change this 3. RunEntity created from SchedulingSettings represent some certain run
- Custom By class which was implemented because our QA think that it is faster than xpath , also it is more flexible .
- All resulting logs and snapshots are uploaded and stored on server . In Studio you can view previous runs . You can filter them by different params
- There is ability to re-run failed test cases as new Test Suite to make sure that fail is reproducible
- 1. Step warning – feature that allow temporarily “mute” exceptions from some well-known bug which was already reported. IMPORTANT :in case step marked with warning will start to pass test case will get FAIL status ! 2. Test Case keywords allow to group test cases by different conditions , Basically it is Test NG groups analog 3. Very often we need to remember some value to compare it later with some another (Example : inserted login name and name in greetings ) this feature will allow to do this
- 1. Test Link widely used within our company , so it is very handy for our QA see automation test result in same place with manual test result 2. AFM Jenkins plugin allow insert post build step that will fire AFM run just after new code deployed
- 1. One of the reasons for migration from Excel was no ability to implement version control system , which will allow easily revert automation in case of revert of production code 2. Headless automation will allow us to consume less resources . - HtmlUnit not support a lot of features - Xvfb not really “headless” - PhantomJS the only solution that we found now