Category: Uncategorized

This post is dedicated to Eli Saad for encouraging me in my Gaga Pumpkin endeavors and for being himself every day.  I’ll miss you!

Recently, Lady Gaga visited Google in her thigh boots and everything.  You can watch the brilliant frakking youTube video here.

 

In the video, Marissa Mayer asks Gaga questions that were gathered from YouTube.  Questions are also asked by Googlers in the audience.  Usually when a star gets interviewed with questions, it’s a mixed bag.  With Gaga, I found that there was a coherent theme around something I’ve been bursting at the seams to write about: congruence.

 

I hear it now..Congruence??? What the fu**…Marlena!! What is that? Isn’t that what you test? Um…no.  It’s psychology, bitches.  That’s right…I said the P word.  Jonathan Kohl wrote a blog post about it which is a favorite of mine.  My post will expand on his, explain this concept with the help of Gaga and why we must practice it to build great software and to be great testers.

Let’s start with a quote from the interview about unlocking your creativity:

“I really encourage people to look into the darkness and to look into the places that you would not normally look to find uniqueness and specialness because that’s where the diamonds are hiding.”

Each of us is unique and special.  Unfortunately, this is not always respected.  In Gaga’s case, she was bullied pretty hard in school.  Note that bullying can happen at school OR work.  For whatever the reason, bullies can tear us down, make us feel small and undermine our confidence.  When this happens, it is very difficult to expose our uniqueness or creativity because a smack-down or a slushee might be waiting around the corner.

 

 

We hide who we are as a defense mechanism.  This is why people will often hide away whatever part of themselves is unique and special.  Unfortunately, being human doesn’t work this way.  When we try to hide who we are, when we show the world what we think it wants to see the results might be passable, but they will never be great and they will likely worsen over time.

 

Let’s think about what exploratory testers are trying to accomplish.  We want to learn the software.  We want to explore the software.  We do this by opening our mind to the possibilities of what can happen.   We learn to trust our instincts about where a user will want to take that and what can go wrong when they do.

 

For exploratory testing to be successful:  We MUST be open.  We MUST be curious.  We MUST be intuitive.

 

(Which of these people to the right is not like the other?  Answer: ALL OF THEM)

 

 

 

This leads me to ask:
If the everyday reality of your team or your company requires hiding from who you are and pushing away from your inner self and your intuition, how can you be intuitive about what you are testing?  If you are someone who is hyper-critical of others (just a few testers in that group), are you causing others to feel that they have to hide themselves or their opinions from you in some way?

 

Congruence is about matching who you are on the inside with who you are on the outside.  What you say to people represents what you are thinking and feeling, not what you think you should be feeling and definitely not what you think the person with whom you are speaking wants to hear.

 

Going back to the interview, during the section where Googlers are asking questions, a guy in a shiny, pointy hat asks Gaga how she reconciles her onstage “persona” with who she is in real life.  Gaga looks him in the eye and chuckles, “Who are you looking for?? I”m right here! Stephanie’s also who I am!  Gaga’s just my nickname… I really make absolutely no separation between Stephanie and Gaga. It is the absolute same person…and it is a gift I wish I could give to anyone.”  You can’t get any more congruent than that.

 

So what have we got at this point in our post?  We’ve got the Lady in all her Gaga-ness, and we’ve got me saying that it should be totally acceptable to be who you are at all times.  I’m sure there are a number of you reading this and thinking, “but she is so offensive to me.”  If this is how you feel about Lady Gaga, and you’re still with me in this post, thank you for giving me the room to finish what I have to say on this topic.  Please stay with me just a bit longer.

 

Congruence doesn’t stop at being who you are on an every day basis.  It also means recognizing where you stand in the face of conflict.  This is where the diamond shines most brightly in Jonathan Kohl’s post: “Whenever I vocalize a small concern even when the rest of the team is going another direction, it is worthwhile. Whenever I don’t, we end up with problems. It helps me retain my independence as an individual working in a team. If everyone does it, we get diverse opinions, and hopefully diverse views on potential risks instead of getting wrapped up in groupthink.”  Vocalizing big and small concerns even when the rest of the team is going in another direction is what a tester does. If we can’t be who we are and have the independence to say what we feel, we will fail in our mission as testers.  Notice also that Jonathan is saying, “If everyone does it.”

 

This leads to another question:

How can everybody be themselves at the same time without offending each other?

