This document discusses web application testing using Selenium. It covers the basics of automation testing, why it is important, and how to design an automation framework with Selenium. The key points covered include setting up the architecture with different layers, writing basic Selenium tests, building out the framework, best practices like continuous integration, and tips for scaling tests. The goal is to help attendees understand how to create a robust and maintainable Selenium test automation framework.

1. WEB APPLICATION TESTING WITH SELENIUM
Sargis Sargsyan
QA Automation Engineer

2. Who This Presentation Is For
• Developers or QA (Students who will become
developer or QA)
• Know the basics of an automation tool
• In this presentation Selenium
• Want to create a real automation framework
WELCOME TO THE AUTOMATION FACTORY OF NAIRIT

3. What this Presentation Covers
• Introduction
• Basic of automation
• Why and how we’ll do it
• Designing The Architecture
• How to design an automation framework
• Creating Basic Selenium Test
• The best place to start
• Building Out The Framework
• Refactoring
• Designing framework for more tests
• Best Practices and Tips
• Continuous Integration, Scaling out, Agile, etc.
WE WILL AUTOMATE YOU!

4. INTRODUCTION
• Basic of automation
• Why and how we’ll do it

5. Type Of Automated Testing

6. UNIT TEST IS TESTING SMALL UNIT OF CODE IN ISOLATION
Unit Testing

7. INTEGRATION TESTING TEST UNITS TOGETHER, BUT STILL FOCUSES ON THE CODE
Integration Testing

8. BATS TEST THE SYSTEM FROM THE PERSPECTIVE OF THE USER
Blackbox Automated Testing (BAT)

9. THE TEST PYRAMID IS A CONCEPT DEVELOPED BY MIKE COHN
Pyramid of the Testing

10. Selenium is a web application testing
framework that allows you to write tests
in many programming languages like:
• Java
• C#
• Groovy
• Perl
• PHP
• Python
• Ruby
What is Selenium?
Selenium deploys on
• Windows,
• Linux,
• MAC OS.
It is an open-source project!

11. 2004 – Jason Huggins creates a JavaScript based tool for automatic
testing called Selenium (now it is known as Selenium Core). Later
Selenium Remote Control (aka Selenium RC) was developed to address
the “same host origin” browser policy and allow many language bindings to
control the browser at a distance
2006 – Simon Stewart started working on another web testing tool called
WebDriver
2009 – Selenium RC and WebDriver are merged into a one project called
Selenium-WebDriver (aka Selenium 2.0)
2013 – The first working draft of WebDriver API W3C Specification is
released
A Bit of History

12. Terminology
• Selenium Core
• Selenium RC
• Selenium-WebDriver
• Selenium Server
• Selenium IDE
• Selenium-Grid

13. CAN’T WE JUST USE OUR UNIT & INTEGRATION TESTS AND RUN OTHERS MANUALLY?
Why Do It?

14. IT WORKED YESTERDAY!
Regression

15. THIS TEST EXPLAINS EXACTLY WHAT I WANT AND WHAT YOU AGREED TO
Absolute Requirements

16. BATS TEST MUCH MORE PRODUCTION CODE WITH FEWER LINES OF CODE
Leverage

17. OUR APPROACH

18. TESTS DON’T DIRECTLY WORK AGAINST THE WEB APP
Separate Automation Framework
Web App Framework Tests

19. I TOTALLY UNDERSTAND WHAT THESE TEST ARE DOING.
Simple Test

20. I AM AN AUTOMATED TEST, I’LL BE DRIVING TODAY. YOU CAN ALL ME ARMAN
Test Drive Creation of Framework

21. DESIGNING THE ARCHITECTURE

22. EACH LAYER ONLY INTERACTS WITH THE LAYER IMMEDIATELY BELOW IT
Architecture

23. THE FRAMEWORK ITSELF SHOULD BE DIVIDED BY LAYERS OF FUNCTIONALITY
Thinking About Layers

24. Thinking about Ease of Use

25. THE CHOICE MAKES A HUGE DIFFERENCE
Which is Easier?
OR

26. PREPARE TO BECOME AN AUTOMATION NINJA!
Let’s Start the Coding

27. COMMON FAILURE POINTS

28. NEVER RECORD A TEST CASE!
Recorded Brittle Test

29. NEVER RECORD A TEST CASE!
Not Building a Framework

30. WHAT THE HECK AM I LOOKING AT?
Writing Test Like a Code

31. NOT EVERYTHING CAN BE AUTOMATED!
Automating Hard Things

32. • Test fail because
• The condition testes was not met
• An Assertion in the test failed
• Test error because
• Something other than what was being testes failed
• The framework threw an exception
IT IS IMPORTANT TO MAKE A DISTINCTION BETWEEN ERRORS & FAILURES
Error vs Failures

33. • Have a plan and stick to it
• Run test as part of build
• Run test locally
• Report results
• Break builds
MAKE SURE AUTOMATED TEST ARE TAKEN SERIOUSLY
Continuous Integration

34. MAKE SURE AUTOMATED TEST ARE TAKEN SERIOUSLY
Our Continuous Integration

35. HOW YOU WILL FEEL WHEN YOUR AUTOMATED TESTS ALL PASS
The End!

36. THANK YOU!
Time for Questions