The Liberation of Testing

A slide from Alan's presentation at PNSQC

 

This is a guerilla blog post from PNSQC.

 

My great friend and fellow testing blogger Trish Khoo recently wrote a post inspired by Goranka Bjedov’s keynote at STANZ 2011.  In her post, Trish reacts to some news delivered by Goranka at STANZ:  “Quality is Dead.”

 

This morning I’ve had the pleasure of listening to Julian Harty play understudy for an ailing Goranka with his opening keynote for PNSQC.  I am guessing that although Julian gave a talk that seemed very much his own, the heart of what he was saying is similar to what Goranka was exposing at STANZ.  (You can bet that as you are reading this, I have absconded to watch the video of her keynote.)

 

What I noticed not just in Julian’s keynote, but the subsequent presentations I attended today, was not a death so much as a rebirth,  a liberation and even a tearing down of walls.  At the end of the keynote, I tweeted that I can feel another paradigm shift happening not only testing but also in software.

In the keynote, Julian talked about how Dr. Barry Boehm has moved on from saying that bugs are found more cheaply earlier in the software process.  Instead, Boehm has been writing that it is now just as cheap to fix bugs in production. This was the perfect setup for Keith Stobie’s presentation, “Testing Services in Production”.  Keith drove home the point that he is currently much more comfortable testing in production than testing in any type of “staging” environment.

 

Aside from moving testing into a production environment, there is some testing that Keith doesn’t even call testing anymore.  He calls it “monitoring.” This is where the wall between testing and production really crumbles away.   He talked about moving asserts from tests into the production code.  I’m sure that this is nothing especially new.  What’s new is that now there are people relying on this code as an indication of system health.

 

In his presentation, “An Introduction to Customer Focused Test Design“, Alan Page (who got us to lunch on time) talked about how his team has been getting away from even doing functional tests by focusing on “ility” testing instead of functional test design.  This in essence, means that his team is much more focused on performance testing.

 

What does all of this mean for those of us who consider ourselves “QA” or “Testers” or some similar combination.  It means that our jobs are changing and will probably look very different in a few years.  I lost count of the number of times Julian mentioned “testing not being around,” “automation experts being out of a job,” “testers being out of a job” or even questioning the validity of a testing conference.

 

As someone who is currently employed to primarily work with test automation and test infrastructure, dId this make me uncomfortable?  Not at all.  In fact, it’s very exciting.  You see, I’m here because I love change and innovation.  If there is something better, I’m all for tearing away the cruft and exposing the new.  It might mean that I start adding code to the app I work with for web timings or that I end up with a job title that has no trace of “test” or “qa.”  The focus is undoubtedly shifting away from looking for bugs and presuming to know what customer’s want  to making sure real data is available about system health and that we know how to interpret it.

 

How does all of this apply to my talk on “Hard Lessons About Soft Skills?”  All of this means that we’ll be more embedded with the devs than ever before.  In fact, it might even mean that we will be the devs.  If they don’t want us on their team anymore because we’ve burned our bridges with them and we are sheltering behind the wall of QA, what’s gonna happen when the wall comes down?

 

No matter how things shift, I can guarantee that I’ll still be around and giving a shit about how well the software is working and whether or not customers are happy with it.  Are you ready to be liberated?

 

I’ll leave this guerilla testing post with a classic from LEGENDARY rockers, “The Scorpions.”

If you are a developer and you would like to own the quality of your code…

Operation Sock Monkey! by moon angel, on Flickr

A flashpoint that I don’t see much discussion about is the moment when developers realize they need more of a stake in the quality of an application.

 

I know quite a few developers who care about quality, and I’m sure they each have their own story about the moment they realized how important it can be.  I’ve seen devs realize the difference a focus on testing can make when they’ve outpaced their testers and the testers had no hope of ever catching up.

 

In a meeting I attended awhile back, a dev said to me that he wanted to have more ownership of testing.  Now, it’s not like he wants to wrestle it away from the testers, but he would like to feel like he is taking a more active role in the quality of his code and in the application.

 

 

