As the kid who ALWAYS failed the lessons in “Following Directions” it is not without some trepidation that I decided to take Weekend Testing Australia/New Zealand in the direction of critical thinking. What do you think critical thinking is? Problem solving? Following directions? Structure? Precision? How many times have you heard critical thinking mentioned as important for testing? Uh-huh, yeah, that’s great…me too. Now, what is it?
No, really…what IS IT?
Before last week, I had forgotten so I spent this week reading about it. I needed some review. (It’s ALWAYS ok to admit we need review.) So that’s what I did. This included taking a quiz about my skills to find out where I’m lacking. For me, critical thinking is using a particular set of skills to analyze a problem or some information. It involves the following skills
Categorizing
Following a sequence
Comparison
Following Directions (Pffffffftttt!!!!)
Close Reading
I did ok on all of it including “Following Directions” but I did not do as well on “Close Reading.” Between that and tester friend Chris McMahon’s suggestion that I mine this blog post of his for some ideas, I decided to base our session on “close reading.”
The first was to take a set of 3 bugs marked as duplicates and compare/contrast them picking out the one we considered to have the most effective information and noticing which information some noticed but others didn’t.
The second activity was looking at issues with stack traces to try and figure out more detail from the stack and information in the issue what had gone wrong.
if you’d like try some close reading on your own, find an issue and read through it. Then, put it away and come back to it after 30 minutes or so. What did you notice the 2nd time that you didn’t the first? if you do this multiple times, is there a pattern? Perhaps there’s a certain type of information you don’t digest as readily or an area of the page that is less likely to catch your eye.
I think we’re going to continue this thread on critical thinking for our next WTANZ as well. That will take place on January 23, after the holidays.
For those who saw my tweets about involving HTML5 in this, I veered away from that because I was not having great success in putting an activity together. I will blog that separately because I think those of us testing HTML5 features will have to reconsider how we approach the web. Stay tuned…
Update: I logged this issue yesterday based on one of the bugs we discussed in our session. The original problem was fixed, but I found another place to get the stack trace, so I logged it.
Sometimes peer pressure is a good thing. Today I got an unexpected tweet from Daniel Woodward a.k.a @woodybrood asking about a FedEx project where I visualize JIRA issues. I’ve now done 2 FedExes. In my first one, I collaborated with Anna Dominguez to create a network graph based on comments in JIRA and Confluence. It was a map of who was commenting on whose issues and pages. I wrote a blog post about that one here.
My second FedEx was an attempt at visualizing code churn as a horizon graph using data from Atlassian’s source code analysis tool, Fisheye. It turned out to be one of my more unsuccessful attempts at visualizing. I couldn’t get code churn data that really meant anything and I realized that code churn should not be visualized as a horizon graph when I started putting the graphic together. (That was painful.)
So, Daniel, the short answer to your question of whether I have a great way to visualize defects in JIRA is: not really. I have put JIRA issues into a treemap before, but I wouldn’t recommend that either.
Where does that leave things?
It leaves me feeling a little frustrated but still curious. I refuse to believe that the data from bugs is not to be visualized. My gut tells me that I just haven’t found the right questions to ask or the right style to use for visualization. I do have one more trick up my sleeve before I’m completely out of ideas. Here are the pieces:
I have, in the past, visualized counts of fake defects with the parallel coordinate plot software, ParallelSets. I already hear screams about visualizing bug counts so at least let me explain before you flame me. When I did this, I was very happy with the results. However, the version of the software I was using was not robust enough for me to use it on a regular basis. It’s been updated to be more robust with data, but the newer version has the side effect of not showing the data points individually, plus it only works on windows and I’m more into mac. When it was working for me, I really loved it. They really nailed the interaction between the user and the data. It really pains me to say it, but I’ve moved away from using parallel sets for now.
What I noticed a while ago is that the visualization language protovis has an example of parallel coordinate plots. I encourage everyone who is interested in visualization to play with protovis. It’s from a group at Stanford and uses javascript. I’ve followed the first tutorial for protovis published by Dr. Robert Kosara, and it’s pretty cool.
So I’ve got my visualization idea. How do we get it out of JIRA? In the past I’ve gotten information about JIRA defects into a spreadsheet and maybe also csv. One of the reasons I liked Atlassian so much before they hired me was that data exports pretty cleanly from JIRA. There is no way to overstate how much easier that makes visualization. Unfortunately, once I got the data out, it did not work in a treemap. Even though getting the data out through the UI is not that bad, I’d like to try something I’ve done some fiddling around with in the past year: REST.
JIRA has just released 4.2 which contains a new version of their REST api, and I love the documentation they have for it. It makes working with the api extremely accessible, much like the docs on twitter’s api. They’ve got curl examples and a script you can use to make a graph of links. They also have a page for simple REST examples which is not completely filled in.
Here’s what I’m gonna do:
Use the new JIRA REST api to create a data set in Ruby to be used for creating a parallel coordinate plot of JIRA issues. If I’m lucky, I’ll get 20% time to do this. I know some guys who, I’m guessing, wil help me get the example in ProtoVis to work with the JIRA data. I bet I can have something together by next month. The goal would be to provide a ruby example for the page on “The Simplest Possible JIRA REST examples” along with some javascript that shows the data in a parallel coordinate plot using protovis.
Readers are officially allowed to hassle me about finishing this before Christmas 2010 on twitter and in the comments here.
Today I participated in a webinar with Alan Page to learn about testers doing code reviews. Since Atlassian makes the awesome Crucible code review tool (which has a $10 starter license), we’ve got code reviews all over the place. Part of my check-in process for automated tests is to have them code reviewed. I’ve never, however, considered doing code reviews for the devs. Thus, I tuned in to see how it had worked for Alan and his team. These are some notes that I made. Update:Here is a recording of the webinar.
When testers look at code review, helps them ask, “In what ways may this code fail?”
The “official” type of code review is the Fagin inspection: prep for the meeting, moderator and reviewers go through the code line by line. It’s very slow, boring and massively successful. Trade off is that they work extremely well but take a very long time. (so guess that would be good for mission critical 911/medical type stuff)
Alan’s approach was less formal. Have a kickoff meeting ask for volunteers. Expectation is that code review happens everyday. As with guitar practice, 15 minutes a day is better than 2 hours done 1 day a week. His star group was able to review 500 lines of code per week.
Checklists play a major role in the review: “I wouldn’t do a code review without one.”
The Invisible Gorilla. A book about how the brain works. The authors are responsible for this youTube video which teaches about the effects of inattentional blindness (if looking for one thing, you’ll miss another)
Checklists should be modified over time. Stuff that becomes less relevant should be removed.
It’s better to use a checklist of types of errors and go through looking for a specific type of errors such as off-by-one, assignment errors rather than reading sequentially through code. (or to have a checklist based on usage patterns.)
Alan thinks most of his checklists have 8 or 9 items which makes a lot of sense. In psychology, I’ve heard about humans being able to remember +/- 7 items at a time.
What will you find:
Code that has lots of bugs probably has more bugs
Bugs likely to be found wherever there is churn
Greater complexity between 20 diff complexity metrics indicates bugs and can guide where to start review.
So what happened:
They found bugs
They learned much more about product code
They found areas where tests needed to be written
Stuff they found:
Instead of using a code review tool, they used word. Lots of the comments were, “should we be doing it this way?” Should this
Devs get sensitive about code. It’s important to remember, code reviews are about the code…not the person. One way to alleviate this is to refer to all problems with we. “This is our problem. This is something we should fix.” The dialog improved relationship between devs and test. Big wins were intangibles: understanding code, developing better relationship with dev. Also was good for teaching non-coding testers similar to the way it’s easier to read a language than to write it.
One challenge was to find a way to keep comments and code in synch.
Inspection SWAT: Get the good reviewers together, find a risky part of the code and go at it for an hour or so.
Code Review of a Test
I asked about doing code review for tests, since this is what I’ve been doing lately. Alan suggested that I use a different code review checklist for automated tests with a few suggestions:
Are there hardcoded paths?
Will the test fail if app taken away?
consistency & reliability – what causes it to vary from run to run
What happens when the test fails, is the information useful?
The review should include a copy of log file that test produces a
key bit of collateral from automated test is results and log file
What would be mean time to diagnosis in case of failure.
I also asked how much of the production code the testers knew before they started doing code reviews. Alan said that his team knew bits and pieces, but did not have a very thorough understanding. Doing the code reviews changed this.
The main benefits:
Testers learned much more about the production code
The relationship between testers and devs improved
They found bugs
Alan also thinks that code reviews are a good way to show developers new to the project what’s been going on with the code.
One of Alan’s stand-out concluding remarks was, “I couldn’t not do them now.”
Tonight, (tonight as in Sydney time…it’ll be morning in the U.S.) I will be interviewing Matt Heusser for the “This Week in Software Testing” podcast. If you would like for me to ask him a question, leave a comment :)
Although my life has changed significantly since my husband, Chris, and I moved to Australia, his life has gone through just as many changes. In our previous life, Chris was a Captain for Dekalb County Fire & Rescue in Atlanta. Long ago, when I would tell people this, a fair number of people would say, “that must mean he’s a great cook!” To which I would reply, “uh…not so much.”
Chris grew up in Brevard, North Carolina. It’s a small town located high in the Appalachian mountains of the Eastern United States. I’ve had great cooking in Brevard, however, it’s usually tamer dishes such as trout at the Fish Camp or a Burger at the local Sonic. As a child and as a grownup, my husband’s favorite meal has consistently been pork chops with kraft macaroni and cheese. I made him a macaroni and cheese from scratch once. I say once, because he didn’t like it. About his eating habits, he is fond of saying, “I like my food bland and my women hot.” (and that’s as far as we’re going with that.)
At a random BBQ joint near Brevard, NC
Eating is one area in which we are polar opposites. I’ll try just about anything. I come from a family that owned and operated a restaurant in Atlanta for over 50 years (which voluntarily integrated in the 60’s) so I had escargot and alligator sausage lovingly placed in front of me at a very young age. Indian food…love it! Ethiopian food…love it! Laksa…it makes me cry and I love it!
Because I have an interest in travel and food, I used to enjoy watching the Anthony Bourdain show, No Reservations, on the Travel Channel in the US. His show is fun because his focus is not on stuffy, expensive restaurants (although some do appear on the show) but rather on street food. He loves trying regular lunchtime dishes wherever he goes. Since he goes to some pretty exotic places, the idea of street food or a regular lunchtime meal varies radically. Although I was the one who started watching these shows, they struck a chord with Chris who started watching the show with me.
Since there is no Travel Channel in Australia, we’ve had a bit of Anthony Bourdain withdrawal. We’ve mentioned it to each other a couple of times, but I thought that was as far as this would go…until I booked our plane tickets for our trip to Singapore and Kuala Lumpur, Malaysia over Sydney’s labor day weekend.
Before the trip, Chris started talking about Anthony Bourdain and how Anthony had traveled to Singapore and Malaysia. Chris’s interest reached new heights on our trip. Both of us read Anthony’s first book, “Kitchen Confidential,” and we visited a couple of the places highlighted in the No Reservations shows. Somehow, being in these places allowed Chris to mentally step into Anthony Bourdain’s shoes which must have opened up some doors in Chris’s mind. Once we touched down in Singapore, I began to notice a dramatic change in Chris’s attitude towards food. It also helped that Singapore’s national dish is the basic and delicious, chicken-rice.
This man is about to try steamed fish head
Once we were in Kuala Lumpur, Chris started trying any food I asked him to try. This included: soy milk with jello (Aussies know this as jelly), steamed fish head, extra spicy laksa and some green and blue beverage the name of which I still don’t know even though it was quite tasty. Not only did he try all this stuff…he did it with glee! When we had dinner on the street in Kuala Lumpur, Chris ordered a barbecued chicken dish. It was very spicy and he ate most of it. I know that it’s easy to throw away inhibitions on vacation so I wasn’t expecting this zeal for trying different stuff to make it back with us to Sydney.
Boy, was I wrong. We had lunch together on Friday and Chris mentioned that he had a surprise for dinner the next day. I didn’t ask what it was since I sometimes like surprises. When I came home that evening, he announced that we would be having Kangaroo for dinner the next day. For the first time in quite a while, I suddenly found myself out of my own comfort zone! Of course, I started twittering.
and, of course, my friends tweeted back:
This resulted in my husband deciding to marinate the steaks in teriyaki and pan sear them. After much bickering over pan temperature, how much oil, how long to cook each side, etc. we sat down to eat. Here’s a suggestion: if you pan sear any type of meat that’s red in the middle, don’t serve it with a bowl of white rice.
Pan Seared Kangaroo with green beans, tomatos and rice
Chris was unable to decide exactly how he felt about his dinner, but he did eat most of the kangaroo. We’re planning on cooking this again and having it as a dinner salad instead. So what’s Chris’s verdict? “It wasn’t bad, but it was kinda chewy.”
I’m excited for my husband that he’s been able to embrace the place where we live and the places we’re traveling to the way that he has. He’s even managed to turn the tables on me and get me out of my own comfort zone. In the recently released movie, “The Kids Are All Right,” Julianne Moore’s character describes long term relationships as, “slogging through the shit, ” which I find to be a fairly accurate description. What makes a long-term relationship worthwhile is when you have somehow managed to stick together long enough to see each other through positive changes such as the one Chris has experienced. I’m not expecting him to ask me if I want to go for Ethiopian any time soon, but I’ll gladly let him cook me a kangaroo steak any day.
My plans were grand. I was going to run a Weekend Testing session to show people how to use a wiki to manage their tests. I would be educating people about testing with wikis and advertising for WT at the same time! FTW^2!!
Well folks, CAST doesn’t really work that way. At CAST, a third of every session is reserved for a facilitated discussion. When I say facilitated, I mean that there is a system for asking questions and maintaining a discussion thread or killing it if the discussion is not constructive. I’ll be honest: I did not know that there was extra time for questions or that the entire session would be facilitated in a certain way. Once I attended the conference opener, I realized that my Grand Plan did not belong in Grand Rapids and started to feel as though I might be, very much, in over my head.
What you didn’t know about my wiki talk: It’s been extremely challenging to put together. I think I’ve figured out why. Wikis are about using pages, links and writing to set down thought patterns visible to others and to allow alteration by others for collaboration. It’s hard to de-couple showing the way my thought process works, from the actual nuts and bolts of putting wiki pages together for software testing to show to others. The way that I manage tests through a wiki will not be the same way Chris McMahon or Matt Heusser manages tests through the wiki. At the same time, the fact that we would all do this differently is the point of using a wiki in the first place. Using a wiki, the three of us could do testing on the same project in different ways or collaborate on some of the same testing, using a wiki to communicate what we’ve done. Although I will only show one way to organize tests in a wiki, you can do testing in plenty of other ways on the same project and link them all together.
Sanity Testing
We do bi-weekly milestone releases for Confluence. Whenever we have one of these releases, we do a set of sanity tests just to check that the basic functionality is still ok. Our checklist lives on a wiki page. As I go through the list, I make a set of notes on a page. If I raise an issue, I’ll post a link to that issue in my notes. I use the same page for every sanity test I do. What I’ve ended up with is a page whose changes I can compare over time and different releases.
Spec Review
Recently, I’ve been taking every opportunity I can to do testing at the beginning of the software process rather than the end. I’ve been looking at specifications when they are mostly but not completely finished. I’ll either leave a comment on the page with a few questions about the spec, or I’ll make a page of a few test objectives. Writing down a few high level test objectives has proven very helpful to product managers and developers as it gives them edgecases to think about when they are designing features or writing code. These high level test objectives can be reused later for system testing.
A Low Tech Testing Dashboard
System Testing
Above is a screenshot of a low-tech testing dashboard. These are not a new concept. I see them mentioned online every now and then. The template I started with is James Bach’s although the test team I work with has altered it somewhat.
You’ll notice that we’ve got a few features listed. Each feature is linked to a page with test objectives. Here is an example of a page with test objectives.
Some Wiki Test Objectives
Confluence has a way to let users build templates for pages, so when I make test objectives, I use our template. This could be replaced with any set of heuristics you want to use. It’s highly likely I’ll be changing this up for my next set of tests.
Since we are now down at the feature level, I will add pages to this for the testing that I do. This is where it gets messy, but that’s ok. What I’ve noticed is that I don’t have much structure past this point. I will either link the test objectives to a page or I will just add a page if I’m session-based testing and write stuff as I go along.
Some Session Based Testing
That’s all I do…really. I feel privileged that I’m not asked to come up with tons of documentation or to follow an involved process for documenting the testing. The way I see it, using the wiki to do testing embodies the Agile Manifesto‘s “working software over comprehensive documentation.” The documentation looks incomplete because I don’t write everything down. I’m too busy testing.
There are some situations where using a wiki will be challenging. It can be difficult at first for people to be comfortable enough with the openness to edit pages or add comments. If you need to aggregate huge amounts of meta-data from your tests, wikis are not there yet. If you have hundreds of tests trapped in a knowledge based tool, I don’t know how to help you extract those into a wiki.
It is possible to do test automation through a wiki with tools like FitNesse, Selenesse. I haven’t done this, but I know others, including Matt and Chris have extensive experience with using a wiki in conjunction with automated tests.
At my CAST presentation, I went through my prezi which I rehearsed lots in my hotel room. I then logged into an example wiki with a testing dashboard and some tests I had written. I was a little frustrated that I didn’t have more to show off, but that’s the point of a wiki. You end up with less but what you do have on the page means more. I also know why Matt was so excited for me to give a presentation about this. I was worried that I didn’t have excessive numbers of pages to show off or highly structured documentation, but this is exactly why wikis are so useful. Wikis cut through the shit.
After I finished showing my examples, Matt showed off how he does testing through his Socialtext wiki. I was also very excited that the Dave Liebreich got up to show off his wiki as well. I’ve followed him since he was blogging at Mozilla, and was already super-stoked to meet him, let alone have him attend my session and show off his wiki.
Thanks to Matt Heusser for encouraging me to submit this as a topic. Since I work in a wiki all-day, every day, it’s easy for me to forget how lucky I am and how different this is. I don’t have to worry about which shared drive has the right version of the requirements. I’m no longer chained to a testing tool someone else has told me I must use. I get to arrange my testing in a way that suits my brain. I wish every tester had this opportunity and I hope that what I’ve written helps someone else get started with using a wiki for software testing.
Voodoo Doughnuts is the home of the bacon maple bar and other doughnut-y delights.
Portland is a goth mecca of the United States as it has 1 of the only 3 Dr. Martens stores in the whole of the U.S. Aside from a plentiful supply of the only plaid Mary-Janes a grown woman can wear with respect, their free Dr. Martens guitar picks are m favorite Portland souvenir.
Powell’s bookstore puts used books next to the new ones and has that awesome earthy, intelligent real-and-not-a-frakking-chain bookstore feel.
The centerpiece of the technical testing track, for me, is Harry Robinson’s keynote Using Simple Automation to Test Complex Software. Those who are lucky will have the opportunity to attend his workshop after the conference. I met Harry at CAST and regret that I only got to talk to him at the end of the conference by which time my brain was processing at 56k speed. He’s got his slides up from CAST and I can’t wait to work with his ideas more for WTANZ and my own testing.
I’ve got some friends presenting so we’ll stop by and see Liz Marley’s poster Exploring Touch Testing: A Hands On Experience. I’m so envious that she does her job with an iPad, among other gadgets. We’ll also be front and center at Alan Page’s prezo, Peering into the White Box: A Testers Approach to Code Reviews. This is just about the only pie I haven’t stuck my QA finger into at Atlassian and I’m sure the devs on my team will be very excited and overjoyed for me to give it a go.
Of course, we have to go to Mark Fink’s talk Visualize Software Quality. I suspect Mark and I have a lot of complementary ideas when it comes to this topic and I hope he’s even been able to take it further than I have. He describes a tool he’s made for the purpose of visualizing tests and those who get to see him show it off are surely in for a treat. I’m glad that I’m not the only person doing work in this area.
There’s also another session in the visualization of test area. Last year, I met the marvelous and awesome Melinda Minch. At the time, Melinda was working at Microsoft for the group involved in the Pivot project (which has recently been moved into Bing). She took some excitement for visualizing tests back with her to Microsoft and I get the feeling whoever goes to the presentation Using Live Labs Pivot to Make Sense of the Chaos will get to see the results of the enthusiasm she spread amongst her team. I am expecting Awesomeness and can’t wait to read the paper. Hopefully there are some screenshots and maybe a movie involved. This is not the last I expect to write about this presentation and this topic on my blog. Tests are only part of what makes this project so interesting to me. Here’s a Ted talk that might partly explain why I find Pivot intriguing. Make special note of what’s said about the web at minute 4.
If you are fortunate enough to attend PNSQC this year, please drop me a comment about your favorite experience especially if maple bacon bars are involved.
(Additional shout-outs to Gabe Newcomb, Ken Doran, Matt Dressman and Lanette Creamer…I had so much fun talking with you guys last year!)
A few months ago, I wrote about my first 3 months at Atlassian. I’ve been doing a lot of Exploratory testing. It’s taught me about following through on my own thought process when I’m asking important testing questions. I’ve gotten better at thinking through different scenarios while using an app. I’m not a master like the co-worker with whom I test everyday (He IS a master), but I’m improving and it feels good.
I have, however, felt that I have a dirty little secret. I’ve been carrying around with me since I started working at Atlassian and learning how to improve my Exploratory Testing skills.
Taking a deep breath…
I love code! I love it! I love it! I love it! I love writing it! I love reading it! I love breaking it! Compiling it makes me so freaking happy!
After a day when I’ve had my IDE open (I don’t care which one, any will do), I leave work feeling satisfied! The days when I work on automated tests or do anything with a script are always my best days at work, even if I’m tired, even if it took me a while to get results, even if I’ve endured crazy looks from the 5 people I had to ask in order to figure out WTF I am doing. Today, I came home after working through an automation problem with our test infrastructure expert and my brain was so tired that I could barely spell my own name, yet I feel energized. I love working with test automation.
So am I still a tester?
I’ve felt so conflicted about this lately. If I’m so interested in working with code and scripts, what does that say about me as a tester? Does this mean I’m a dev in disguise? Am I a wolf in tester’s clothing?
This situation reminds me of one of my best friends from college. She came out as bi-sexual during our freshman year. She was in a phase were she had a lot of questions about herself and the world around her as it related to this new way she had of defining herself. I remember she came home with me to see my hometown (we were effectively trading, I had been to see hers) and we went to a local lesbian bookstore. She asked the sales clerk if they had any books on bi-sexuality. “We might if it existed” the clerk sniffed. Once we were outside of the store, my friend explained that even within the gay community, bi-sexuality was a somewhat controversial topic.
What my friend taught me, is that there are areas within human existence that we might try to neatly categorize, but in the end, people are too beautifully messy for labels to apply. We are labeled in many areas of our lives including our careers. So if I self-identify as a tester, does that mean that I am creating a career trajectory for myself where I’m shunted away from code because I don’t have a developer job on my resume? Will I be ostracized by some in the testing community because I tend to embrace code alongside exposing its flaws?
Here is where I think the truth lies:
There are people who who see testing skills and coding skills as mutually exclusive as are the people who fill those jobs. I hope I never work for them.
We’re never going to solve big problems in testing unless some of us are not just passable, but extremely good at writing and architecting code.
Not having the word “developer” on my resume doesn’t mean I don’t know how to work with references or that I can’t recurse through a stack of calls.
Exploratory testing skills such as observing, questioning and critical thinking are just as important as coding skills. There’s no compromise here.
There are other testers who also self-identify as straddling the dev-test line. They are my heroes and role models. (Perhaps they deserve their own blog post, if I named them and why, this post would be quite lengthy).
I’m finished with the part of my career where I justify my identity as dev-test to myself or others. The tagline next to my name means the same thing today as it did when I put it there. I’m guessing that it will take me longer to become masterful at both sides of this equation as well as the resulting intersection, but I will not stop trying.
This month, Weekend Testing Australia-New Zealand was happy to welcome Trish Khoo as our guest facilitator. Trish writes the blog Purple Box Testing and works with another test blogger, James Martin (The beaches here in Australia are awash in excellent software testing bloggers…who knew!)
We seem to have a thread going around Watir and Ruby (likely to be continued next month) which Trish helped to push a little farther with this month’s project. Whenever Trish is writing automation, she finds it helpful to get a few files containing lists of controls for the pages being tested. Our mission was to use whichever framework we had handy (duh! Watir) to create files containing some lists of the elements, such as links and buttons, on each page. The application we used was the very practical National Public Toilet Map of Australia. (I hear there’s an iPhone app for this.)
I guess this doesn’t sound too much like a garden variety Weekend Testing topic, it’s pretty involved and isn’t immediately testing (like with our brains) but this has been one of the most interesting sessions I think we’ve had in a couple of ways:
It’s giving me something practical to try with Ruby and Watir, and gets me into looking at the content on a page or set of pages. This isn’t necessarily system testing, but being able to get meta-data out of a SUT about the elements it contains could be an entry point to asking questions. I am all about asking questions in as many different ways and from as many different perspectives as possible. At some point I want to look at how I can do this at work where I use Selenium and Java.
The conversation between Trish and Oliver (Oliver Erlewein is another WTANZ facilitator) was fascinating. I ended up not asking too many questions because I wanted to see where they would take their conversation.
Since I’m not that familiar with Ruby, I had to abstract mine down to something I could accomplish in an hour. I was able to get a list of links from the page into an array. Although getting lists of all of the different types of controls such as buttons and checkboxes was beyond the scope of what I could do, Watir seems to have plenty of methods for these (here is the api. In restricting myself to links I searched through the Watir Google Group and found a link to this page on Collections of HTML Elements in the Watir CONFLUENCE Wiki. The example made getting an array of links a fairly trivial task.
While I didn’t end up with the script that Trish was describing, I kept working on this mission well past our allotted 2 hours.
I’ve thrown some of the commands I used into a gist on Github. (don’t judge the crappiness…just don’t) I know that ruby scripts are easy to make, but I’ve had some issues getting my browser to work with scripts, so I’ve just been using irb. Maybe I’ll do some work on that in the next month.
Switching WTANZ to being monthly is much more sustainable and seems to be working out. Preparing an interesting topic every other week, as we were doing previously, is not an easy task. I admire the Europe Weekend Testers for consistently coming up with the fascinating topics that they do on a weekly basis. We might eventually steal some of them for use down here in the Southern Hemisphere. Oliver was hinting at some Cucumber for our next session and I’m still turning over Model-Based testing and some other extremely non-trivial ideas for sessions.
In WTANZ 07, Oliver helped us install Ruby and Watir (it was rather painless). After the install, we were to log into the Weekend Testing web-site and add a forum post. Since that session, I’ve been playing with Watir at work and discovered that the Firefox extension, Firebug, together with the information in the Watir google group greatly speeds up the learning curve for writing tests.
This week, on Sunday (for most ;o), we will be writing automated tests of the Weekend Testing web-site with Ruby, Watir and Firebug. The mission is to find a bug in the Weekend Testing web-site and write a failing Watir test for that bug.
There are 4 learning objectives:
Learning the structure of the Weekend Testing pages through the use of Firebug
Improve our Watir syntax using the Watir google group
Find out which bugs lend themselves to being recorded in an automated test
Shed some light on the utility of writing failing tests for a bug that’s been found. Is it a useful way to record what happened or is there too much overhead involved? I’ve heard both sides and would like to investigate this for myself.
Note: This session will be better for everyone involved if we all have watir, ruby, firefox and firebug installed. If you want to participate but don’t have them installed, please check out the transcript from WTANZ 7. Everyone in that session had watir working by the end.
If you’d like to participate, send an email with your skype id to weekendtestinganz at g m a i l dot com
Times:
Sunday, August 21
Sydney 4:30 pm
Wellington 6:30 pm
Manila 2:30 pm
Frankfurt 8:30 am
Bangalore 12:00 pm
Seattle, Saturday 11:30 pm
Update: Here is the transcript from our session. Life has kept me from writing a complete follow-up (or anything else), but I am hopeful Life will cut me some slack in the next week.
