Next Tuesday’s San José Selenium Meetup is promising to be one of the best attended yet! Selenium Framework: Effective Automation Simplified will be presented by Sivakumar Anna, Director of Enterprise Services at InfoStretch. RSVP now!
Remember! If you can’t make it to Adobe’s East Tower Park Conference Room to attend the Meetup in person, you can still watch/listen to it live, via Adobe Connect (guest login). And if you don’t have time for it until the next day or even later, you can still watch/listen to it, via a different Adobe Connect URL, one which I’ll post at the bottom of the Meetup event page after the Meetup has ended.
Better late than never! I just discovered that Pysaunter creator Adam Goucher wrote an almost point-by-point response to my Starting from Scratch with RC, Python, and Pysaunter talk at the 02/28 San José Selenium Meetup.
The entire post by AG is informative, but best of all is that he set up a Saunter Google Group! If you’re interested in either Pysaunter or SaunterPHP, please join the group now so we can start sharing best practices and supporting each other’s test automation work.
Tonight’s San José Selenium Meetup was one of the best Selenium Meetups I’ve ever attended! Speaker Dante Briones, Principal Consultant for Cochiva, gave a talk entitled The Restless Are Getting Native: Lessons Learnt While Automating an iOS App. He started off with a long discussion of automation best practices, which was really interesting, but made me (as the Organizer) squirm in my chair, worrying over whether he was actually going to talk about automating an iOS app! But much to my relief, he soon showed a single-word slide–</digression> (!), and then launched into a very informative and amusing discussion of his experience automating an iOS app using the NativeDriver API.
If you weren’t there tonight, I heartily recommend you catch Dante’s presentation via Adobe Connect. It’s two-talks-in-one and both are superb!
Last night’s San José Selenium Meetup, at which I talked about my experience starting up a Selenium automation effort at Adobe EchoSign, can be viewed via Adobe Connect. Hope you enjoy the talk, and hope even more that you try out Pysaunter! I’d love being part of a Pysaunter Users Google group!
Next week’s San José Selenium Meetup–Selenium @ Adobe–features a couple “short talks,” one of which is by yours truly! Starting from Scratch with RC, Python, and Pysaunter will cover my experience starting up a Selenium automation effort literally “from scratch.” I’m sure you’ve all heard of RC and Python, but perhaps not Pysaunter. Pysaunter–developed by Selenium developer and consultant Adam Goucher–is an open-source framework that supports Selenium/Python test development with either the RC or WebDriver APIs.
Part of my goal in giving a talk about my experience with Pysaunter at next Tuesday’s Meetup is to increase the size of the Pysaunter community so that I’ll have more people with whom to discuss automation issues! To help achieve that goal, I want it to be as painless as possible for people to get started developing with Pysaunter. So here forthwith are installation instructions which I created for my co-workers’ use. (I could cover these in my talk next Tuesday, but that would make for a seriously boring couple of slides!) Obviously, you may not need to do every step, depending on what software is already installed on your system.
- Install Java (at least 1.6).
- Ensure that your path environment variable includes the directory where the java executable is located.
- Download the latest selenium-server-standalone-2.x.jar file from SeleniumHQ.
- Enter java -jar selenium-server-standalone-2.x.jar at the cmdline of either a Mac OS terminal window or a Windows cmd window. This starts up the Selenium server. Minimize the window and use a separate one for the remaining commands below.
- Download/install Python 2.7.2. (Python 3 will not work.)
- Ensure that your path environment variable includes the directory where the python executable (python.exe on Windows, python on Mac) is located.
- Download/install setuptools from PYPI.
- Ensure that your path environment variable includes the directory where the easy_install executable has been installed.
- Enter easy_install -U py.saunter at the cmdline. This installs the pysaunter software. Note, that you can also use this same command to update to the latest version of py.saunter in the future.
- Download py.saunter (in order to get the examples) from GitHub. (Ignore the Sorry, there aren’t any downloads for this repository message!)
- From the download location you’ve chosen, enter cd examples/saucelabs (RC example).
- Open conf/saunter.ini in an editor and go to the [Selenium] heading.
- Modify the server_path line to point to the Selenium server .jar file you just installed.
- Modify the browser line to add the appropriate path for Firefox (chrome) on Mac OS. On Windows, be sure to not surround the pathname with double quotes, even if it contains embedded spaces.
- Run the examples via: pysaunter.py -m deep -v
I hope you can make it to next Tuesday’s San José Selenium Meetup, either in person (please RSVP in that case!) or via our Adobe Connect session. If you’re interested in attending but can’t make the live timeslot, I’ll be posting the URL to the recording afterward, so watch for a new post that evening.
Finally, as I said at the beginning of this post, the Meetup will feature a couple of short talks. My colleague from NOIDA–Ashish Gupta–will present Test Data Extraction & Generation and Performance Analysis Using Selenium. Part of Ashish’s presentation deals with his use of Selenium for a purpose other than automated test cases, which I’ve done in the past and have always found intriguing. So, I’m particularly looking forward to hearing his talk!
WOOT! A San José Selenium Meetup is now a reality!!!
If you read my recent post about last Tuesday’s San Francisco Selenium Meetup, you know I found it very useful, interesting, thought-provoking, etc. What you don’t know is how exhausting I found it to commute from my job in downtown San José to this meetup and back again on a week night. (I live in downtown San José as well as work there). So, I decided to do something constructive about the matter by setting up the San José Selenium Meetup. And I’m hopeful that I’m not the only South Bay Selenium user who would like to attend a Selenium Meetup close to where we live and work.
Many thanks to Ashley Wilson from Sauce Labs for both her informative post on how to start a Selenium Meetup and her assistance in helping me set up this new one. Thanks also to Sauce Labs CEO John Dunham for his words of encouragement at the recent SF Selenium Meetup. And finally, a huge thank you to Selenium creator and Sauce Labs co-founder Jason Huggins for agreeing to be the speaker at the inaugural San José Selenium Meetup!!!
Thanks also to my employer, Adobe, for providing a fabulous venue, and to several co-workers who helped me (in a myriad of ways!) to pull this off.
Selenium Aficionados in the South Bay: Please go to the brand new San José Selenium Meetup site and RSVP to hear Jason Huggins on 01/18/12! While you’re at the site, suggest a program or speaker for a future Meetup! Better still, volunteer to be the speaker or to coordinate the program for a future Meetup!
Selenium Aficionados elsewhere: Consider starting your own Selenium Meetup! Read Ashley’s post on how to do it. Wait for her promised part-2 if you must. But then, go for it!
Tonight’s SF Selenium Meetup was the first “Whiteboard Night” for me. Two of the speakers were especially interesting….
okta’s QA Lead–Denali Lumma–flabbergasted me with the news that okta doesn’t have any manual testers at all! Engineers are required to create appropriate Selenium tests as part of their development of a new feature. While I’d certainly heard before this of developers being heavily invested in the test automation effort, the idea of no manual testing really intrigued me. Too many companies hire QA engineers to do automation but then feel compelled by the realities of aggressive release schedules to push those automation engineers into doing manual testing. This creates a vicious circle–the product continues to grow more rapidly than does the automation suite, leading to the need for still more manual testers to execute regression tests for those new releases.
Ms. Lumma also made clear how well Sauce Labs had served okta’s Selenium efforts, an opinion she recently expounded on in the okta blog, which I read on my train ride home after the Meetup. Her points really resonated with me. Too many companies don’t consider employing providers like Sauce Labs because of (a) the cost; or (b) a smug we-can-do-that-ourselves attitude. This is seriously short-sighted! The time employees spend dealing with automation infrastructure issues and solving Selenium mysteries is not free. It’s far better to have your automation engineers focus on creating customized automated tests for your product, and “out source” as much of the rest of the automation effort as possible to providers like Sauce Labs.
The other whiteboard presentation which I found particularly useful was that of Brian O’Neill, Senior QA Engineer at our Meetup host, Eventbrite. Eventbrite’s approach to Selenium automation is quite similar to what I’m doing–Selenium-RC, Python, page objects, Jenkins, etc. Since I’m the only automation engineer at present in the QA team where I work, I treated Brian like a temporary co-worker, peppering him with specific questions about Eventbrite’s test organization and structure. Occasionally other people attempted to ask questions, but eventually I had most of them scared off!
The Whiteboard Night format requires more effort on the part of an individual attendee than any of the other formats I’ve seen used in the SF Selenium Meetups. One has to quickly ascertain whether an individual presenter’s topic is at all useful, and if not, move on to the next speaker. Once one finds a presentation relevant to one’s own work, one must be assertive about asking the speaker questions, opinions, etc. But if one is willing to put in that extra effort, this format can be just as rewarding as the more traditional speaker/audience formats.
Kudos to Sauce Labs for their continued sponsorship of these SF Selenium Meetups!
After attending the PushToTest-sponsored Selenium: You’re Doing It Wrong webinar in May, I (foolishly, as it turns out!) followed almost all of presenter Adam Goucher’s advice, including the part about not necessarily following all of his advice! Specifically, I continued to put Selenium API calls (such as is_text_present) within the tests of my Python page object framework, albeit only for the assertions, because I thought the assertions should exist in the tests rather than in the page objects. At yesterday’s Create Robust Selenium Tests with Page Objects webinar (also sponsored by PushToTest and also presented by Adam Goucher), I learned that keeping API calls out of the tests does not mean keeping assertions out of the tests, and I learned what could be achieved by maintaining the former. The two biggest “wins” I took away from this super useful webinar are:
- While API calls should not appear in the tests, the assertions themselves should exist there. These assertions should take the form of calls to assertion methods located within the page objects.
- If one adheres to this “no API calls within the tests” strategy, one can theoretically switch test frameworks without having to modify one’s tests! Since I’m still using Selenium-1 but envision transitioning to Selenium-2 within the next year, this point really hit home with me.
The webinar covered a wealth of other useful info for those of us trying to implement our automated tests using the page objects model: the concept of “page portion objects”; an explanation of the “one and only place” a sleep command should appear; a recommended order of attack for developing a test within a PO framework; lots of code samples, etc.
If you’re a Selenium test developer who’s not yet an expert on the PO model, I heartily recommend you check out the screencast of this presentation, which should be available soon on PushToTest’s ScreenCast page. You can also follow PushToTest Founder & CEO Frank Cohen on twitter.com/fcohen; he’ll send out a tweet as soon as the webinar has been published.
Just over a month ago, I started transitioning from script development in Selenium/Perl to script development in Selenium/Python. I was flabbergasted by how much time I spent trying to find documentation on the Selenium/Python API! Finally, I located this very valuable wiki page.
My first response was to copy/paste the output of dir(selenium) into a file, and search in the file whenever I needed a particular type of method. Then (following the instructions on the Wiki page), I’d do a print selenium.method.__doc__ to get the full documentation on the method of interest. But that struck me as pretty cumbersome. I longed for a lengthy page full of method name and accompanying documentation, which I could search and read virtually simultaneously.
Then, while I was puzzling over what new assignment I could issue to my beginning Python students next class, it dawned on me. They could produce my longed-for full-length documentation page!
Here’s the teensy program that generates the Selenium-1/Python API:
from selenium import selenium
for call in dir(selenium):
str = "selenium." + call + ".__doc__"
print call + ":"
And here’s the almost identical program that generates the (unfortunately, also teensy) Selenium-2/Python API:
from selenium import webdriver
for call in dir(webdriver):
str = "webdriver." + call + ".__doc__"
print call + ":"
I can’t believe how long it took before I finally spent the 5 minutes necessary to develop a tool I really needed. SIGH!
In my last post, I reviewed a PushToTest-sponsored webinar I had attended entitled Selenium (You’re Doing It Wrong). One of the slides in that presentation contained the wording: “Page Objects FTW!” I’m generally leery of acronyms containing an “F” so was relieved to learn that “FTW” expands to “For The Win.”
Since I was about to start a new QA job at the time and was particularly disinterested in having to create a framework before I could delve into developing Selenium scripts, I decided to investigate using the Python Page Objects framework published by the Selenium (You’re Doing It Wrong) presenter, Adam Goucher.
It’s been only a few weeks since I was able to download and start using the framework, but so far, I’m seriously impressed. First off, the framework did just what I hoped–it allowed me to focus on developing scripts right off the bat rather than having to first design and implement a framework. Secondly, my scripts are very clean and crisp as a result of following the page object model. All of the locators are in the page object modules. Almost all of the Selenium API calls are there too. Ditto for the various messages that a page can display in response to a user action. Ditto again for the various email subject lines that are generated by user interactions with the page. (My scripts have to retrieve these emails so that they can check and/or interact with them.)
In short, I don’t envision needing to modify a completed test case very often at all going forward! Changes to a page will instead be handled via modifying just the corresponding page object. That “FTW” acronym from the webinar is quite accurate.
And to top things off, PushToTest is sponsoring another free webinar with Adam Goucher on Wednesday, July 27th: Create Robust Selenium Tests with Page Objects. Attendees will get to hear an in-depth discussion of the Page Objects model that was just touched on in the previous webinar. I highly recommend: (a) checking out AG’s framework on github; and (b) signing up for the upcoming PushToTest webinar. And if you fail at the latter, don’t worry–the webinar will undoubtedly be posted on PushToTest’s ScreenCast Central a few days after it happens.
Now if there were just fewer bugs in the Selenium APIs, I’d be totally over the top!