For this Sunday’s weekend testing session, Oliver introduced the group to a web test automation tool called Watir which works with Ruby. I also found out that this session will be a precursor for yet another session for a test automation tool called Cucumber but the next session will be four weeks away though. I’m digressing. Anyways, as a prerequisite (supposedly), we were asked to install ruby and watir onto our workstations following instructions laid out in http://watir.com/installation/#win.
The session started off with Oliver walking us through with some basic commands, then afterwards he let us work on our own on a mission to use watir for posting a forum reply in weekendtesting.com. I had some trouble at first. For one, when I worked with IE7, one of the commands (b.text.include? "<text>") just kept returning false. I’m guessing watir was still looking at the blank tab rather than at the tab where the test web page was launched. I then tried using Firefox instead but I was getting an error message on jssh even though I’ve just installed the plug-in as indicated in the watir installation site. I later realized that I had two versions of Firefox and the command Watir::Browser.new seemed to be opening the older one which didn’t have the plug-in installed. After getting that sorted out, it was pretty much smooth sailing. 
Here’s a summary of commands I used in the session:
require "watir"
Watir::Browser.default = "firefox"
b = Watir::Browser.new
b.goto("http://weekendtesting.com")
# Find text
b.text.include? "Forum"
# Click links
b.link(:text, "Forum").click
b.link(:text, /Next Weekend/).click
# Log in
b.text_field(:id, "user_login").set "<username>"
b.text_field(:id, "user_pass").set "<password>"
b.button(:value, "Log In").click
# Post a reply for the WTANZ07 topic
# Would only work if the topic is still in the list of Ongoing Discussions
# Searching for "WTANZ session #07" didn't work (even thru manual approach)
b.link(:text, "Forum").click
b.link(:text, /WTANZ session.*07/).click
b.link(:text, "Reply").click
b.text_field(:name, "message").set("Test reply yada yada blah blah")
b.button(:value, "Submit").click
# Log out
b.link(:text, /Logout/).click
Right after the session, I found some more links on watir to check out later when I have time. :p
Over the weekend, Pam and I were at the supermarket buying some groceries. When it was our turn to pay at the counter, we were still quite engaged in conversation. When the cashier gave us the total bill, I handed over my credit card to her. In turn, she handed the credit card slip to Pam instead of to me. Pam absentmindedly signed the slip (and I absentmindedly let her; we were still talking :p). The mistake was eventually realized when the cashier handed back the card and our copy of the slip to Pam, and it was actually Pam who pointed it out.
What was odd though was that the cashier actually flipped my card over to see the back side and she did look at Pam’s signature on the slip. She went through the motions but failed to see that the signatures and even the names did not match.
Some lessons learned (yeah, over buying groceries):
- It’s not only inattentional blindness that we should be wary of. Apparently, there’s also attentional blindness wherein we’re looking but we’re not seeing.
- Just because the test steps were performed doesn’t mean the test’s objectives were met. Try to align what you do with your purpose.
- Monotony dulls the senses. Once in a while, it might be a good idea to defocus then refocus. After all, fresh eyes find failure.
One thing I’ve found with these weekend testing sessions is that there’s always something new to learn. Last Sunday’s session was no different as Marlena introduced us to modeling — not the kind with runways or with strutting involved. Here we had a chance to try out modeling a few suggested applications using state diagrams. Our mission for the session was posted over at Marlena’s blog.
I reckon that as testers, we have this mental picture of how we expect our programs under test to behave. I guess preparing test specs is a way to translate this mental picture into something more tangible, and alternatively, capturing the system into a model does the same thing. In modeling, we get to break things down into bite-sized chunks that are less overwhelming as opposed to dealing with the system as a whole. This activity also potentially allows us to capture gaps in our thinking.
With state diagrams, we try to depict the system in terms of states and trans(actions) with more focus on the former. I came to find out that Anne-Marie tends to think more in terms of transactions than of states. I shared that I did so too and gave out an example of a textual (rather than visual) model that I previously used. Unknowingly, as Vivek had pointed out, I had created some sort of state transition table.
Takeaways from this session:
- Gliffy – a new tool! It’s a browser-based tool that uses flash for creating diagrams.
- Somewhat similar to what Anne-Marie said… as someone who also focuses on transactions over states, this exercise challenges our traditional way of thinking. It reminded me of Tim Toady (TIMTOWTDI)
- All the more interested in HWTSAM. I still have a lot of books (and comic books) lined up to read though. [Subtle hint: But if Roy buys me a digital copy, I wouldn't mind
]
- Tim Toady again… aside from taking textual notes, there’s an option to go visual through the use of models.
To a lot of folks, drafting a blog post with the unaided eye might seem like a very mundane task — no biggie, easy as pie! As for me, as I type these words, I cannot read what’s being displayed on screen thanks to my less than perfect vision. I usually wear contact lenses with PWR -4.00 and so without them my face would have to be around a hand span away from the monitor for the text to be readable. Using my browser’s zoom function isn’t really of much help. Even at maximum zoom, at my usual resolution and with the monitor at arms’ length, the text still looks blurred and the site’s layout gets badly compromised.
For some, I guess an option is to use screen readers. And last Sunday, that (and accessibility) was actually the focus of the WTANZ session. For the session, I used a Firefox add-on called Firevox and one of the built-in apps in Windows called Narrator. Our mission was to go to the weekend testing website and log in, with posting a comment reply as a bonus — without looking for most parts.
One downside of Firevox is that its keyboard shortcuts seemed to have been in conflict with my other add-ons. So to enable it, I had to look on screen to find and click the corresponding icon. Once enabled it went on to read text from the website including some stuff which sounded like css properties. It also gets triggered by mouse actions so whenever I move my mouse around, it starts reading the section where the pointer is at. I suppose it does this by design but it was awfully distracting whenever I moved the mouse pointer by accident.
As for Narrator, I wasn’t really able to use it as a screen reader although I think it could function as one. It’s use for me during the exercise was for telling me where the focus was as I shifted between windows or between fields using the keyboard. Sometimes it gets annoying though since it seems to repeat some stuff over and over again.
Some other things:
- I found myself inclined to use the keyboard instead of the mouse. This means shortcut keys and correct tab ordering come in very handy.
- It’s also helpful to have a default focus on first field to be most likely used — e.g., Search text box in Google, Username text box in wordpress.
- The field descriptions proved to be quite useful. — For Narrator, it reads out these descriptions when the focus is on the field. Without these descriptions (as in the case of the post reply form), I couldn’t easily tell when I could actually start entering inputs. Downside though is the Narrator took around 2-3 seconds before it read it out loud.
- Breadcrumbs are not screen reader friendly. Sometimes I just wanted to know which page I was at but the reader would go on to read the entire trail.
- Same thing with some of unnecessary links on top of the page (as pointed out by Oliver). These aren’t screen reader friendly as well.
- An interesting point raised during the discussion was that it would be helpful if there was a b.<whatever.com> version similar to the m.<whatever.com> for mobile sites OR some way to tone down the site content to be more apt for screen readers.
- We thought ALT text would be read by the screen reader. I tried Firevox on xkcd but the ALT text wasn’t read.
I guess what Marlena said during the discussion sums it up best: “This was, ironically, eye-opening.”