These are just a few suggestions from me:

Don’t make it too cumbersome to write tests
I’ve worked with test infrastructure that was so old, there was a lot of new functionality lacking and old bugs made some testing a real pain.  A frequently heard dialog was, “did you write tests for that?”  “Uh, no, the framework doesn’t support it.”

Don’t be too strict about having perfect tests
Especially if you have developers who are just getting use to writing unit tests or functional tests, make it a positive experience.  It should be ok to play around with what works well in the tests.  It means that there will be refactoring later, but having tests to refactor and developers interested in refactoring them is better than having devs who are scared of ridicule when they write tests and no tests at all.

 

Use short developer checklists

– have an awareness of stuff that you tend to miss and make a short list to check for them
– are there certain types of problems your team is trying to avoid?

 

Make sure the interns are testing
We all know that testing education is hit or miss in CS programs.  If you work around interns make sure they are writing tests.  If they don’t know how to write tests, you’re looking at someone who will be a developer that doesn’t own tests or the quality of their code unless you intervene. This isn’t to say that I haven’t met interns who know how test, just that there are plenty who don’t.

 

But this is just me…the tester talking about owning quality.  I went in search of some Mozilla web devs interested in sharing their perspective on this topic.

 

Kumar McMillan  (@kumar303)  a developer for addons.mozilla.org had these tips for developers:
test each component in isolation so that it works

  •  Integrate components early and often because there are usually surprises, especially when integration spans multiple teams (via APIs / services, etc)
  •  Test at different layers of integration.  For example: write tests that combine lots of backend components but not no frontend components.
  • Developers should deploy code directly or be present when deploying code and should know where to look to monitor the health of the deploy.  Without this direct responsibility it’s easy for developers to lose track of quality.
  • It’s also important for developers not to over-test components.  It’s tempting to boost code coverage graphs or attempt a 3:1 test to code ratio but generally these practices are not helpful.  It will slow you down.  It’s more important to get code into the hands of users with crucial edge cases covered by tests.  The “happy paths” are not so important to test because it is more likely for those to be explored.
  • Whenever there’s a bug it’s important to write a test to prevent regressions before the bug is fixed.
  • Always use continuous integration and make every developer own up to their mistakes when they break the test suite.
  • All tests should be automated in CI otherwise that test is useless — someone will forget to run it.

 

Dave Dash (@davedash)  who recently gave the workshop “Test Anything, Test Everything” at DjangoCon took a more philosophical approach.  Dave’s perspective is that “Quality is more than finding bugs.  It’s about having a high-quality product.”  He mentioned it’s about having pride in your work and caring about the website you build.  Dave’s attitude is one that I’ve consistently found in the best developers I’ve worked with.  As a tester,  I’ve noticed that it’s always 10 times easier to work with developers who care about quality and testing because they want their code and the applications they produce to be great.  Quality is, indeed, about more than finding bugs.

Thanks to Dave and Kumar for sharing :)

 

If you have your own opinion about how developers can own quality, I invite you to share it in the comments.

Talking at PNSQC about being a testing asshole

Portland by diebmx

A theme has been running through my blog on the topic of being a testing asshole.  It began with the post “The Tester’s Paradox” and continued with the posts, “Is it necessary for testers to care?,  “Are you a testing asshole?”  and  “Let’s destroy the World.”

 

In these posts I worked through my own experiences with my behavior on a software team.  These posts also came from my processing on some of the books I was reading at the time.  My bookshelf for these posts includes:

  • The No Asshole Rule, by Bob Sutton
  • The Sociopath Next Door, by Martha Stout
  • Crucial Conversations by Kerry Patterson
  • Good Boss, Bad Boss also by Bob Sutton
  • Artful Making by Rob Austin and Lee Devin

 

