Selenium SF Meetup: Tales From the Selenium Testing Trenches

For those who haven't seen it, and are in the SF Bay Area today, the San Francisco Selenum Meetup group will be getting together tonight. I'm setting the stage with this post, and I'll update it later this evening when the event starts so that those who can't be there can get a taste of what's happening.


So a static blog to set up a live blog for later... yeah, that's it :).


With that out of the way... Thursday, February 28, 2013 at 6:30 p.m. (we walked in at 7:15 p.m. and tamales were never so appealing, lot of traffic on 101 tonight, my thanks to my Quality Director for the ride up :) ):

Tales From the Selenium Testing Trenches

Lookout Mobile Security
One Front St, Ste 2700,
San Francisco, CA
6:30 p.m. - 9:00 p.m.
(map)

The first speaker is Giri Nandigam of TRUSTe about their Tracker Detection Tool and how Selenium has become part of their mix to test, develop and move forward. TRUSTe is in the business of protecting customer data, and to do that, they have to make sure that large amounts of data can be safeguarded, and that involves dealing with some huge systems. Their goal was to try to comb networks to look for data and verify that it is not being exposed. Their challenges that they were facing were having issues where JavaScript engines would throw too many errors, and trying to get systems that could be maintained in a realistic manner. Their idea was to use Selenium as a crawler, and to allow them to use Selenium to go from page to page, to collect all of the links (thousands of them) and then export out those links as HAR files for later access. Also, they've made a browser hack so that they can get access to the cookie store for requests (an interesting way to go about doing some protective data mining, to be sure).

These kind of talks are always interesting because we get to see what other organizations do with Selenium, and while we are used to thinking of Selenium and its framework to "test", it's a system for computer aided processing and step automation, and looking to see what data can be gathered.

Taking a little break, and nature calls, so I'll be back in a bit. Oh, and Ken got the last Tamale, if any are here and looking for more food ;).

---

The second speaker is Dr. Wenhua Wang of Marin Software, who will be discussion ways to use Selenium to test IE. Due to a lot of multi-browser needs ,and yes, a large customer that mandates IE7 as part of the support deal, IE is not going to be something I will be seeing less of any time soon. Marin has   lot of legacy code and the idea of creating new automation tests was and still is a daunting situation to deal with.

Also, many of their tests used XPath locators (sometimes very helpful, but often very expensive if not implemented in the right scope... hey, I actually understand what that last sentence means now ;) ). They decided that, rather tan start from scratch, they would see how much of their existing test code they could refactor, especially with the gains that WebDriver now gives to allowing an easy retrofitting of Selenium drivers, and instead of changing the testing code itself, use the time and energy to update and refresh the locators and methods to access them.

The big win and goal of these changes was to try to explore techniques that would minimize the code maintenance, plus allow for a maximum on the return of effort with the lowest overall cost. Developing automation tests with well supported techniques will help make sure that the churn of test change is minimal.

One interesting question from the audience was to ask "if you could do this all with no budgetary impact and all the resources necessary, what would you do differently"? The best answer came from Ken, who was sitting right next to me... "tell your developers to make sure that very element has an id or a class!" Frankly, I couldn't agree more!

I said I was looking forward to seeing Chris McMahon and Zeljko Filipin being in town for this, and sure enough, they came. I felt bad that I didn't have any time this week to get out and hang with them while they were in town, but this in a small way makes up for that. My thanks also to Ken for being my ride to the city tonight, and letting me take a much needed nap on the way up (that's a topic for another post, but not just yet ;) ). To all of my Selenium compatriots, good to se you again, and we get a treat in two weeks, another session at Pivotal Labs, this time to celebrate Elizabeth Hendrickson's in-print launch of Explore It. That will be on Tuesday, March 12, 2013, and I hope to see you there :).

TESTHEAD Giveaway: WIN a FREE Selenium Book!!!

And now for something "Completely Different"... and yet, not.

For those who have been following this blog for the past month, I've been working through "Selenium 2 Testing Tools" and doing a long form review of the exercises and materials. I also, last month, did a review of another book, "Selenium Testing Tools Cookbook", which is also available from the publisher of Selenium 2 Testing Tools, i.e. Packt Publishing in Birmingham, UK.

