How AI, OpenAI, and ChatGPT impact business and software.
Selenium practical
1. Selenium in the life of day-to-day
testing. Practical aspects.
Ruslan Strazhnyk
February 2012
2. About me
Ruslan Strazhnyk • Experience – more than 6 years in IT
• Position:
– QA Automation Engineer
• Skills:
– Python, Selenium, Jenkins
– Jmeter, Cloud Services
www.maven.co
3. Agenda
• Part1
– Selenium Grid and Jenkins
– xUnit frameworks
– Issues with some browsers
• Part2
– Selenium in the cloud. Integration with various
cloud services
– Build your own infrastructure in the cloud
7. Introduction. How do we QA?
• What do we always have:
– QA mess on the project
– How to support all specifications
– Team coordination?!
• What do we want to achieve:
– Results visibility
– Better cooperation
– Customer satisfaction
9. Selenium Grid and Jenkins plugin.
• What is Continuous Integration
• Role of Selenium Grid in CI
• Jenkins Selenium plugin
• Other plugins that should help:
– Test Report (xUnit)
– Violations, TestCoverage
– Rebuild
– Extended choice plugin
– Repository connectors
12. How can Jenkins serve you
• What it helps and what it doesn’t
• Create as many jobs as needed
• CI for you project is not only test automation
• Has a lot of really useful plugins and features
• Let your all team work on it, not only you
15. Jenkins Selenium Plugin
Pros Cons
• Almost as built-in. Easy to • Manual update to new
install and track Selenium Server through
• Console output workaround
• All in one • No control
17. Nodes tune-up
• How to add multiple OS/ browser version
support
• Different run-scripts for every browser
– Firefox profile template
– Googlechrome driver
– Iexplore security issues
• Autostart tasks
• VM environment
21. Potential Browser problems
• It all suck, no ONE FITS ALL solution
– Better to do it one by one
– Start with easier
• Windows is Windows
– Different CSS and XPATH
– Slow performance
• SSL support
• Proxy support
• Let you control the browser not browser control
you
23. Nosetests as a universal xUnit
framework
• Features
– Unitestplugin support
– Short commands
– Junit result output
• Plugins
– Include third-party plugins
– Testconfig
25. Part 2
Selenium in the cloud. Integration
with BrowserMob, SauceLabs,
ShiningPanda, AmazonEC2
26. How could cloud testing help your
project. When to turn cloud.
• When you need cloud services:
– Everybody needs unless you’re not Facebook,
Google, Cisco
– Having own cluster base is expensive
– You have a start-up and your team is remote
– You want to quickly show results to customers,
investors etc.
28. Semi-paid and semi-free services.
• A lot of services grow up recently:
– Saas services
– Cloud hosting(Amazon, Rackspace)
• You are the boss, you choose:
– Strong tech skills and you want full control –
Rackspace, Amazon EC2
– Less skills to admin – Sauce Labs, BrowserMob,
others
30. Traditional Load Testing
Pros Cons
• Everything is configurable to • Takes weeks to build good
yourself working test infrastructure
• A lot of Free tools (Jmeter, • A lot of computer power is
Grinder etc.) required to run really good
load tests
33. Ready cloud services
Pros Cons
• Already includes all services
you only start thinking of • Non-free use
• Video capturing and good • Dependency on the service
error parsing provider
• Easy API
37. Do it yourself. Dedicated Cloud
• When you need something done right, do it
yourself
• Traditional way of using cloud - PaaS
• A lot of providers, most of them have good
pricing:
– Rackspace Cloud Servers
– Amazon Web Services
– Joyent
– GoGrid
– SkytapNetworks
39. Do it yourself. Dedicated Cloud
Pros Cons
• Everything is configurable to • Takes a lot of time to build
yourself good working test
• You pay only for monthly infrastructure
hosting • Harder support
• You can switch to cloud • Needs smart Developers in
from your local-built Test to design frameworks
environment
40. Cloud
services
Selenium
Jenkins CI
Grid
Ideal QA
Environment
Multiple
xUnit
browser/OS
Framework
support
To be practical – find a balance in your testing projectsDo things rationally
How QA always like: Mess in the project. Nobody knows who is doing something. Developers don’t care about build frequency, unit tests. Testers do not know who failed the build.