After all of the reading, all of the testing, lots of asshole screw-ups of my own and dealing with some people in my life who are pretty big assholes in general,  I’ve drawn some conclusions:  Testers are automatically placed in the most socially awkward position on any software team which means we need more social skills and awareness than anyone else.  We need more emotional fluency.  We are not assholes and because of the work we do, we must learn how to minimize our asshole behavior as much as possible.  As I’ve been reading and learning about this, I’ve found enough compelling information that I decided to put it into the hands of testers by giving a talk at this year’s Pacific Northwest Software Quality Conference (PNSQC).

 

The talk is meant as a means of self-reflection just as the examination of this topic has been an exercise in self-reflection for me.  I’m hoping that people who come to my talk walk away with more questions than answers.  I hope it gets people thinking about how they act with others on their team.  There is so much in testing that we have absolutely no control over.  My hope for this talk is that it gives people enough information to work on controlling the things we can control.

 

Since I’m not a psychologist, I teamed up with my friend, Gordon Shippey, who is a licensed counselor, to write the paper.  We didn’t feel comfortable calling the talk, “Are you a testing asshole?” so we settled on, “Hard Lessons about Soft Skills — Understanding the Psyche of the Software Tester.”

 

I’ll be talking about:

  • Asshole behavior in the context of testing
  • Crucial Conversations
  • Recovery and Repair
  • Testing in a Safe Environment

The paper Gordon and I wrote in conjunction with the talk is intended as a resource for times of testing distress when testers feel they’ve backed themselves into a corner or find themselves handling situations in ways that don’t make them proud.

 

Another conclusion that I’ve drawn in all of this is that anyone can be an asshole when put in the right situation.  Personally, I now have enough confidence to know that 95% of the time, I’m not one of them.  This realization has made all of the effort and hard work I’ve put into this paper and talk worth the time spent.  I hope others find it useful as well.

 

Running AMO Tests with moz-grid-config

This post contains the instructions for a workshop that is part of the addons.mozilla.org automation testday.

 

For running the AMO tests, it’s good to use our moz-grid-config repo to run selenium because it allows you to get around some issues like setting up a separate firefox profile for accepting certificates and it contains both the standalone version of selenium rc as well as what you’ll need to run selenium grid.

 

If you’d like to know more about how grid works, you can check out this page.

 

Here is the url for the repo which includes a readme.

 

Once you’ve cloned the moz-grid-config repo using
git clone git@github.com:mozilla/moz-grid-config.git

You can try starting it up.  There are 2 commands for this which will each need to be running in their own terminal window:
ant launch-hub
ant launch-remote-control  -Drc.environment=”environment name”

 

The value from the -Drc.environment parameter comes from the grid_configurations.yaml file.  If you have a look in the file, you’ll see options for other environments including Firefox 6 and the Aurora channel.

 

It’s also worth noting that the selenium jars are in the vendor directory.

 

Once you’ve got grid up and running, and forked the AMO test repository, you can run some AMO tests with this type of command line

 

py.test -n 5 –browser-name=”Firefox 5 on Mac OS X” -q test_search.py -k test_that_searching_with_substrings_returns_results

-n 5 is xdist telling py.test to run 5 instances at a time.  Note that you need to have multiple terminals going with ant launch-remote on different ports to use this option.  If you don’t specify a port number when you run “ant launch-remote” it will launch on 5555
–browser-name=”Firefox 5 on Mac OS X” is specified in the grid_configuration.yaml of moz-grid-config
-q test_search.py is telling py.test to run the file test_search.py
-k test_that_searching_with_substrings_returns_results

 

-k is a keyword parameter.  In this example it’s used for a testname, but we could also specify -k substrings to run any tests with substring in the testname.

If you get stuck or if something isn’t working with your environment, feel free to stop by the testday irc channel:  irc.mozilla.org #testday.  (Note, I probably won’t be watching twitter as much today since I’ll be in the irc channel)

These are your tests: Testing in the Mozilla Ecosystem

The Mozilla logo
Image via Wikipedia

Yesterday marked my 3 month anniversary at Mozilla.  I’ve been soaking it all in.  Currently my job consists of leading automation for addons.mozilla.org web-site.  I write selenium tests and test infrastructure in python, code review tests and infrastructure written by other members in our community.

 