So why am I mentioning this? Because Packt Publishing is partnering with TESTHEAD to give away three FREE copies of the Selenium Testing Tools Cookbook!

OK, do I have your attention :)?

Here's some of the details about "Selenium Testing Tools Cookbook" from the Packt Publishing site:

• Learn to leverage the power of Selenium WebDriver with simple examples that illustrate real world problems and their workarounds.
• Each sample demonstrates key concepts allowing you to advance your knowledge of Selenium WebDriver in a practical and incremental way.
• Explains testing of mobile web applications with Selenium Drivers for platforms such as iOS and Android
• Uses a variety of examples and languages such as Java, Ruby and C#.

Read more about this book and download a free Sample Chapter

How to Enter

All you need to do is head on over to the book page (Selenium Testing Tools Cookbook), look through the product description of the book, and drop a line via the comments below this post to let us know what interests you the most about the book. It’s that simple.

Winners from the U.S. and Europe can either choose a physical copy of the book or the eBook. Users from other locales are limited to the eBook only.

Deadline

The contest will close on March 10, 2013. Winners will be contacted by email, so be sure to use your real email address when you comment (you can, of course write it as my (dot) name (at) emailProvider (dot) com). The winners will be chosen by a random number generator, and I'll only count people once, so no leaving a bunch of comments to boost your chances.

Please feel free to share this post with any and all who want to participate.

SummerQAMP 2013 Training Materials... Home Stretch!!!

Today, SummerQAmp put out a press release talking about what they are doing for 2013, and the fact that they are working with a number of organizations to "pre-train" the interns that will be participating this year. For the full press release, take a look here: 

SummerQAmp Embarks on Its Second Year to Create Internships at Leading Technology Companies in Eight U.S. Cities.

Of note is this:

"In addition, this year we are offering a more in depth online curriculum developed in collaboration with the Association for Software Testing, who is graciously providing the educational materials for students to sharpen their QA skills during the program..."
I want to say thank you to everyone that has taken the time and put forth the effort to help us develop materials and consider topics and provide details. A special thanks goes out to Smita Mishra, who single handedly (at least to date ;) ) took on the module about "What is the Software Development Process?"

Again, we are in the home stretch, but we are not out of the woods yet :). If you would like to help us get over this last hill and make our goal line on time (i.e. March 1, 2013) please head over to the EdSig Forum and weigh in with your ideas, on Bias, on Testing, on Context, on Software Development Process, or any other areas you think would be beneficial. Remember, our goal is "what did you wish you had known on your first day?" If we are not representing it, tell us, and tell us quickly :).

Podcast Review: How to Program with Java

During the process of working through the issues and question related to the PRACTICUM series I'm going through with Selenium 2 Testing Tools, I found that a refresher on my Java would be a good place to spend some time.

There are a lot of resources out there for those who want to learn about Java, and for some of us, there are different things that resonate. Personally, I like hearing a human voice, one that can coach you through areas that might not make obvious sense when you are working with them. Many podcasts start from the premise that you are already experienced, and that you are looking to hear special topics or more of a conversational podcast about the state of your chosen language. As an example, I enjoy listening to Ruby Rogues for this very reason.

For a choice to listen to and contemplate topics related to working with Java, I found "How to Program with Java" in iTunes. This podcast started in September of 2012, and roughly each week, Trevor Page puts together a podcast talking the details and the nuts and bolts about what Java is, what it does, and how to use it. The content is focused, it's easy to follow, and the coaching style helps a lot. Trevor takes the time to explain both simple things and those areas that are a little less simple to grasp. There is also a companion web site you can visit at howtoprogramwithjava.com that gives you access to other materials, as well as video tutorials and an E-book with exercises (those you pay for, but the podcast and other posts are free).

For those of you out there who want to learn a new language, and if Java is something you might see being part of your future, or you need to come back to Java after a long time away, Trevor's podcast would be a worthwhile listen.

Ya' Gotta' Commit

Yesterday I and a friend of mine brought some of our kids up snowboarding. I have long considered Homewood on the Tahoe West Shore one of my favorite places to ride, and decided it would be fun to bring us all there. For my friend and his son this had been their first time up in a few years, and might be their only time coming up this season. 

