Sahi also offers some ways to access page objects that are just flat out awesome. I’ll discuss a few here, specifically strings, indexes and it’s built-in Browser Accessor API _under.
Suppose you had a story that called for you to click a link from the table above. Simple enough… in Sahi you could write something like this:
1
_click(_link("Deng"));// opens Luol's Wikipedia page
Yup. This code does indeed open Lu’s Wikipedia page as expected. It’s using the link text to access the page’s object (not an xpath). Handy for sure but what if you had other sites to test that contained different data in this same table (hopefully not any Miami Heat Players)? Or maybe these links are commonly deleted by other scripts you’re running? The code above would fail.
No problem. Sahi indexes all page objects which allows you to access the “nth something” on the page. In this example, we could just click the first link. And in case there are other links elsewhere above, we’ll be more specific and make use of one of Sahi’s fantastic relational accessors, _under. So…
Lu’s Wikipedia page again appears! What’s happening here is we’re clicking the first link (indexes are zero-based a thus start with zero) under the table header “Last Name”. Thanks to the indexing of the links, we could also iterate through all of the links via a simple for loop.
But now maybe we’d like to take this up a notch and inject some randomness that will help broaden our testing scope and perhaps improve our chances of finding a bug (the purpose of testing after all). And maybe we’ll also make it a function to help keep our automation more readable. So perhaps something like…
This function uses Sahi’s _count method to count the number of cells that have an id of lastname. (Note: because the results of _count are NOT zero-based (starts with 1) it returns “3″ so we just subtract 1. We then use Sahi’s method _random to get a random number between 0 and $numPlayers (2). Now we call the same code as in our previous example to click one of the player’s links at random, under the table header “Last Name”.
And now any one of my Bulls player’s Wikipedia pages is displayed when running the script! These are just a few of the ways Sahi lets you get at page objects… there’s a bunch more including _leftOf and _rightOf, new to Sahi Pro 4.2.
In the recent uTest blog post, Gerald Weinberg hit an old nerve of mine…
“To me, the biggest weakness [in the way companies test software] is not considering software testing anything but a (barely) necessary evil. Testing is seen as something that could be done by a troop of monkeys, so serious testers are treated like third-class individuals. The lack of means of acquiring testing skills arises from this attitude, as do most of the other poor practices in the testing business. You treat people as if they are stupid, then they will wind up acting stupid.”
This truth is something that I’ve dealt with my entire career… and has been on my mind lately.
I found this video via Slashdot and after watching it, read some of the comments… which hilariously missed the scope of the presentation. I post it here because it reminds me… that if you abolish boxes, there’s no need to think outside of them.
I’m watching a talk by James Bach (who can impressively talk over heavy nose-breathers) in which he claims he has a google alert for blogs with the terms exploratory testing. I am now testing this claim.
The folks at TechSmith make a nice screencasting tool called Jing that I’ve been using for quick tutorials and various documentation. It comes in two flavors, free and pro, but interestingly, I’ve found the free versions limitations to almost be features.
For example, it only records 5 minutes of video. Personally I find that tutorials longer than 5 minutes to be too long anyway. If you’re rambling on for longer than 5 minutes, your listeners are gonna move on.
Which brings me to another limit/feature… you can’t edit the video. I also like this because I want to make quick tutorials… not monkey around with video editing. This forces the issue.
The free version only records video to swf (pro version does mp4) which again, is kinda nice. You can drop the resulting swf onto any modern browser (with flash installed) and the video will play. No additional apps required. It’s also a *snap to embed in a web page (see below). Additionally, it runs on Mac & Windows, has nice stingers and can also do screengrabs with markup.
Now, that said, if you’re looking to build a slick, more professional screencast, Jing will fall short. It’s strengths are agility and functionality… pretty is another apps job.
*Update… okay, so there are some issues playing back swf files on windows :) Here’s a link to the video.
I’ve never been one to dwell on QA-related terminology. I could care less about the differences between mauvebox testing and pucebox testing (I made these up, no need to google ‘em). I could see how such things would be useful in a conversation… but bringing them up can quickly turn that conversation into an argument. No thanks.
Still, the idea of context-driven testing just seems to describe the way I think about testing. If I was to describe it in basketball parlance (and I always do), it might be “take what the defense gives you”. For example, if they back off you and dare you to shoot it, shoot it!.
Or you can read this explanation (boringly devoid of basketball terminology) from James and Cem…
Context-driven testers choose their testing objectives, techniques, and deliverables (including test documentation) by looking first to the details of the specific situation, including the desires of the stakeholders who commissioned the testing. The essence of context-driven testing is project-appropriate application of skill and judgment.
Adjusting your testing to fit the current situation should seem like a no-brainer but it can be hard to stay true to. It’s easy to listen to, if not rely on, the ghosts of projects past. Context-driven testing might require you to get out of your comfort zone, learn new things and adapt to change but this also enforces another popular QAism: that software development is a creative, complex human activity… which it has proven itself to be… to me.
And as Kobe found out the hard way, my Bulls’ defense is almost universally ungiving.
This past year, I switched the default browser on all my machines–Macs and PCs–from Safari, to Google’s Chrome. Ironically, the reason was because of UX (User Experience).
::SPOILER::It was the URL bar.
Like most browsers up to that point, Safari had two forms in the bar; one for entering a URL and one for searching the web. Google melded these two into a single URL/Search bar (reminds me of a single button mouse), thus, when I open a new page, focus is in the bar and I can just start typing a search term or a url. Brilliant!
Safari and Chrome share the same engine, WebKit, so they’re very similar in speed and general abilities, which makes this coup even more impressive. They snuck inovation in to the very top of my browser workflow! Because this is what I end up doing most in a browser, once I got a taste, I was addicted and found myself typing searches into other browser’s url bars. I became annoyed with Safari’s antiquated two-form functionality, and eventually I moved on.
The irony of course, is that Apple has a history of being pretty good at UX… and I’m excited by the idea that more companies are making UX a priority. I wouldn’t say the torch has been passed… but rather, additional torches have been distributed.
I’ve been watching some of the presentation videos from the 2011 Google Test Automation Conference (GTAC) and found this one to be particularly interesting. Entitled “Building a Test Grid for the Cloud”, Simon Stewart talks about writing tests, ensuring test isolation and testing in the cloud (including Amazon’s EC2).
There’s an old joke in Bluegrass music circles that goes “Bluegrass musicians will drive hundreds of miles to jam with people from their home town”. It’s funny ’cause it’s true. While attending a ThoughtWorks workshop this past year, with a faction of my company’s QA team, I discovered this joke can also apply to software testers. Eg. it can take traveling hundreds of miles to get testers from the same company to work together.
At the workshop, it quickly became clear that many of the questions or pain-points expressed by individuals within our group, were at least shared by, and in many cases, could be solved by, other individuals from our group. With that powerful knowledge in hand, I paired up with a coworker to hatch a plan (over cocktails… ’cause we’re from Wisconsin) to leverage this shared knowledge and pain.
The plan was simple enough; set up bi-weekly QA meetings, at which a pair of testers would facilitate the meeting and make a presentation to the rest of the group. Fairly straight ahead but there’s some details to call out…
The meeting will:
Be one hour. Topics must be sized and focussed to fit.
Facilitated by a pair of testers. The idea being each will QA the other’s work, thus solidifying their concept and streamlining the meeting.
Be tool agnostic as possible (unless the a tool itself is being presented).
Include an example(s).
Attempt to ask and answer a question.
Concentrate on topics that affect the entire group. Questions will come up at the meetings themselves that can/should be tabled for a future meeting topic.
The overall premise for the meetings are for the presenters to “show their cards”, as it were. Show examples of what they are actually doing; not what some book says you should be doing. This is essental and it takes a lot of courage to expose yourselves in this way… especially to a room full of QA! I’ve found the fear/pain from such exposure can be lessened substantially by pairing facilitators and allowing them to come to a concusses before presenting. Strength in numbers! This has also proved to keep the conversations at the meetings focused.
We’ve been running these for a couple months now and the response has been extremely positive. I documented one of the topics from a meeting in a previous post… I’ll try to continue to do so.
Sahi is a great automation tool for testing web applications. While Similar to Selenium, Sahi offers many notable advantages over Selenium, including some that were deal breakers in my current situation (IE support for instance). 
In the recent uTest blog post, 
I’ve never been one to dwell on QA-related terminology. I could care less about the differences between mauvebox testing and pucebox testing (I made these up, no need to google ‘em). I could see how such things would be useful in a conversation… but bringing them up can quickly turn that conversation into an argument. No thanks. 
This past year, I switched the default browser on all my machines–Macs and PCs–from Safari, to Google’s Chrome. Ironically, the reason was because of UX (User Experience). 
There’s an old joke in Bluegrass music circles that goes “Bluegrass musicians will drive hundreds of miles to jam with people from their home town”. It’s funny ’cause it’s true. While attending a