Archive | Rants RSS feed for this section

Uninstall old SafariDriver on recent versions of Safari

15 Mar

Aside from not needing SafariDriver starting in Safari 10 (or was it 9? I forget) and requiring recent versions of Selenium with older versions of Selenium paired with older Safari using SafariDriver, if you’re like me and haven’t used Selenium/SafariDriver in a while, you might have left the browser with SafariDriver extension.

If you update Mac OS X and Safari, you may still have the extension installed unless you specifically uninstall it.

One interesting quirk about having it installed is that it can now cause problems on certain websites (likely from same core issue from something in the extension’s codebase):

TypeError: Value is not a sequence

This came up for the websites from my company as well as Apple’s iCloud.com.

Once I uninstalled the extension, everything was fine.

Advertisements

Awesome Stuff – Selenium, RobotFramework, test automation, etc.

24 Feb

A while back I came across the “awesome” series of listings of (good?) resources for a given category (awesome go/java/ruby/python/etc.).

Well, it’s nice that it has expanded to other areas beyond programming languages, and per se to my original blog content, some areas I and my readers are interested in that I thought to share (if you haven’t already come across them):

I’m contributing to these as I can. And we all should, but at the same time, in keeping with the motto “awesome”, entries in the list should have good reason to be there, not just “yet another related thing to put on the list”, should be something special, otherwise, it will end up a bloated list of (spam-y) stuff.

On filing bugs to Apple

26 Aug

Unlike other public bug tracking systems, Apple’s one is closed to public viewing other than Apple and the reporter of the bug.

So bugs you report, others can’t see the status of. And as such, there can be likelihood of duplicate bugs being filed, etc. I assume Apple has good reasons to overlook potential duplicate bugs in favor of this closed access bug tracking system.

Amusingly, a public repository of Apple bugs is available at OpenRadar. It’s useful for the public community to look for existing bugs filed to Apple before filing their own, and check status of said bugs. There is one caveat though, OpenRadar does not pull data from Apple’s system. Therefore to get data into OpenRadar, one must file a “duplicate” bug to it for whatever one files to Apple.

As such, I would recommend those of us who deal with Apple bugs to:

  1. Check OpenRadar first before filing bug to Apple. If one exists on OpenRadar, just subscribe to and monitor that. Although one is free to file a duplicate to Apple just in case.
  2. If one doesn’t exist on OpenRadar, then file bug to Apple. And if the bug is not specific to your internal case (confidential/security/proprietary info, intellectual property, etc.), post a duplicate filing on OpenRadar. This allows the public to see the bug you filed. Also makes it easier for team members to view the bug for those teams that don’t use a shared/team Apple developer account or whose said accounts aren’t all under the same organization access.

What the f**k to test?

23 Feb

Was reading my emails and some blog posts today and came across these:

http://lifehacker.com/5911385/seven-helpful-sites-that-tell-you-what-the-fk-to-do

https://github.com/soulwire/WTFEngine

it made me think, as a tester, it would be interesting to have/see a site about “What the f**k to test” or something similar. It could be useful to the entry level and novice testers just getting into testing profession. And it could be useful to all of us testers when we happen to feel lazy or have “tester’s block” not being able to test or decide how/what to test.

Or do we actually have something like that already? If so, let me know.

If not, anyone interested in helping build such a site/service? It would be a site that randomly decides to give you the tester a tip on what to test for your site/application/system (in general terms that are not specific to your site/application/system).

Chrome version upgrade can break Chrome extensions?

28 Jan

This is a short blog post today:

Who would have thought this, but some recent Chrome version upgrade can break the UI of your Chrome extension (by changing extension popup window size and font sizes). I only found out after reading a user review.

For reference to the particular issue: https://code.google.com/p/autosmsclients/issues/detail?id=3

and now I have to find time to go debug and fix this, just because Chrome decided it wanted to change things on how a Chrome toolbar UI renders, and without notifying it’s extension developers about this…sigh…

WebDriver API and JSONWireProtocol is not just for web and mobile applications testing, it can be for desktop too!

19 Jan

And so, here’s a blog post about just that. I’ve found that the WebDriver API in general, with regards to common location strategies of ID, name, class, tag, and kind of XPath, along with element manipulations–such as click, type/sendKeys, get/set text, get attributes, mouse operations, key up/down, taking screenshots, finding elements & validating properties (enabled, visible, selected)–all that being common across web, mobile, and desktop.

Selenium/WebDriver started off for web applications. Then came along Appium, ios-driver, etc. which expanded it to the mobile space, first iOS then Android, and now somewhat even Windows Phone.