As we were hitting the various runs, I noticed that my friend's son was only riding on his heel side edge. This is common for many snowboarders. they learn how to ride generally straight, or they learn to break on their heel-side edge or slide down on their heels on steep slopes. For many snowboarders, this is as far as they ever get. I've gone up with some riders who have ridden a few days a season, and even well into their thirties and forties, they are still only able to go straight or go heel-side. 

As is often the case when I snowboard with friends, I cannot help but morph into a teacher (it's an annoying trait, I know), but I asked him why he wasn't doing toe-side turns? He shrugged and mumbled, and I suggested, if he was interested, that I could teach him how to do toe-side turns. It's really not that hard to do, once you get the technique down. I even offered to share with him my "secret sauce" technique that has worked with everyone that has ever tried it. He moderately agreed to give it a try, and with that, I went up the hill to an open run, and gave him the following piece of advice.

When we snowboard, the most critical thing we can do is keep the center of gravity right between the balls of our feet. To do this, I asked him to visualize how he would carry a 5 gallon water bottle, full, for a distance of 100 yards if he had to. Some smart-alec's will say "throw it on my shoulder" because they want to look macho, but most of us, when pressed, will likely say that we'll carry it right in front of us, with our hips helping to support the weight. This is the answer I was after, because if he could visualize how to walk while carrying this, he would realize where his center of gravity would be. 

I then asked him to flip over and stand up on his toe side edge, and practice doing the  exercise while determining just how much edge he needed to get moving and stop. For many of the people I've shown this idea to, they have been able to pick up on it in just a few minutes. In this case, though,  while he would momentarily get it, each time I tried to get him to go further, to commit to the turn, he would panic, lose it, and crash. His frustration would take over at that point and he would get mad, or punch the now, shout "I can't do this!" or some other thing. Net result, he came dangerously close to doing it, but at the last moment, he'd bail on it, and ultimately i just had to say "well, there's the technique". You know what you need to do. Commit to it and you'll get it." 

Sometimes the most frustrating things when it comes to teaching a new skill is getting over the "commit" phase. We know that we want to do something, we can rationally understand why it would be god to do something (rationally, we understand that linking heel-side and toe-side turns gives us much better control, lets us ride a lot faster, and cover much more terrain comfortably). Still, it's one thing to say it, it's another to really be wiling to tell ourselves "I'm going to make this turn, even if by doing so I'm going to crash, hit the snow, and it's likely going to hurt". Fact is, at that point, it stops being fun, and for many people, they would rather just stick with what they know rather than go into that "punishment zone". Making the decision to commit, and go through with it, no matter how hard, no matter how uncomfortable, no matter how scary, is a real leap of faith, and a real act of courage. Often, we get to the point where we master the goal, and we then say "huh, that wasn't such a big deal!" but leading up to it, oh yes, it absolutely is. 

This need to commit, no matter the price shows up in everything. It shows up when we want to learn new testing skills. It comes up when we want to code. It comes up whenever we need to branch out into a new technical skill or gain domain knowledge of any kind. We can have all the tools and all the techniques at our disposal. Sometimes, we can just walk the steps and presto, it's all good. Sometimes, though, there's a wall we have to go over, or around, or sometimes just punch through, and at those times, tools, techniques, skills, mentors, none of that matters. Those are the moments when we are alone with our own "lizard brains" and we have to make the decision, right then and there, to commit. If we do, we will likely come out the other side better for the experience. If we don't, we can go on as we already have. Either way, the choice is always up to us, but if we want the reward... "'ya gotta' commit!" 

Sometimes Simpler Gives a Greater Effect

As I've recently mentioned, I've been working with a friend of mine's son to teach him how to play guitar. We're very early on in the stages of this process, but already, I'm realizing that there are things that can be done to help get those "quick wins" to make it feel like you can actually make progress and keep excited.

I remember going through books for a number of years trying to make sense of what I was reading, and realizing that either the theory was over my head, or that the images being shown only told part of the story, and I'd obsess over those little bits. In truth, after I started listening to music and watching others play, I started to realize that there were a number of things that seasoned players did that were much simpler. While I was wracking my brain and my hands trying to master these intricate chords, most of the players I would see, especially in rock guitar, would usually play the chords they were hitting with just two fingers and usually just three strings. Occasionally, they would hit chords where everything would ring out, but more times than not, it was much simpler that it seemed.

I realized that most of the chords I was showing my student could also likewise be simplified a bit, and that there were two finger variations of most of the chords he could use, and they could be moved up and down the neck easily. This makes for a big win in that I can teach him real songs without the minutiae (that will, of course, come later).

We often get sidelined because we don't have enough knowledge to do everything. We get frustrated when we can't get it perfect. Let's stop thinking like that. Instead, let's see what we can do now, and let's see how effective we can be with a little bit first. Once we get our bearings, and we get accomplished, then we can expand our repertoire, but just like guitar, many of the efforts we get involved in can be performed with a lot less effort than we believe is possible. We just have to trust that a little can go farther than we think it can.

Tis The Conference Season!!!

It's almost March, when a young testers heart and mind, if they are so oriented and plugged in, starts to think about the upcoming Conference season and where they might go, who they might hear, and what they might say.

This year, I have decided to aim for three conferences. Two as a speaker, one as a supporting player, and I'll see if I can finagle one more if it makes sense and my company is cool with it.

First of all, for those in the Southern California area or those who will be attending STP-CON Spring 2013 (to be held April 22-25, 2013). I'll be there speaking on my experiences as a "Lone Tester in an Agile World". Actually, I may have to say that as an "Ex Lone Tester", as that's not my reality any longer, but I can say I certainly learned enough about what could be done, and most certainly what not to do, that it should be a fun and engaging session. My talk is on Thursday, Apr. 25, 2013, stating at 11:45 a.m.

The second conference is one I'd like to attend, and I've already made overtures as to how I can get a "crew pass" and work the show as a roving correspondent. Yes, I'm talking about the Selenium Conference 2013, to be held in Boston, MA June 10-12, 2013. My goal is to be a roving correspondent and create audio content that can then be distributed both at the conference or afterwards. The final decision still hasn't been made on this one, but I am hopeful. Either way, I'd like to see how I can be of service to this conference, and perhaps can package the materials to be available before the conference. Either way, I want to see this one success, and I want to be part of it one way or another.

I just received confirmation that I will be a full track speaker for CAST 2013, which is being held in Madison, WI, August 26-28, 2013. My topic for this conference will be how we went through and developed the (as of now) still baking content for the SummerQAmp initiative. What we learned, what went well, what went not so well, and the feedback that we have received along the way, both good and bad :).