In this situation it is inevitable that there will be disagreement.  If we are channeling our inner-selves and letting the freak flag fly, it is inevitable that someone might get offended.  This is when tolerance and mutual respect are a must ON BOTH SIDES.

 

1. Others should respect and be tolerant of you.
2. You should respect and be tolerant of others.

 

If either side fails to respect the other and someone is pushed further than they can go, there’s a good chance  that the argument will turn personal and, in that situation, everyone loses along with the customer. We have to be able to argue constructively with each other and express what we’re thinking when we think it.  We have to be able to do this openly and without fear.  If we can’t do this, then we are effectively muzzled as testers and as people.  As an illustration of the type of freedom that follows from respect and tolerance, I recently spoke with a developer who expressed his respect for bugs that simply say, “this is awkward.”  Is this something you can do at your job?  As testers we need to be free to express what we observe when we observe it even if it’s just a feeling that we flesh out at a later time when we are finished observing.  This is the road to creativity.  Another quote from Gaga:  “The most important thing is to honor your creativity and don’t ignore it…It’s when you say, ‘Oh I’m too tired let me just go to bed.’ That’s when the creativity stops coming…You know, if God calls you, pick up the damn phone.  Hello!”

 

I bet if Lady Gaga were an exploratory tester she would be pretty good.

 

Congruence is all about being the same person on the inside and the outside.  What you are thinking and feeling are in concert with what you are saying and doing.  Anything else is a compromise.  Most of the time, compromise is essential for getting things done and coming to a conclusion in a respectful way, but when it comes to being the person you are, there should never be a need for compromise.  Be who you are, not what others say you should be.

 

A long time ago, I promised myself that if life offered me an interesting plot twist, I would follow it.  Perhaps this is why I love working in the tech industry.  The pace is fast and the rate of change is exponential (or sometimes even logarithmic).  Being open to learning is required for professional survival.  Personally, I’ve found that the plans and dreams I had 12 months ago, are not the same plans and dreams I have today. They’ve gotten bigger and I’m feeling ambitious.  (a woman with ambition…this could be dangerous.)

 

Atlassian has been a great place for me to get my feet wet in Agile and to work with web-based technology.  I love Confluence and the rest of Atlassian product line up.  It is sad to leave, but life has given me another plot twist, and I’m going for it.

 

I’ve gotten a job with Mozilla’s WebQA team, and expect it to be a great challenge.  Although the job includes exploratory, manual testing it will also be heavy on the writing of selenium checks and test infrastructure with python.

 

The automation lead for the WebQA team with whom I’ll be working is David Burns.  He writes the blog, The Automated Tester, and has published a book on using Selenium.  We met at the Google Test Automation Conference in 2008 and have kept up with each other through blogging and twitter.  This will be my first opportunity to work with someone I’ve met through blogging which blows my mind!

 

To join the Mozilla team, I’ll be moving to the Bay Area in California where their headquarters is located.  I will miss Sydney and the people I’ve met here.  Believe me, I will shed a few tears when I board the plane to leave Australia.

 

It is, however, a few weeks before I leave, and I’ve got some loose ends to tie up.  I’m working on a retrospective of using a wiki for software testing.  I also plan to facilitate a session of WTANZ on March 20.  Since I’ll be in a timezone far removed from Australia AND New Zealand, this will be the last WTANZ that I facilitate.

 

Does this mean it’s the end for WTANZ?  Although I haven’t made plans for a handover, I suspect that it is not.  I’ve been quite impressed with how different groups have taken the “what” of Weekend Testing and changed the time to suit their needs.  I’ve also been impressed with the community of testers I’ve found in this part of the world.  They are a rollicking bunch and I’m glad I can at least keep up with them on twitter.

This week, I’ve been reading the book, “The No Asshole Rule:  Building a Civilized Workplace and Surviving One that Isn’t” by Dr. Robert Sutton. For the past few months, I’ve been working at building a relationship of trust with the developers whose code I test. As part of that, I’ve been exploring the divide that often happens between developers and testers. It’s so easy to have an antagonistic relationship and to forget that instead of placing focus on us vs. them (and I’m talking from either side) it should be more important to think about the “we” of the software team. The end goal is, after all, to get the software out the door.