But there has been very little in the desktop area. The first for it was Appium for Mac. And we’ve seen nothing else since. Though if you consider unofficial Selenium/WebDriver-like APIs, then maybe there’sa few more: Twin and sikuli-remote-control. But now, I’ve worked out some proof of concept prototypes (based off the old Appium Python implementation) to give you more options to desktop automation using WebDriver API and for Windows, not Mac!

https://github.com/daluu/AutoItDriverServer
https://github.com/daluu/AutoPyDriverServer

Check them out. Pretty interesting. The AutoIt one has a Selenium integration demo showing automation of AutoIt and Selenium together against websites using 2 drivers – a “web” driver and an AutoIt driver. They’re not Selenium Grid compatible yet, something to look into for the future. But at least they work for remote deployment. Though there is a way to make it work unofficially with Selenium Grid deployment of Selenium tests (but where these desktop UI servers are just not officially part of Grid as nodes) – this solution will be presented in a future blog post.

And last, I had wanted to complete with a three’s company big bang, but I couldn’t get Sikuli working just yet, maybe in the future…

https://github.com/daluu/SikuliDriverServer

So try them out, submit feedback, send pull requests with enhancements and bug fixes, etc.! 😉

P.S. all this made possible by the great work of others. Like the Appium team for the server base I used. And if/when I work on the Java server version – the Selenium team or ios-driver team, and .NET server version – Jim Evans for his Strontium server implementation. As well as the work of those who build great free or open source tools like AutoIt, Sikuli, AutoPy.

Update 6/5/2015: since my post, I found a new solution that’s better and more recent than Twin for desktop Selenium-style UI automation – Winium.

Organizing tests by repetition or granularity?

24 Sep

I’ve seen this often in my job covering test scenarios manually as well as adapting those tests for automation. Have others come across same issue?

In terms of manual, and more correctly, exploratory testing, as a human tester, you can choose how you perform your tests and it is often logical to consolidate areas of testing (or in documentation parlance, “test cases”) around things that would otherwise be repetitive. e.g. re-using same test data to test slightly varying scenarios. Where workflow or sequence of test steps are common across several tests, you may as well run them sort of together like multitasking rather than separately one after another, repeating the common steps all over again.

One example is testing a workflow that happens to be mostly same across desktop, tablet, mobile. Only UX or UI is different. Do the test 3x? Or run test nearly 1x by testing all 3 at same time where/when possible using one test/path to do most of the workflow and verifying across all 3 paths at the critical points.

But that’s easy to do for exploratory (and undocumented manual) testing. But what do you do when it comes time to put this on pen & paper for others like an offshore team to execute said tests, who are one or more connections/layers away from the intimacy of the feature being test than you are? And then converting such documented tests to automation.

Do we strive to follow the human (exploratory test) nature/convention of consolidating the test coverage around the repetitive workflow and shareable test data minimizing amount of test cases and test scripts to create OR strive to keep granular individual specific tests for tracking/auditing purposes and simplify or attempt to idiot proof things, even though it will be in ways redundant in repeating test steps and generating more repeated tests data that could have been shared/reused otherwise?

One argument could be to do it granular since automation and/or hardware is cheap. But it turns out unless your site is 1990s basic HTML, repeating test steps can still be slow against modern websites/applications against modern browsers. And running tests in parallel helps with this but adds complexity and still can take long time once your test codebase grows big. So in some cases, maybe consolidating testing isn’t necessarily bad, you have to weight the pros & cons with short & long term automation coverage/infrastructure in mind.

Just wondering what experiences and approaches folks have taken in the real world.

Perform

“Incinerate Ignorance”

Anastasia Writes

politics, engineering, parenting, relevant things over coffee.

One Software Tester

Trying To Make Sense Of The World, One Test At A Time

the morning paper

an interesting/influential/important paper from the world of CS every weekday morning, as selected by Adrian Colyer

RoboSim (Robot Simulator)

Visualize and Simulate the Robotics concepts such as Localization, Path Planning, P.I.D Controller

ÜberDev

open notebook

a happy knockout mouse.

my journey into computer science

Perl 6 Advent Calendar

Something cool about Perl 6 every day

technolinchpin

Inspire and spread the power of collaboration

Niraj Bhatt - Architect's Blog

Ruminations on .NET, Architecture & Design

Pete Zybrick

Bell Labs to Big Data

Seek Nuance

Python, technology, Seattle, careers, life, et cetera...

TELLURIUM

New Era of Test Automation

Der Flounder

Seldom updated, occasionally insightful.

The 4T - Trail, Tram, Trolley, Train

Exploring Portland with the 4T

Midnight Musings

Thoughts on making art

Automation Guide

The More You Learn The More You Play...!

The Performance Engineer

Code.Test.Tune.Optimize.