But that’s enough about me.  This post is all about you.

 

My favorite aspect of working at Mozilla is that every test I write or review is part of a community ecosystem that supports Mozilla’s mission of “promoting openness, innovation and opportunity on the web.”

 

Openness
The codebase that I work with is completely open in this github repository.  Anyone can download it, run the tests and play with them.  Thanks to the nurturing of our 2 selenium core commiters, David Burns, The Automated Tester and Dave Hunt, our team is also code-review-infected.  These code reviews are also completely open in the pull request section.

 

Innovation
Our team is fairly aggressive when it comes to trying new stuff. We are already talking about how to switch our tests over to Selenium 2 before the end of the year and I would be very surprised if mobile tests didn’t make an appearance in one form or another.

 

Opportunity
Because these tests are open, it’s an invitation to try something new with selenium that perhaps you wouldn’t get the chance to try otherwise.  If you work primarily with selenium and java, this is your chance to see the python bindings for selenium in action.  If you’ve ever wanted to see the difference between xpath and css or wondered what an architecture using page objects looks like, this is your chance.

Mozilla frequently holds test days for it’s different applications, and the automated tests for addons.mozilla.org are no exception.  Our next testday will be August 19.  These are an opportunity members to focus on writing some tests.  For the last one I ran a github workshop and am already thinking about what type of workshop I will hold for the next testday.

 

I consider this a testing ecosystem, because while I can add tests myself, the real win is having contributors learn something or teach the rest of the community something with their code.  The strength of the tests is gathered from the diversity of contributors.  With so many smart and generous people working and learning from each other through these tests, we will show what can be done with browser-based testing as well as shed some light on its challenges and limitations.

 

These are your tests and they help to ensure that the open web works for you.

Enhanced by Zemanta

All up in your head: Changing my relationship with logic

In my last post, I vented a little about logic and discovered something about myself.  In addition to re-framing my relationship with testing, I need to re-frame my relationship with logic.

 

Sometimes when I say something that I think is true, I realize that it’s not all true.  I like the scene in the classic movie, The Princess Bride when Billy Crystal’s character, tasked with resurrecting what appears to be a dead man on his table says, “There’s a difference between mostly dead and all dead.  You see mostly dead is slightly alive.”  In expressing my boredom in Puzzles class, I made some blanket assumptions about myself and logic.  Is this relationship all dead or mostly dead?  Actually, I don’t think it’s even mostly dead.  It just needs a bit of an ambush makeover.

The reason why I don’t think my relationship with logic is as dead as I assumed is because there are classes where I’ve done work with logic and loved it.

Classes I enjoyed where logic was used:

  • Discrete math (I loved this class so much I never wanted it to end)
  • Artificial Intelligence
  • Formal Methods – In this class I learned how to connect requirements to the logic equations I learned in Discrete Math.  It was brilliant!
  • 6th Grade English (we diagrammed sentences…was fun!)

Classes where logic was really boring

  • Puzzles
  • Scientific Methodology aka “How We Know” class (“How We Know” was our textbook.  My copy has mysteriously disappeared into the ether of time)
  • Intellectual History (I learned about dead nerds who were not men of action.  One of them never left the bathtub. I suspect they were hipsters before their time.)

Hmm…there’s a fairly clear delineation here for me.  Classes in the first category are science classes.  Classes in the 2nd category are humanities classes.

But I love humanities!!!  What happened?

I think I know.  I like the clarity that comes from breaking down something complicated into different pieces and rebuilding something completely different with the same pieces.  That’s useful for me.  It can be very simple.  I’m a great fan of DeMorgan’s law and it’s friends.  There is no pretension here.  There is no bullying or critique…just order being made out of small simple pieces.  In the classes I loved, logic made me so happy!

If we skip to classes in the second category, logic turns into something entirely different.  While I have a healthy respect for those how brought us logic and were killed or punished for it, there is still plenty of history that is dead dudes trying to one up each other with fancy 3 and 4 syllable words.  There is nothing fun about decontextualizing a tautology by using inferences instead of deductions.  (Don’t try to figure that out, it’s nonsense.  I made it up).  This view of logic means as much to me as the shade of lipstick being worn by the housewives in Orange County.