I plan on writing more about this, but for now, I wanted to share a few bits from this quiz in the “No Asshole” book. I took this quiz, and it told me that I am not an asshole (my sister might not have the same opinion). It got more interesting when I decided to reframe it. I substituted all of the pronouns “other” and the word “people” with  the word “devs.” The quiz, then, took on a completely different meaning. I’m not posting the whole quiz because the book is worth reading so I hope you’ll find at your local library or purchase it. There is, alas, no kindle version. Hopefully, Dr. Sutton will get hip like Jerry Weinberg who has begun selling kindle versions of his some of his books.

There are 2 versions here, a tester one and a dev one, although the tester rings more true to me than the dev one. Feel free to share results.

If you are a tester, write down true or false for your answers:

1. You secretly enjoy watching devs suffer and squirm

2. You have a small list of dev friends and a long list of dev enemies. You are secretly proud of both.

3. You enjoy lobbing “innocent” comments into meetings that serve no purpose other than to humiliate or cause discomfort to the dev on the receiving end.

4. You don’t make mistakes.  When something goes wrong, you always find some dev to blame.

5. Devs keep responding to your email with hostile reactions, which often escalate into “flame-wars.”

6. Devs always seem to react to your arrival by announcing that they have to leave.

If you are a dev, write down true or false for your answers:

1. You secretly enjoy watching testers suffer and squirm

2. You have a small list of tester friends and a long list of tester enemies. You are secretly proud of both.

3. You enjoy lobbing “innocent” comments into meetings that serve no purpose other than to humiliate or cause discomfort to the tester on the receiving end.

4. You don’t make mistakes.  When something goes wrong, you always find some tester to blame.

5. Testers keep responding to your email with hostile reactions, which often escalate into “flame-wars.”

6. Testers always seem to react to your arrival by announcing that they have to leave.

The Extremely Unscientific Scoring:

0-2:  Not an asshole

3-5: Borderline asshole

6: Certified Asshole

Perhaps the lesson here is that it’s important to keep “we” in mind instead of “us” vs. “them.”   This means being less concerned with our job title and more concerned with using our best skills to get the software out the door.

In the past week, there have been two blogposts  one about testing and one not necessarily about testing.  Both, in their own ways, dealt with a theme of caring.

The first is a post on the Thoughts from the Test Eye blog from Martin Jansson titled, Turning the Tide of Bad Testing.  The centerpiece of Martin’s post is the Broken Window Theory which you can read about in his post.  He ties it to testing with a thought provoking list of how broken windows manifest in software testing.  To me, the list is a masterpiece.  There are a couple of items on that list that stand out in terms of this post:

“How do we see Broken Window Theory affect testing?…

• When you have stopped caring about how you test.
• When you have stopped caring about how you cooperate with others.”

The second post is Alan Page’s post on Leadership and Caring.  It’s one of his shorter posts and he wrote without the intent that it was about specifically about testing.  He writes that, “Leaders care about making progress in their work and in sharing their results. More importantly, they care about the work and progress far more than they care about their popularity.”  His post seemed to strike a testing nerve which is revealed in some of the comments of that post.

Both of these posts were well-timed for me as I have just finished reading a very interesting book, The Sociopath Next Door.  As the title suggests, the book is about Sociopaths.  These are people that lack the ability to care.  They have no conscience.   Every move they make is merely to make themselves more comfortable even if it requires looking like they are helping others.   The book illustrates several examples of sociopaths including the so-called “Captain of Industry” whose sole goal in life is to win, regardless of the pain and chaos it creates for other people.

As I read this book, I kept thinking about testing.  At times, I have felt that, as “the tester” I am the conscience of my team.  The truth is, I work on a great team where everyone cares about what we release.  The more interesting question is, could someone who has no facility for caring about others make a good tester?  What if a tester works on a team with a leader who has no ability to care?  What happens to the testing?

Before I read Sociopath, I had never stopped to carefully consider the role conscience plays in testing.  Critical thinking is great, but it’s equally important to understand people’s motivations.  Caring sits in an under-layer that is easily forgotten or dismissed as being yet another “personal” or “soft” topic (I call them hard topics).  Perhaps it’s more of a foundation than an under-layer.  If so, what does that mean if it’s missing?

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.”

We had 2 activities, both of them involving bugs in Atlassian’s open-to-public-view issue tracker.

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.

The transcript is here.

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.

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.”

Checklist Manifesto:  Checklists were used to make surgery much safer

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.

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.)

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.

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.

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.

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:

1. 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.
2. 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.

Here is the transcript.

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.