VMWare Fusion vs GoToMeeting – who’s in charge?

I keep running into an odd problem with GoToMeeting on my Mac – when I try to open a meeting via URL, it launches a VMWare Fusion session (presumably to try to launch GoToMeeting in Windows) instead of just using the perfectly-functioning GoToMeeting for Macintosh application that exists on my system.

The first place I tried to fix this was from within Fusion. In Fusion’s Settings, I opened Default Applications. and made sure that both Open Mac files… and Open your Windows files… were unchecked. Clicking the Configure button, I also removed all default apps so it is blank. I also tried the Restore Defaults button – be careful with that one if you’ve already done any sort of customization to your Fusion setup.

No dice – no matter what, every time click a GTM hyperlink, Fusion still insisted on opening the Virtual machine.

The solution, I found in a community forum, is a bit more complex and dangerous-looking but it works:

try clearing out the helper applications:
– Make sure Fusion isn’t running
– Get inside the .vmwarevm bundle of the offending virtual machine (see Information Gathering for VMware Fusion on how to find that.)
– Delete the Applications folder there.

This last step may be overkill – it appears that may just need to delete any/all objects in that folder with GoToMeeting in their name.

Though the title of the community post I found this in is “How to PERMANENTLY stop Fusion from opening apps in the VM instead of on my Mac?” – this solution isn’t permanent. Every time you (accidentally) open a GTM hyperlink from within a VM, this “helper application” object gets created, so you’ll probably have to come back and do this on a fairly regular basis.

Atlanta Code Camp 2013

Atlanta Code CampThis past weekend, over 400 developers, testers and others involved in software development got together on the campus of SPSU at the Atlanta Code Camp for a day of training and networking. Code Camps are community events, volunteer-organized and staffed, with sessions presented for free by local (or not-quite-local) individuals. This was my third year to attend, and this year I was also selected as a speaker; I presented a session entitled Keeping Your Sanity With User Interface Automation.

From a quick hand-raise survey, most of the attendees to my session were developers, as was expected, with a handful of testers and one architect. About ten percent of the room indicated that they had tried some form of User Interface automation, with varying levels of success.

We discussed some of the common reasons for frustration, starting with the brittleness of tests – tests that work one day but fail the next – which is often caused by changes in the structure of pages and a too-specific strategy for locating elements. There is no single “silver bullet” answer; we talked about using various forms of XPath, testers and developers working together to come up with a good strategy for Element IDs, and using the CSS selector.

Dynamic content is something we all have come to know and love as users of the web, but throws some wrinkles into automation and testing. I talked about developing tests that wait for the right event rather than sleeping for a speicific time period.

Lastly, we spent some time talking about data setup and cleanup, the need for non-dependent tests, and the use of test runner and/or tool capabilities.

The code and presentation slides I used are available on github, and I welcome feedback from those who attended the session via surveyMonkey and SpeakerRate.

I’d like to thank all the organizers and volunteers for putting on another great event this year. This was a lot of fun, and I hope to see you at next year’s event.

Non-Warning: Smartphone Pictures Pose Privacy Risk

There’s a bit of a scare being circulated this week, mostly via Facebook. Perhaps you’ve seen it:
Warning: Smartphone Pictures Pose Privacy Risk
Warning: Smartphone Pictures Pose Privacy Risk

Now, I’m not saying that people shouldn’t be aware of information that’s captured about themselves and their children, but there are a couple of things you should know about this.

1. According to Facebook’s help pages, downloaded files don’t contain location information. I don’t know if this has always been the case or not; perhaps it wasn’t back when that video was recorded.

2. The video that’s being pointed to is from November, 2010. In Internet time, that’s forever ago. Facebook and other online services change their software often — many services deploy changes multiple times every day (we call that “continuous deployment” and yes, it’s really practiced).

3. I did a quick experiment, the results of which you can see here, and it shows that Facebook’s help page is indeed correct.

test showing exif location info of an original image, the same image uploaded to Twitter, and to Facebook.
A test showing exif location info of an original image, the same image uploaded to Twitter, and to Facebook. Click the image to show full-size.

On the left is the exif information from a photo I just took. You can see the location and other information plainly. I then uploaded the file to Twitter and Facebook, and both services seem to have stripped out the location and some other info before saving them. Other online services may or may not do the same thing. I know of many which explicitly do not.

Facebook does have an option to “add location” to any picture.
Add Location
If you choose to do that, all bets are off.

You can see the photos which do have a location associated with them by going to your profile page and choosing “Places”
Facebook's Places

— — —

In my opinion: As in many cases, the answer’s very simple…

Don't Panic.

More Dave Robicheaux

book cover: Light of the WorldI see that many people have visited this site for a list of James Lee Burke’s novels about Dave Robicheaux, Lousiana detective. He’s written more since I compiled that list, so I just updated it with four additional novels for you. Mr. Burke has written other novels as well, about other characters. I’ve not (yet) tried any of those but they’re likely to be good as well.

The First Three Months