The reason I draw a parallel between some of the most revered scholars in history and the cattiest women I’ve ever seen in my life is because logic can be used poorly just as it can be used beautifully.  I understand that the people I learned about in the classes I didn’t like were directly responsible for what I learned in the classes I did like. I guess that not enough attention was paid to the fact that it is easy to abuse logic.  Logic can be used to argue someone into a corner for the purpose of making her feel horrible about her new brow lift.  Logic can be used to send someone in circles and can be used to split someone’s hair extensions until her weave is ruined.

In this, I see that philosophers and testers have some of the same challenges.  It’s easy to do too much and not know when to stop.  I’d like to see how far Aristotle would go to isolate a bug.  Logic is no good if the person using it doesn’t pair it with heart and an understanding of when to quit.  I have a few critical thinking books in my library and both are very clear about how it can be misused.  If I had time, I would keep writing.  Unfortunately, for now, my draft for PNSQC calls.

I have more work to do with logic and testing, but this is shaking things loose for me.   The walled garden I’ve been living in has become a safe place and is showing signs of new growth.

Let’s Destroy the World

Life on a Grain of Sand, 5
Image by adonofrio via Flickr

Before I was ever a tester or even in software or even cared about software, I was in Puzzles class.  This was a class I took as part of the hippie-powered liberal arts program where I spent my first 2 years in college at Appalachian State University.  Doesn’t it sound like a fun class?

Well…despite my best efforts, it bored the hell out of me.  There are many testers for whom this class would have been a dream because it was all about logic puzzles, but I find philosophy and talking about logic absolutely, stultifyingly BOR-I.N.G.  Even if I try to listen and do the whole “fake it ’til you make it” bit, my eyes glass over and it’s obvious fairly quickly that I just don’t care.  At this point in my life, I know that philosophy will never turn me on and I own it.  Don’t get me wrong, there’s gold to be had in philosphy for the field of testing. I won’t be discovering it.   I have lots of respect for people such as Rick Scott and Zeger von Hese who can throw down with this and make something important and gorgeous out of it. (Go dudes!)

This means that I obviously didn’t learn that much in my puzzles class. In fact, there’s not much I even remember. I only have one memory from puzzles, but it’s come back into my life lately in a very bizarre way.  It’s helping me format the paper I’m writing for PNSQC.  Here goes:

The only thing I’ve remembered is the day that I showed up for class and our puzzles teacher told the class,”We’re going to destroy the world today.”

Apparently it’s possible to use philosophy to reason oneself into a logical position where the world cannot possibly exist.  Of course, I have no memory of how this is done or what it involves.  Philosophy leaves me too cold for that.

Anyway, the memory of my teacher’s words and his intentions, “let’s destroy the world,” have come back to me.  I’ve found myself rolling down a dusty and, at times, lonely road in my personal journey of software testing.  I have a ton of friends in this industry and I’m sure some of them will identify with what I’m talking about.  It’s entirely possible to find yourself in a crowded room full of people you love and still feel totally alone.  There are those of us in testing who live in this type of “walled garden” because we’ve burned through the ceiling of what a tester is allowed to be within our own ecosystem.

There are other types of fail showing up on the testing doorstep as well:   Devs often fear or hate us, our value is questioned on lots of projects and nobody ever starts their software career wanting to be a tester.   In fact, there are plenty of people who are in testing simply because it’s the only job they could get in software.  (I’m not saying it’s right, but we all know it happens.)

As testers, we’ve become adept at assigning blame for this.   Schools don’t teach enough testing, managers don’t understand how we bring value and devs just don’t give a shit.  What I’ve noticed is that we never ever point the finger at ourselves.  In my own testing journey I’ve come to a place where I’ve started ripping apart who I am as a tester and asking myself, the classic Dr. Phil question, “how’s that working for you?”