That's what has been forecast thus far. as in all things plans may change, and I will likely look to opportunities that are weekend oriented and close to home, too. More on those opportunities as I hear about them. More to the point, I look forward to meeting as many of you as I can who can make it to any of these events :). 

PRACTICUM: Selenium 2 Testing Tools Beginner's Guide: Selenium Grid

This is the next installment (completed) of my PRACTICUM series. This particular grouping is going through David Burns' "Selenium 2 Testing Tools Beginner's Guide".

Note: PRACTICUM is a continuing series in what I refer to as a somewhat "Live Blog" format. Sections may vary in time to complete. Some may go fast. Some may take much more time to get through. Updates will be daily, they may be more frequent. Feel free to click refresh to get the latest version at any given time. If you see "End of Section" at the bottom of the post, you will know that this entry is finished :).


[Note for 2/19/2013: Compiler errors... no, that will not stand, man! I will get to the bottom of this... and I think I finally have. For those who are using Java 7 as your JDK, look towards the bottom, I discovered something that resolved our past compile problems, or at least, I think I have :). --MKL].

Chapter 8: Selenium Grid

One of the nice things I have noticed thus far with regards to the Selenium tests that I have seen is that they are relatively easy to change so that the tests can be run on multiple devices. The down side is that, so far, we have had to run them all one at a time, or switch things over to different servers, different bridges, and check them out one at a time. Also, tests are launched serially and run in order in the approaches we have taken so far. That's all cool, but is there some way that we could simplify things and just have one place we could focus our attention? The answer is "well, almost!"

Selenium Grid lets us set up a number of Selenium instances, with one central "hub" to send commands to. Selenium Grid routes the commands destined for a particular device or driver based on the configuration options and identification elements we create. While it's not an "all in one" solution, it's a nice way to go about gathering a lot of tests under one roof and varying the ability to test lots of different devices. First, though, we need to set up our environment to allow for a grid server.