Since starting my new job, I’ve often been asked how I like it and what I’m doing. The short answer is that I’m really enjoying it and that this is the greatest company I’ve ever worked for. I’m busy meeting people, talking and writing about testing, and learning more new things each week than I have in a long time. Here’s a quick list of my output (I’m not even going to try to list everything I’ve learned or all the great people I’ve met):

That’s just the first three months. Exciting times, indeed.

It’s Time to Share What You’ve Learned

Adam Goucher posted this last week on Twitter:
notion; if your 'engineering' team is not doing enough interesting things for 1 blog post a week, you likely have a problem.

I think it’s certainly worth considering – I mean, how’s the old saying go, something about learning something new every day? In our day and age, and especially in the software development arena in which I work, there’s always something new going on, a new challenge to overcome. Dan Pink, author of Drive, talks about our desire for Autonomy, Mastery and Purpose — Mastery is the urge to get better and better at something that matters. I hope you’re not stuck in a position where you’re not learning, where you don’t have an opportunity to improve your skills.

So, assuming that you’re learning something at least once a week, what are you doing with that knowledge? Are you sharing it with your co-workers, with your peers, with others in the industry?

There are plenty of reasons why some people don’t blog publicly. Some ideas are considered proprietary; sharing them outside of your company is frowned upon or may even be a fireable offense. Consider though, are you at least sharing your learning with others inside your company – via an internal Wiki, blog, or newsletter? Does your team get together for lunch and talk about what they’re doing and how they’re doing it? If not, what does this say about the investment you and your company are making?

Once you walk out of the office at the end of the day, your brain (hopefully) doesn’t stop working, and neither does your opportunity to learn and to help others. During my time as a leader in a Boy Scout troop, one of our ongoing philosophies was that we learn best by teaching. When a boy said they didn’t know how to do something, we’d get them some instruction and ask them to be ready to teach a few other boys at the next campout.

So when you’ve just overcome a problem that’s been bugging you for a few hours, learned a new programming pattern, or discovered a new tool that saves you some time, it’s time to teach someone else. Generalize the challenge, so you’re not giving away any of your company’s trade secrets. Start by explaining it to your favorite rubber duck, then get your explanation down on paper – or at least in a text editor. Send it out to a few trusted colleagues, or start a simple blog. You don’t have to advertise it widely if you don’t want – just the act of writing it will solidify the concepts and lead you to learn it more in-depth. This is also a really great confidence-builder: As you keep doing this, you’ll start to realize that you are becoming an expert, that people are looking to you for answers, and that your boss should realize what a valued employee you really are.

Here’s an advanced step. When you’re ready — or even better, before you think you really are — stand up. Give a talk on the subject at your office. Get involved with a tech meetup in your area and offer to present it there. People aren’t looking for perfection; they’re looking for you to share what you know and how you’ve learned it (including the stumbles along the way).

Of course, to circle back to Adam’s point (or what I believe it to have been), perhaps the lack of blogging from your team is pointing to a lack of challenge, a lack of learning. Then yea, “you likely have a problem.”

Agree? Disagree? Add your thoughts to the comments here or join the discussion over on Twitter.

Google Music All Access Radio Stations

Google Music All AccessI’ve been giving Google’s streaming-music, the somewhat awkwardly-named Google Music All Access service, a try ever since the announcement at IO. For the most part I like it, and I’ll likely move to it full-time (especially given the news of an iOS app soon), though I haven’t really figured out the dual nature of it, both having a streaming-music service and wanting me to upload my music library.

I am trying to find the answer to one apparent shortcoming when compared to other services.

When I create a “radio station” on Pandora, I can seed it with as many songs or artists as I’d like.

Pandora Radio Station definition

I haven’t found a way to do this with Google Music All Access – once a station is created based on one artist there doesn’t seem to be a way to add more variety or refinement to the station’s definition.

If you’ve figured out a way to do so, please let me know.

Specification By Example (ATDD at AQAA and ATLScrum)

Note: Andrew presented this workshop a second time last night. As with any presentation or workshop, it has evolved slightly over time. I’m incorporating my additional notes into this post. -Sjv 23-May-2013

Over the past week or so, Andrew Fuqua (@andrewmfuqua) has given workshops on Acceptance Test Driven Development for both the Atlanta Quality Assurance Association — an organization that, I’m embarrassed to say, I didn’t know existed until I heard about it via Twitter (of course) — and the Atlanta Scrum Users Group.

Andrew comes to the topic from his role as an Agile Coach and emphasized communication, communication, communication. ATDD, as we discussed this evening, is all about getting “the three amigos” — Product Owner (a role he asked me to fill for the AQAA workshop), Developers and Testers — together to communicate. The intent is to discuss the details of requirements (often written as User Stories these days) and distill them down into a minimum set of examples in order to provide clarity. Another, perhaps better, term would be Specification By Example.