I’m now at the end of the road.

I am not a tester.

You heard me.

I AM NOT A TESTER.

and, in my world, neither are you… even if you’ve got 20 years under your belt, a fat paycheck and a bad attitude which you think makes you the greatest thing to smack the devs on the ass since the black turtleneck.

I am not a philosopher, but I’ve managed to destroy the world where I work<.

If we really want to evolve testing, if we really want to find something new it’s time to throw out the hubris and rip what we do down the studs, the bare earth, the beating heart if we’re ever to find answers to some of the hard questions that have dogged testing for years:

  • Why are we in testing?
  • Do we really care about the software? or do we only care about making ourselves look good on the software team?
  • Why is there such a love/hate relationship between devs and testers or even testers who write code and testers who don’t?
  • Why is it so easy for testers to feel ostracized on software projects?
  • Why do most testers not see themselves in testing in 5 years?

If you take away the tester, the dev and the software, what’s left?  In “The Neverending Story” this is when there is only one small, solitary grain of sand left.  I do think we’ve got a bit more than that.  At the end of the day, all of we’ve really got is being human.

Let’s get to the bottom where the beating heart lies and start rebuilding on something more solid than a job nobody ever wanted until they “fell into it.”  Let’s destroy the world.

 

Enhanced by Zemanta

Github WTF: Learn Some Github with Me Next Tues.

Github...wtf!!!!

In which the lady invites you to participate in a Github workshop on Tuesday, May 24th, 9:00a.m. PDT….world times here

My first month of working at Mozilla has slipped past without a sound on my blog.  That’s because I’ve been making lots of noise over in my github space. One of the software skills no one will ever, EVER tell you to learn but a skill everyone in software should know is how to use distributed version control like a Boss.  This post is an invitation to an online Github workshop I’m hosting next week and contains a few resources for those who can’t make it but would like to learn more.

I’m not a stranger to version control, but it’s always been something I approached timidly and with great care.  Since my first task is re-writing a bunch of selenium checks for addons.mozilla.com, I had to come up to speed pretty quickly on Github.  I’d been checking in bits of my own code prior to starting, but I had only ever worked with branches when I was pulling down code on subversion. Let’s just say I had to get it together pretty quickly.

Github is fabulous once you understand the bulk of it.  It handles code reviews, has diffs and provides great visibility.  Github makes it possible to collaborate with my co-worker, David Burns, who writes The Automated Tester blog and is based in England.  If you poke around in my github you’ll see comments both of us have made in the repository for Addon Tests.

Now that I know how painful it can be to spin up on Github, I’d like to spare others some of this pain.  To this end, I’ll be running a Github workshop during Mozilla WebQA Automation Test Day.  The test day is next Tuesday at 9:00a.m. PDT (World Meeting Times Here).  This will be my first Mozilla Test Day, so I’ll be learning what it’s about along with everyone else who shows up for the first time.

About the test day:
From what I understand, it’s an opportunity to collaborate with the team at Mozilla on some testing or, in this case, writing some selenium tests.  You’ll need a little, but not tons of programming experience.  All levels of experience at writing selenium tests are welcome.  Please read David’s post about it here.

The IRC channel if you want to go straight into writing selenium tests is irc.mozilla.org #testday

 

About the workshop:
I’m expecting to spend from 1 to 2 hours on this.  It starts at 9:00am-ish on the West Coast of the U.S. If you are in a different time zone, check this link. Everyone will work at their own pace so it should be very low stress.  Prior to the workshop, I’ll put together an example project we can use for getting used to the whole distributed aspect of Github.

If you would like start before the workshop, check out the github instructions for installing and setting up git.  I found them to be quite helpful for setting up on both mac and win7.

The IRC channel for the workshop will be irc.mozilla.org #expectpants

If I can get it sorted, I’ll post a transcript here after we’ve done the workshop.

Some Resources:

As I’ve been learning how to use github, I’ve been adding to my github cheat sheet.  Making your own cheat sheet seems to be a “rite of passage” for github users and there is no shortage of these.  I invite you to use mine, fork it or otherwise steal from it to write your own.

