seen from United States
seen from Hong Kong SAR China
seen from China
seen from Finland
seen from United Kingdom
seen from Germany
seen from United States
seen from Germany
seen from Singapore
seen from South Korea
seen from South Africa
seen from China
seen from United States
seen from Germany
seen from Italy
seen from United Kingdom
seen from United States
seen from Singapore
seen from United States
seen from United States
Minou Sexy à Paris
Blog: https://sladdicted.blogspot.com/2020/01/minou-sexy-paris.html
Flickr: https://flic.kr/p/2i9PcGx
Facebook: https://www.facebook.com/imajica.vemoflow
InstaGram: https://www.instagram.com/imajicavemoflow/
Avatlife: https://www.avatlife.com/Imajicavemoflow
PixelVR: https://pixelvr.me/ImajicaFlow
[Video] Advanced Automated Visual Testing With Selenium (SeConf 2016 India)
Watch Adam Carmi's talk at SeConf India!
If you don’t know what visual testing is, or if you think that Sikuli is a visual test automation tool, or if you are already automating your visual tests and want to learn more on what else is out there, or if you are on your way to implement Continuous Deployment or just interested in seeing how cool image processing algorithms can be - this talk is for you!
#SeConf #SeConf15 Facebook app automation demo, running on 3 simulators (at Hilton Portland & Executive Tower)
Cross-browser unit testing JavaScript by Alan Parkinson
do you do cross browser functional testing
2/3 of crowd runs multiple browser tests, but why?
we can't test rendered things like position and pixel perfect design
and testing for functionality is slow and difficult
functional tests are slow
you need a timely feedback loop or else the devs are forced to do
costly context switching which is painful
you should only run the critical tests in actual browsers in webdriver
js test runner:
karma https://github.com/karma-runner/karma and karma webdriver launcher https://github.com/hindsightsoftware/karma-webdriver-launcher
talks to existing Selenium grid (can reuse existing webdriver infrastructure, inc saucelabs)
node.js
TODO ideas!
run files every time they change, automatically?
starting browsers is super slow, can we do something clever to save time? or re-use?
devs do TDD and use code-coverage tools to assess where QA needs to write additional tests
karma webdriver launcher goes to a wide array of reports, do we need to write a better one? an exporter perhaps ?
how cucumber can improve your testing by Titus Fortner
cucumber?
it's not a magic bullet! gherkin given when then, steps, regexes to match strings, webdriver does things based on match
cucumber != bdd/atdd
homeaway
vacation home service. incorporate companies all from all over and merge front-end/back-end. constantly adding new services.
1000s of test cases per brand
audience
who cares about your test and what is their level of technicality ?
where do you need communication? traditional specs go out of date, devs don't understand 'em, and QA is left in the wind.
putting it in cucumber hopefully means you have living documentation - changes to website need to be reflected in changes to cucumber
cucumber helps focus on the purpose
what do the consumers of the test care about?
mike's password?
how we welcome a user?
content on the page?
exact header text?
test consumers don't care about that stuff! plus it's really brittle!
try and automate things with value - insist on a high bar for automation
cucumber helps improve your naming convention
puts you in a mindset where you name things what they are, and you name them consistently.
because you have to match the regex, the naming conventions can be standardized
cucumber makes it harder to cheat
makes it harder to cheat - not as flexible as RSpec, so you have to be deliberate about your changes
changes need to be business related, who should be involved in making this change?s
helps you focus - each rule should only do one thing. are you only testing one action? are you coupling multiple things into this step (extra assumptions?)
selenium security scanner by @gwestr
"perfect" testing pyramid
so, looking at a new functionality/feature, what kind of test design do we need? long term test coverage? at salesforce scale, UI tests get expensive - resources and time
what if we test without the DOM? can we have the devs write javascript tests?
test without DOM, load scripts and specs into javascript, execute them in the context of different browsers. these can be run much, much faster than webdriver UI tests.
example test
"arrange", "act", "assert" pattern. but it's hard, what to do about dependencies?
mock everything except for what you're testing. don't test things nearby, just test specific things
javascript is application code!
new strategy
bottom: JS unit tests, middle: work with headless DOM like Phantom.js, top: webdriver for ensuring consistent experience and browser compatibility
security
we want to find problems with active and passive scans
if you have selenium covering your entire app, you can use it to do security scans
how: send your selenium traffic through a proxy request and make a queue of requests, then with that list you potentially have all your access points/vulnerabilities
XSS (reflected or stored) (in the server or in the DOM), CSRF
obstacles
CSRF tokens expire on replayed requests (which is working as expected, right? :))
failures and flappers can give a bad queue of requests that source your "entire list" of access points
not timely - you basically run your whole thing twice. once to collect, again to scan security
But, despite these things, it's really powerful if we can pull it into the CI loop,
Željko Filipin on How MediaWiki, software that runs Wikipedia, is tested
problem: communication is hard
tough for everyone involved to see what's going on.
solution: cucumber! it's for communication and as a nice side effect it's an automatoin tool
problem: maintanability
solution: page objects
problem: works on my machine
RVM - allows you manage ruby installations. gemsets, bundler
it's a pain getting everything configured on your own. so, use vagrant!
vagrant uses puppet underneath to do all the work
also, jenkins! wahoo.
problem: too many browsers to support!
tough to manage, use saucelabs. it should display in all browsers, but maybe not all the features will work in all browsers.
problem: visiblity
if you have a perfect automation solution but nobody knows about it and no one cares, you're not doing a great job.
try hard to make it visible and open
their jenkins is completely open, failed tests go to saucelabs video
more info at his blog!
Everything is public & transparent, so it's a great resource for examples and problem solutions
questions:
why ruby instead of php: the php bindings sucked big time! also, he was a ruby dev
saucelabs + jenkins integrated for reports?: provider just had a deal with saucelabs, pretty trivial. clone their repo and change some env vars and you can run all the tests on your own computer
how are failing tests connected to saucelabs?: saucelabs uses selenium session id
rspec vs cucumber?: we're trying to solve the communication problem
Testing and moving fast: making Selenium work for Facebook presented by Damien Sereni
move fast and break stuff!
tons of users, tons of committers, but luckily # of commits has scaled well with # of committers.
what do we do at facebook since we don't test in prod?
FB: life of a code change
sandbox -> code review -> trunk -> release branch -> 1 billion users
what's unique at FB is that the engineer is responsible throughout the entire process
engineer is responsible for testing; no one else at FB will test your code
once it makes it into trunk, it's destined for release
automated builds cut every week - only end up with 1.5 days to fix your broken code! aaah!
because there are so many frequent releases it's really important that trunk is good
fabricator: submit a code change -> it gets pushed to a bunch of servers and gets tested;
concerns
speed > completeness - speed is so important, if we can't run all the tests in 10 minutes, we'll just run the most important ones. 10 minutes is guaranteed to be shorter than a manual code review anyway, so automated test results always get back before the code review is complete
signal > coverage - it's important that people trust the tests; flakey tests are the antithesis. if a test starts failing and it's not fixed in 24 hours, it's deleted! "if the failing test wasn't fixed in 24 hours, it must not have been that important anyway!"
use the same language - barriers to tests are bad! make it easy for your devs to write tests
php bindings
Problem: too implicit, API didn't help with common tasks, basically just a thin wrapper around API
Solution: PHP Webdriver Bindings 2, recently open sourced
deep code integration
every element written in php get an testid attribute. it does nothing in production, but for tests, that attribute is used directly as the locator.
<a href={URL} testid={UI::TEST_ID}>whee</a>
mobile?!
mobile site and iphone app look exactly the same. their app was a hybrid WebView around the mobile site - great, we can test it in webdriver! but performance was abysmal. what to do?
mobile first!
design features mobile first, then port it to desktop
all the engineers write mobile code, but they're inexperienced at doing mobile. so how do we test them?
release process: exactly the same process as web, but it's elongated. desktop is 1 week cycle, mobile is a 4 week cycle.
mobile master always has to be good because it gets released frequently!
UI testing for native mobile
releasing a new version is complicated - users have to download it themselves, unlike the web.
testing is complicated - there's more than one app (messenger, fb, fb home)
iOS devs write tests in objectiveC+objectiveC bindings, android devs write their tests in java+javabinding.
all the tests go over JSON wire protocol to re-use existing infrastructure
need (to write? to choose?) translator between JSON wire protocol and iOS.instruments/android.UIAutomator
questions
tell us about your secret sauce?: we don't really have one, we've just started working on it
is 4 weeks a good release cycle?: maybe! we're still working on it
testid attribute in html elements?: a feature of XHP (embed html in php?) define attribute in html element, and only put it on the page if it's a webdriver test! who cares if it comes through as an id or as a class or whatever, as long as it's one constant selector then no one has to mess around with it
talk about infra for iOS, android?: it's not too complicated - instead of starting a browser, you're starting an emulator. s'long as you have something that can start the emulator and talk between the emulator and the bindings/JSON wire, then you're sold
php binding space is fragmented why did you make a new one:(?: we wanted one really close to the java bindings, and adam goucher's was the closest but not close enough.
talk about pieceable?: (https://www.pieceable.com/) - do mobile manual testing, but in the browser? they're working on it, they're close.
do you have anything for windows/BB?: nope! ummmm nope
how do you get 10 min feedback test loop?: lots of parallelism; don't run useless tests; get people focused on writing smaller, focused tests. the tests itself need to be fast, long tests are brittle duh
cross browser?: most tests are FF chrome IE, most run without modifications. some tests are only on platforms. just run more things in parallel :)