Here are a few of my scribbled notes from the two evenings:

  • Why do software have bugs? Many reasons, but most often because of miscommunication between humans – especially around requirements.
  • We humans have a tendency to assume ill intent (why is this?) where often misunderstanding is more likely the cause.
  • A feature or product request often starts with some sort of concrete example, which gets thrown away as more general requirements documents are written. Let’s get back to examples as part of the requirements
  • Business rules are more likely to be stable than user interfaces. Therefore examples should be in business language.
  • Cognitive dissonance (discussion between people with different viewpoints, different skill sets, different ways of thinking) can facilitate exploration and improve understanding. Involve product owner, developer, tester, business analyst, customer if possible.
  • Don’t get lost in the details.
  • We all have too many meetings. Don’t create another one for this discussion/distillation activity. Hold a specification workshop instead.
  • Discuss, Distill, Develop, Demo (explore). Lather, rinse, repeat.
  • Distill the list of examples down to the bare minimum, a minimal set of both “passing” and “failing” examples. One example per business rule.
  • There is value in the discussion and distillation even if the examples are never codified into automated testing. Communication is the goal.
  • ATDD != TDD. TDD guides design of code. ATDD guides clarification of requirements.
  • ATDD is done before — and throughout — coding/testing.
  • Best captured in some sort of living document (no specific tool recommended, but a wiki was mentioned)
  • The results should be owned by the product owner, not developers or testers.
  • It’s not about testing, it’s about communication.
  • “Don’t invest in something that nobody gets value from.” – Claire
  • “Design a level of testing that is commensurate with risk tolerance. Don’t dabble in automation. Do it well to keep it – or toss it.” – Sellers
  • Understand Brian Marick‘s Agile Testing Quadrant model. (see this and this) – Alex

And some of the resources Andrew mentioned:

The discussions did also touch on the topic of test automation. Again, no specific tools or technologies were covered or recommended, but a couple of good points were raised. I was especially pleased to see many heads nodding in agreement when Andrew said that “test automation is software development, and should be treated as such.”

This was a good workshop, and I’d like to thank Andrew for his time (and for letting me help where I could be of assistance).

Book Recommendations by a Dozen

I was fortunate to spend two days last week with some very smart people as my company hosted a completely non-company-specific, non-tool-specific, non-technology-speicfic peer conference; twelve people in a room discussing the craft and profession of software testing, what changes we see happening and would like to see, and how we might be able to influence them.

On day two the question was raised: “what are you reading or do you recommend?” The following is the list that was produced. This is completely non-edited, everyone was welcome to post their recommendations and talk a bit about them. I am not endorsing all of these; many I’ve not read and a few I’d not even heard of before. Heck, there wasn’t agreement among all the participants on every book, some resulted in quite a discussion.

Note to the participants – I went from our hand-written notes on the wall; if I’ve mis-read something or found the wrong book, please let me know and I’ll update this.

disclosure: all these links are tagged with my Amazon Affiliate code — if you purchase through these links I’ll get a small percentage (which will undoubtedly go toward more book purchases), and I’ll be able to see what books were purchased (but not by whom; Amazon respects your privacy at least that much).


Why not sleep?

In my last post, about test automation, I wrote about using sleep : “Bad, bad, bad. Don’t do this.” But why not? Well, the way I was doing it there — until d.exists? — really wasn’t that horrible. What you really want to stay away from, and what I’ve seen people start out with, is sleep with a hard-coded time value. “But I know the app’s going to take a few seconds to be ready,” they say, “so I just put in a 5-second delay.”

Let’s look at — in human terms — what we’re talking about. Imagine for a moment that your extremely strict boss wants to know what colour taxi he’ll be taking to the airport, and sends you outside to look.
Yellow Cab
He knows the car’s due to arrive in the next five minutes, so his instruction is a simple one: “Go outside and wait five minutes with your eyes closed. At the end of that time, open your eyes. Look at the car at the curb and come tell me what colour it is.”

Can you see any problems with that task? I see two right away. First, it’s potentially a waste of your time and his. What are you to do if the taxi arrives before the five-minute mark? Nothing. He expressly told you to wait five minutes, then look at the car. If the driver’s having a good day and shows up early, too bad. You wait uselessly at the curb; he waits impatiently for an answer that you could have delivered earlier.

Secondly, he gave you no instructions on what to do if traffic is bad and the taxi isn’t there on time. You’ll have to go back and deliver a non-answer. Next time, he may decide that five minutes wasn’t enough, so he’ll try giving you a ten-minute wait time.

This is decidedly non-optimal.

“But wait,” you say to your manager, “Why don’t I just wait until I see a taxi, then come and let you know.” That is what you’d say, right? Of course it is. That’s exactly what we want our computers to say, too.

That’s the purpose of until. Give the computer a specific condition, and the flexibility to wait just long enough until that condition becomes true. In my previous Ruby/Watir example, we waited until an element existed, or until one contained a particular text string. Other language/testing frameworks have similar syntax. Using WebDriver, for example, you’d use wait.Until()

Until our computers get a bit more intelligent and understand what we mean rather than what we say (and given the potential state of computer intelligence maybe that’s not a good idea), we need to be explicit in our instructions while making those instructions flexible enough to work well in the real world.