It’s very easy to work yourself into a corner in git.  When this has happened, I’ve turned to the Pro Git book. It’s available in the ever-awesome Safari Online (these people brought back html view for me, I <3 them).  I also got our manager to purchase a copy for our group.  I’m relying on it less these days, but find that when I need it, I really frakking need it.

Besides these 2 places, I search on Stack Overflow.

 

If I can’t find answers in these places, I’m down to getting creative.  Luckily, this hasn’t yet failed me.  I am by no means an expert at Git and Github, but I’m ok with them.  Let’s practice together :)

If I gave a lightening talk at the Selenium Conference…

Brisbane Lightening

Imagine that it is long ago in a galaxy far, far away, on a doomed planet.  You are a vulcan tester.  Unfortunately you have been tragically rendered a paraplegic.  Your rehabilitation as a paraplegic vulcan tester in a galaxy far, far away involves a virtual self in an automated testing environment.  This talk addresses evidence found in the “ark of truth” gleaned by paraplegic vulcan testers being rehabilitated by living through a virtual self in an automated test environment everywhere (come on, we all know how frakking ubiquitous this situation is.)

Truth #1;
Selenium IDE is like the People magazine of automated testing.  Everyone uses it, but nobody wants to admit it.  Not even Adam Goucher.

Truth #2:
Using a percentage in your prsentation slide is 602% effective as long it is large, flashing and contains absolutely no hard numbers to back up the claim you are making.

Truth #3:
Idea is so beloved that anybody who uses a text editor as lowly as Textmate, especially in their presentation will be shunned.  Let’s all have a group hug on this while Idea takes it’s sweet mother-frakking time to load.  Again.  Ok, now let’s all go get a coffee and give the bitch a few more minutes.

Truth#4:
The wisdom of Bret Pettichord emits from the cowboy hat.

Truth #5:
The Saucelabs awesome sauce will eat the copper off of a penny and cause an explosion if added to Diet Coke.  (Be the first to capture it on YouTube!)

Truth #6:
Betty Ford is launching an experimental twitter addiction rehab program and has scheduled an intervention for everyone sitting at the table of trouble.

Truth #7:
You can only have a lightening talk at the Selenium Conference if a. you’re Canadian b. you’ve already given a talk c. you’ve got pictures of cats.

Truth #8:
If 300 people show up…then Monday really *is* the first day of ur conference.

Truth #9:
If you put thread.sleep() in your selenium talk, you will get heckled.

Truth #10:
Don’t ask Simon to include anything in Selenium 2 or the answer will be no (especially if it involves Github).

Enhanced by Zemanta

The Selenium Conference: A Sort of Homecoming

The Golden Gate Bridge and San Francisco, CA a...
Image via Wikipedia

The past month has been all about suitcases for me, packing them with the stuff I absolutely can’t live without, weighing them, re-packing them, getting them checked in, getting some-but-not-all of them back from Salt Lake City, Utah.  (Yes, really.)

 

My suitcases and I have landed in Mountain View, California.  I am ready to get my head out of the suitcases and back into the testing community.  To do this, I’ll be attending the Selenium conference in San Francisco this week.

 

This will be the 2nd test automation conference I’ve attended.  The first was the 2008 Google Test Automation conference.  Up to then, I hadn’t thought of the scripts I was writing at work as test automation at all.  It was quite a wake-up call to sit in a room filled with extremely nerdy people who had very sophisticated ideas about and experiences with testing software.

 

I remember going home from GTAC feeling like my eyes had been opened and that I’d found “my people.”  In terms of my career path, I felt as if I had come home.  As I’ve just moved back to the U.S., I am expecting that the first ever Selenium Conference will also feel like a sort of homecoming.  I suspect that I won’t be alone in feeling that way either.

 

If you are attending the conference, please say “hi” if you see me in passing, poke me on twitter @marlenac, or leave me a comment.

 

It feels great to be home :)

 

Enhanced by Zemanta