Starting up Selenium Grid


Thankfully, this is an easy first step. We start up Selenium Server like we usually do, but we add a flag to it, like this:

java -jar selenium-server-standalone-2.29.0.jar -role hub

This will start up selenium server in grid mode (note, of course, use the version of selenium-server-standalone[x.xx.x].jar that you have, if you have a newer version, it should work the same).

And here's what your browser will say if you point to the server.

Cool, we've successfully started Selenium Grid. All looks good here. This is going to be the center point of our tests, and other Selenium instances will be reached from here. When we start Selenium Grid, we can see what options we have control over and which ones we can change. By passing in the port number (i.e. –port ####) We can use any value that we want (and have access to, of course).

By typing in

http://nameofmachine:4444/grid/console

we can see what environments are accessible (or at least assessible as far as the grid hub is concerned).

Unlike the Selenium Grid 1.0 version, 2.0 allows a machine to host multiple servers and allow access to multiple browser drivers.

Setting up Selenium Grid with a Local Server Node

This time, we'll look at starting up Selenium Grid, as well as starting up a second Selenium server.

Enter the following command in the apropriate location (note, the previous selenium grid command needs to be running for this to work. That's not directly mentioned in the book):

Start with

java -jar selenium-server-standalone-2.29.0.jar -role hub

and then run

java -jar selenium-server-standalone..jar -role node -hub http://localhost:4444/grid/register

You should see the following in your command prompt or console:

And if all goes well, this is our Selenium Grid display:

Nice! Looks good :)!

Setting up Selenium Grid With Remote Server Nodes

While having the grid running locally is cool, to really leverage the benefits of Selenium grid, what we really want to be able to do is run Selenium Server on multiple machines, and have those machine register their connections with the main Selenium Grid hub. The more machines we have that can do this (and the different variety of machines we use for this purpose), the more we can leverage the benefits of cross-platform and parallel testing. For this purpose, here's my setup with a second Darwin device and my Windows machine:

Each of the machines needs to be registered, and each needs to point to the primary grid hub, like this:

1. Make sure the hub system is running on my main Darwin system:

 java -jar selenium-server-standalone-2.29.0.jar -role hub

2. Set up a secondary local Darwin Selenium server instance and have it pointing to the hub:

java -jar selenium-server-standalone-2.29.0.jar -role node -hub http://localhost:4444/grid/register

3. Set up the second Darwin machine to run a Selenium server and register it with the first Darwin machine's hub:

java -jar selenium-server-standalone..jar -role node -hub http://74.51.157.191:4444/grid/register

4. Set up the Windows machine to run a Selenium server and register it with the first Darwin machine's hub:

java -jar selenium-server-standalone..jar -role node -hub http://74.51.157.191:4444/grid/register

Cool, so if we did that all correctly, we should have a grid with three registry entries... do we?

Indeed we do. Right on! So the key here is that we have the hub instance running, and with that, we can set up as many remote environments as we have machines. For our purposes, though, I think this will be sufficient to make the point.

Setting up Selenium Grid to dedicate OS/Browser Specific Tests

If we only needed to run on one browser and one operating system, this would be a much easier situation to deal with. In that case, much of Selenium Grid would be to merely provide for parallel tests and pointing to different instances of Selenium Server, all utilizing the same browser driver. While that's probably OK in some instances, most of us have to deal with situations that require a variety of browsers. More to the point, we don't have to just consider issues of browsers (Chrome, Firefox, Opera) in their own rights, we also have to consider the challenges of running them in a variety of Operating Systems (Windows, Mac, Linux, etc.) Even with Internet Explorer being solely on Windows, there are now multiple versions and multiple OS considerations (XP, Vista, 7, 8). Safari runs on Mac, and we haven't even started talking about Mobile yet! Selenium Grid, in a manner of speaking, gives us "One Ring (Hub?) to Rule Them All!" Well, OK, perhaps not all, but there are nine options that we can leverage at this point.

We've already seen that we can set up a base hub for the Grid, and use the -hub flag to point remote instances to it. We can use the -role flag to associate remote instances of Selenium server with our Grid hub. To get the browser level into the mix, we use a flag called -browser . The following command lets up set up a Selenium Server that registers with Internet Explorer specific options:

java \
-jar selenium-server-standalone.jar \
-role node \
-hub http://localhost:4444/grid/register \
-browser browserName="internet explorer",maxInstances=1,platform=WINDOWS

If this is doing what it's supposed to do, then we will have a Grid entry that only references Windows. That's what the book shows. My reality is a different story:

Not sure if that's going to make a big difference, but suffice it to say, we're running with the parameters the book told us to run. In our later tests, we'll see if they run correctly.

Using Selenium Grid 2 with YAML

YAML is a way that we can take commonly used data and encapsulate it into a file, so that the details we might want to update, or run with several instances, can be sourced from one place. Here's the suggested example for our YAML file (called grid_configuration.yml):

There are two different configuration options that are available. If you have Selenium 1 Gris servers (i.e. Selenium RC) and you want to run them along with the more up to date Selenium2/WebDriver servers, you can. Define the details you want to configure in the YAML file, and when you start up the Grid hub, give it the flag -grid1yml and the name of the YAML file, and you're good to go. 

 

A  quick look at the config options shows us our grid1yml file configuration options (note that we haven't created a grid 2 configuration file yet):

The key takeaway here is that a lot of the parameters that we would want to keep track of can be housed in a couple of YAML files, and that makes configuration changes quite a bit easier to track.

Actually Running Tests in the Grid

Up to this point, I have to say that my update speed has been very slow with this chapter. That's been a combination of work conspiring against me, plus some unusual issues with getting files to compile that made me decided that I had to get to the bottom of it. Through that process, i discovered that Java 7 requires a little more verbosity than Java 6 did. I could be wrong about this, but on the bright side, I think I may have found an answer to the issues of not being able to compile in previous sections.

First, let's talk running tests that leverage the grid. This is a simple example, simply because I decided I didn't want to fight multiple machines, multiple drivers, and multiple error messages just yet (hey, I'm having such fun with it, why shouldn't I let you all do the same ;) ?). But, to show that we are actually "gridding" it, here's a simple test that I put together to make sure that it goes to a particular location. In the example below, I have three servers. One's running on Windows, one's running on Linux and one is running on Mac. I want to make sure the test in question goes to the Mac instance. 

Right, so what's interesting about the above code? Glad you asked. As I was setting this example up, I kept getting the compile error "SetPlatform requires Platform, but found String".

This is so similar to all of the design pattern errors I was getting, I decided that there had to be a reason I'm seeing this. Additionally, I've gotten to the point that I couldn't believe that so many code examples were just not workable. I have met David, and I know he's way more conscientious about this stuff than to allow so many "mistakes". Well, what if it's not a mistake? What if Java 7 requires stricter type usage? As soon as I thought about that, and remembered back in my old C days that I could "force" a type casting to be applied, I started experimenting. In the process I came up with the following approach and change (note the difference between the two files):

Once we forced the type requirement, the project compiled! Not only that, but it actually ran the test to the specific server we wanted to have run it. Look below, the grid console shows the test instance being run. It's the muted firefox icon, and yes, that server is indeed the one running on my Mac:

Oh, and note... I finally got my Windows Server to declare itself an Internet Explorer only node, so yes, it's doable. I don't know what I did differently other than have the Windows version run the latest version of Selenium Server... hmmm, that might be it.

Summary:

Yeah, this section took a long time to get through, but on the plus side, I made a neat discovery, and that discovery may go a long way to solving a few other problems. Net result is that I'm going to go back and do some re-testing and re-coding of the previous examples and bring them in line with Java 7 realities. Seriously, I am ecstatic that there is a potential solution to all of the random compile errors, and if it's this simple, then there will be some easy changes to suggest to Packt so that they can perhaps make an update in the errata to reference Java 7 type conversion (or lack thereof :) ).

End of Section.

Michael Larsen, TESTHEAD

Wait... You're Not Supposed to be Here!

Since I've changed jobs, I am no longer commuting to San Francisco, but instead I am commuting to Palo Alto. Changing from North to South, from getting on the train in San Bruno to getting on in Millbrae, and of course, no longer getting off at San Francisco 4th and King, but getting off at the Palo Alto Caltrain station.

