QA Craftsmanship, Unite - Live From Pay Pal, it's yet another Meetup!!!

Live from San Jose, it's... me :).

This time, I'm excited to say that there's a new group that's formed in the Bay Area called "QA Craftsmanship". It's meant to be a corollary to the Software Craftsmanship movement, and it's looking to be a way to bridge the gaps between the programming and testing realms. That's the theory, in any event. Whatever it's called, I'm happy to see dedicated testers who are looking at ways to up their game, and the fact they are doing it here in the Bay Area, double bonus!

This one came quickly together, as I got the invitation on Saturday to join the group, so here's a quick run-down on what we are talking about tonight:

The Althea Studies Platform is a smartphone and web based SaaS platform for creating longitudinal healthcare studies, i.e. studies that collect data over a period of time. Study administrators can define studies on Althea's web site and deploy the studies as native applications on the iPhone and Android and also on the web for use by study participants.

Learn how automated testing gets down with AltheaHealth's mobile tracker (Android/iOS) using cucumber & calabash

Truth be told, I've had much more experience with desktop and traditional web apps than with mobile, and Calabash is totally new territory for me, so I'm curious to see where this talk goes.

Melvyn is starting out with a quick intro to Cucumber, and explaining how the gherkin interacts with the step definitions as defined in selenium, capybara, etc.

Melvyn likes to use some basic rules when it comes to writing tests. One example he points out is "If I can click it, it must be there", so put into a more direct focus, don't code specifically to items on the screen, code based on what you want to do. Defining things by their actual structure (buttons, links, etc) means that if those elements change or are removed, feature files will need to be modified. I like this approach, and think it could save a lot of editing in the future.

At this point, Mishal Shah picked up the talk and carried the discussion forward. Using Jenkins, we can use a variety of plug-ins, and in this presentation, the Android Emulator can be set up as one of those plug-ins. You can also plug in you actual phones into the Jenkins server if it's available, or via port forwarding, you can remotely connect your actual Android device into the Jenkins server (ok, that's a trip, I've gotta' try that out :) ).

Calabash-android basically lets you run Cucumber features on an Android device or emulator. It is controlled from your command line, and as you run your tests, you can see in real time the steps run on the Android emulator. The Feature files and test steps work just like we would expect Cucumber to do on our desktops. 

Again, just as with their web counterparts, remember to make a distinction between creating step definitions that drive behavior vs. driving interactions with elements. All of the options hat we are familiar with when it comes to Cucumber, i.e creating hook files, making macro commands, and other options that we either love or hate about Cucumber and it's underlying structure, Calabash does very much the same thing.

One interesting thing with calabash is that they are using Frank, which allows users to look and see the element IDs and such. Frank will let the user get every element id currently loaded. Key takeaway and urging at this point; don't look for text, look for element ID's (it will also save me from having to go and change tests if the text is changed later).


query, touch and a variety of other commands will allow the user to directly interact with the elements and be able to enter text, select items, etc. This talk is also looking to be developed out to be a hands on workshop in the next few weeks. Hoping I can be there, but if not, I plan to spend some more time in the calabash-android github repository.

One other interesting tidbit (this may be common knowledge to many others, but hey I'm new here) is that calabash has a very limited scope as to what the framework will interact with. It's limited to the apk file and what it will generate. You can't jump over to another app, it's out of scope. That's a security measure, so that you can't hijack other applications. I find that interesting.

Oh, and while I'm on the topic of "interesting", I took some time tonight to give out some "Ministry of Testing" stickers, and for those curious, though I doubt it's the first one in the USA, I think this may well be the first one out in the wild in the Bay area other than me ;):

Thanks for joining me tonight, I hope this was interesting (I certainly found it to be :) ).