Having done the commute up to 4th and King for a few years, and making the same general walk, you start to notice things, and then those things blend into the background and you just don't really think about them any longer... until something shows up in a totally unexpected place. In this case, that something totally unexpected is a lady that I often used to see on the walk from 4th and King up to 4th and Folsom. She had a distinctive tan patchwork leather blazer that she would wear very frequently. Over a few years I'd see it and think "oh, there's the lady with the patchwork leather blazer"... and then, over time, I wouldn't think about it any longer, because it was just there. She walked the same commute path I did, and so, meh, nothing out of the ordinary.

Yesterday, as I got off of Caltrain, I saw her again. The same patchwork leather blazer. In Palo Alto. Huh?! It caught me by surprise, and at first I thought "naah, must be a coincidence". Today, as I got off Caltrain, there she was again. Same blazer, and as I would see, walking roughly the same commute direction I was going once again. This time, I had to ask (and run the risk of being considered some kind of creeper, but oh well, whatever):

"Excuse me, but did you used to work in San Francisco?"
"Actually, I still do, but sometimes I work down here in Palo Alto, too."

We had a quick conversation, and she told me where she worked and how the company has a number of offices, and she sometimes goes to San Francisco, and sometimes goes to Palo Alto. Not a big deal, really. After a laugh and some quick small-talk, we went our separate ways.

What makes this story, I think, somewhat interesting is that I was prompted to start a conversation because I noticed something "out of the ordinary". This is a person that I had seen for years on my daily commute, and never said a word to. Why would I, really? It's kind of odd for a married guy to approach some random lady on the street to start up a conversation (or maybe it's not, and that's just my traditionalism showing through). It took seeing her in a totally unfamiliar situation to cause my curiosity to get the better of me and have to ask. It all came about because, at that moment, my first thought was "hey wait... you're not supposed to be here!"

How often in our testing do we miss interesting pieces of information because, in our world view, they've just always been there. We've gotten used to seeing them there, and so they must just be part of the ordered cosmos, doing its thing. It often takes us seeing something familiar in an unfamiliar setting to make us "wake up" and do some inquiry. That's normal, and I'm not suggesting that we suddenly start automatically questioning everything we see, or everyone (for one thing, it's a good way to get people to consider you a class A nutter, and I already have to fight that depiction enough as it is). Still, when you see something out of the ordinary, it might be fun to check up and see what you discover. In this case, someone I've seen for years, and had zero interaction with of any kind, now knows who I am, and I know who they are.

That's kinda' cool :).

The Benefit of "Intern Fresh" Eyes

It's interesting when a story or set of stories comes together as a big mass, and just by their very nature, they are manually intensive. Just by the virtue of their design, they defy automation, they defy fast checking, they require the physical patience and calmness needed to work through them, one at a time, for a long as it takes. I'm living that dream right now (for some definition of dream ;) ).

Seriously, we have a lot of stories that just fit a similar theme, and to help get through them, I've been assigned my very own intern for the next several days. Nice! He's a good guy, and I'm happy to get some extra help for a bit. Today, we set things up and we worked as a pair for much of the morning. As I explained the rules of the road for the testing we need to do (this is accessibility stuff, so it depends a lot on hearing speech from screen readers and talking into microphones for dictation), it was interesting to see how he interacted with the product, what steps he took, what frustrated him, etc.

What I love about "fresh eyes" is the fact that, often, they do not have any paradigm to hang things off of. In testing, they don't know the rules of the road at all, and that's great. It lets me see how someone would approach a problem without even realizing the problems that are already there. As I am going through and trying to determine what aspects of testing to teach for SummerQAmp, these opportunities are great, because I can often see very different approaches being taken, some very much out of the realm of what I would do because I'm both experienced and, let's face it, a little jaded.

As we were working through some of the challenges, I found it interesting to see why he would go in certain directions, what interested him. What he would do to try to make things work if at first they didn't (which, with a tool like Dragon, is really easy to do).

A few years ago I wrote a post about Pairing with An Expert to help open your eyes to those areas you might not be aware of. Just as powerful is the opportunity to pair with a domain neophyte, since their "ignorance" is a valuable tool... they don't know the rules, so they can much more easily break them, and teach us something new along the way.