How did I get here?

At the Agile Tour here in RTP last Thursday (www.takebackthepark.com), I heard someone say to me, "Dawn, you are a natural speaker."

I specifically say "heard someone say to me" because it felt like exactly that -- it didn't sound like it could possibly be /me/ they were saying that to.

Who?

Me?

Uhhhh, here's how I picture me: I'm 6, at my house, and my dad's VP is coming to visit from California (I live in Jersey at the time). It's a big deal, mom has had us helping clean the house for a few days. The VP, Jim, comes into the house and introductions are being made. Me? I'm hiding behind my dad's leg, holding on for dear life, hoping against all hope that I will just disappear.

Me? I'm shy. I'm reserved. I'm the quiet one. I always see my sister as the outgoing, social one. I took public speaking in college, but even in front of just a few people who I shared class time with (summer class even!), when I got up to speak, my mouth went dry and my ears started ringing, and my vision was enclosed with dense white fog surrounding all but two small circles.

One more exemplary memory: Not terribly long ago, when I /really/ started hearing that I should be speaking at conferences, my son, Steven heard me talking about it. He was 12. He came to me, gave me a hug, and said, "Mom! Don't worry! Talking in front of people isn't so hard! I'll help you! We can practice together!"

Isn't so hard? HA! Who are you kidding?! It's impossible!!

It's a good thing I listened to other people. It's a good thing that as I heard person after person tell me I should speak, I should write, I should teach, even though that concept completely contradicted my own picture of my abilities, that I tried it anyway.

It's not terribly easy to accept that my own view of my own characteristics, strengths, and potential may not be the same thing that other people see. I sat in disbelief for many long hours, repeating to myself the words from other people ("Dawn, why aren't you speaking at conferences?" "Dawn, you have so much passion and energy! You would be great as a speaker!" "Dawn, will you come talk about that topic at the local user group meeting?").

Finally, I decided to jump. I came up with a plan to ease myself into it. First, I would talk at the local user group. The audience would be small, and it would be people I knew. Then, I would speak at a bigger, less familiar venue with someone else who had experience speaking (that way, I could pass off the parts I was having trouble with and learn from how they handled situations). Finally, I would begin speaking by myself.

Of course, life doesn't have the same plans for us that we have for ourselves.

I was presented with an opportunity to speak at STAREast this year (last minute, nonetheless). I took it, and spoke about a subject I was familiar and comfortable with. I did great! I've spoken several times since then, and it has gotten easier every single time. People told me that it would (chances are, people have told you similar things if you've thought about speaking and have been afraid). Really, it did.

I spoke at Agile Tour amongst such speakers as Jeff Patton, Andy Hunt, May Lynn Manns, and Laurie Williams. I am unspeakably honored to be in such company. I was excited and happy before my session, rather than nervous, anxious, and just wanting it to be over. I felt confident and comfortable and in my element.

My first public speaking engagement was right at 6 months ago, and I have no idea how I have gotten here from where I was a year ago. What I do know is that if I had not listened to those wonderful people who encouraged me, I would still be sitting here, telling myself that I wish I could speak, but am just too scared.

How *would* you test this?

So, I am using Google Voice as my voicemail these days. It's neat, and I like it, mostly. They offer, for free, a transcription service that sends me an email/txt message of what the caller said. Over the last 3 days, I've gotten calls form my son's middle school about him being absent (he is actually withdrawn!).

The beauty of this setup is that the tester in me LOVES certain characteristics of this test set. The call is an automated one -- in this case, I know that the caller is saying the *same exact* thing every time. The tone is the same, the inflections are the same, it's the same voice source data. However, over 3 days, I've gotten 3 different transcriptions from Google Voice!

The voice mail *actually* says this:
Hello. This is the attendance office at Durant Road Middle school, calling to inform you that your child, Steven Cannan, was marked absent today. Please send a signed note upon returning to school, explaining the reason for the absence. Thank you.

And following are THREE Google Voice transcriptions ... they crack me UP!

Day 1:
Hello, this is the attendance office ed to Ron corrode middle school calling to inform you that your child. Hey, it's Dawn Cannan was marked absent today. Please send a signed note on returning to school, explaining the reason for the absence. Thank you.


Day 2:
Hello, this is the attendance office and to Ron corrode middle school calling to inform you that your child. Jeanne cannon. You're a smart ass in today. Please send a signed note up on returning to school, explaining the reason for the absence. Thank you.


Day 3:
Hello, this is the attendance office at Deron corrode middle school calling to inform you that your child G intended You're a smart ass IN today. Please send a signed note up. I'm returning to school, explaining the reason for the absence. Thank you.

I *kind of* think they did the best job on the first day :)

But this brings up an interesting point for me, and it's one that I have encountered several times in my career as a tester.

Roughly, I can ask this question as something like this: How can you test something that is not feasible to prove, logically or mathematically, is *correct* every time?

I can think of so many examples where testing isn't cut and dry. I started working as a tester in a company that did software that processed genetics algorithms. How did we know that the genetics algorithms were correct? At that time, I started off by having all of my testers know how to do the algorithms by hand, so that results that weren't right would just stick out to them.

At one point, I was testing a search engine. I was lucky in this case to have knowledge of the source data in a database. One approach I took here was to find objects in the source data that exhibited certain special (and easy to identify) characteristics. Then, I could perform searches that I *knew* would return those objects and look for them early in the test results. But even then, I didn't really know that the search engine was performing correctly.

Recently, I read a set of slides by Harry Robinson, talking about testing Google Maps. Here's another good example: How do you test something that has multiple right answers, in such a way that you feel confident releasing it to customers?

I've given two approaches that I have used, but I'd like to know how others have solved similar issues. Please, let's talk, I'd love to hear more from you.

Are you the one holding you back?

I talked to my sister tonight. Like some other times I've talked to her, she was feeling frustrated at the walls that she has run into while trying to chase her dreams. What concerned me, however, was the tone in her voice that sounded like she had given up. She seemed to have decided that since she does not have a degree from a 4-year university, she was never going to be able to pursue the career she wants.

The conversation both made me sad and frustrated me. Although she has encountered some pretty big obstacles, I did not feel like they were impossible to scale. At one point, I told her, "Go get yourself some rock climbing gear, and let's get you over that wall!"

She feels like I don't understand how hard it is to not have a degree, because I have one. Maybe, she has a point. Though I know that when I am hiring, I don't even notice if my candidates have a degree. I look for skills, passion, pursuit of what they feel is right. I know that at least some others do the same.

I do, however, know what it's like to feel that the odds are stacked against you, and to feel like you might as well not try.

At age 19 I found myself single, pregnant, and a sophomore in college. The semester I found out I was pregnant, I was already struggling with a Biology curriculum. I had barely passed my first year and a half of school, and with a baby due in June, my spring semester was atrocious. I missed most of my classes that semester. By the time I asked for a medical leave, I had missed the deadline to do so by a week. That semester, I failed out of every single class and was placed on academic suspension.

After my son was born, I landed a temp job as a secretary for the Computer Engineering department at Clemson (where I had been attending classes before the baby). I worked for them for several months. When I started talking about going back to school, they were very encouraging of me. They encouraged me to go back and study Computer Science (because I "seemed to be pretty good with computers"), and they walked me through applying again. I was able to get the college to accept me back as a student, but as the summer before classes started began to fade away, my hopes for getting financial aid began to fade with it. I was told that I simply did not qualify for financial aid because I had been placed on academic suspension.

I had no money. I was a single parent, living with my parents. My parents had not saved for my college, so I had been relying fully on financial aid in order to go to school. Panicked, I thought this one barrier of money was going to stop me from going back to school.

(Edit from my original post because I realized I glossed over the most important part!)

(Let's pause here for a second. This situation looks pretty bleak at this point, right? I could very easily have stopped right there and given up. I mean, they told me, "Those are the rules, academic suspension = no financial aid when you come back until you prove you'll do better." Seems like a deal breaker to me. **That**, however, is the point of this post. I didn't let it be a deal breaker. I kept trying to go after what I wanted anyway. So, let's get back to the story....)

I really felt like the circumstances that lead to my academic suspension should be forgivable. I felt like they were pretty extreme and that I should still be able to finish my education and get the degree I wanted. I talked about it *a lot*. Apparently, the professors that I had been working with felt the same way.

All of the professors that I had been working with in the Computer Engineering department wrote letters to the financial aid department at the school. All of them made an argument to the school that the opportunity they gave me would be well worth it, that an investment in my future would pay off for the school in a shining star. I gathered several of these letters and took them to the financial aid department. I was shocked when they offered enough aid to get me back into school!!

My first semester back to school, I made Dean's List. Three and a half years later, I graduated from Clemson with a Bachelor of Science in Computer Science. I spent those three and a half years supporting myself and my son in a home of our own, working full time, and taking full-time computer science classes. My senior year of college included 7 comp sci classes and a physics class.

Me? I know barriers.

But I don't see them as showstoppers. They exist, and they are big, and at times I am really intimidated by them. At times, I don't think I can get past them. The truth is, sometimes I can't. Sometimes, "over the wall" doesn't work, but it turns out, if I scale the wall long enough, I can find a small crack that has crumbled enough for me to squeeze my body through. The point is, I just have to *keep trying*.

If I give up, the result will always be the same -- I definitely won't accomplish what I want. But if I try, and keep on trying, and look to others for ideas, something just might happen. Maybe it won't be exactly what I want, but maybe it will be better.

Building a test team ...

I told this story recently and was asked to blog about it, so here I am.

I have worked on several teams over the years, usually teams where I am starting testing departments from almost nothing, or revamping them from a place of failure to a place where they feel more valuable and are valued more. Frequently, I think back to the first major position I had out of college.

I started out during my senior year in college working as a part-time software tester at a bioinformatics company (software for genetics researchers). About 6 months in, I was given the opportunity to lead the testing effort (we had 2.5 testers) for a small turnkey project we had for a government agency. It was difficult, but I enjoyed it. When I graduated from college (about 11 months in), I was given the opportunity to hire 2 full-time testers and lead the QA team for the company.

My first 2 hires spent the first week or two in training (that I instructed) about the domain -- I taught them about bioinformatics and the algorithms that the software used (I did it because I loved it, but it was good for them to learn). There were maybe a dozen different genetic matching algorithms. At one point, my team was able to run the major genetics algorithms *by hand*, and knew *immediately* when some result set was incorrect.

Within about a year, I encouraged each of them to specialized in some aspect that interested them: the software itself, testing, the domain, etc. One of them enjoyed unit testing, so she did that. Another was interested in the back-end processing so he focused on that. Each of them also focused on specific types of algorithms.

We met regularly to teach each other what we were learning. Each "specialist" would give some sort of presentation to teach all of the other team members what we all needed to know to be able to effectively test. As new developers came on, they lacked the domain knowledge to understand *why* something was wrong. I was proud to see my test team able to understand the problem deeply and be able to explain it to the development team.

Before long (about a year), it became time to hire 2 more testers. Once the new hires came on, my existing team members helped to teach the new hires about the domain and the algorithms. The company had expanded the systems that it supported to 5 platforms for the client and 3 for the server. We maintained large whiteboards across the QA "hallway" to coordinate with each other on configuration management and testing efforts (in the days before I spoke words like "big visible charts").

At one point during this time, my software development lead conducted an experiment on us -- he purposely inserted 5 issues into a build and we had 2 days to knock away at it. We found 4 of those 5 issues in just 2 days.

In general, we struggled with test automation and never quite got it to work (though I became intimately familiar with WinRunner and TestDirector). We got offended when we were reprimanded for talking to each other too much (I valued that then, just as I do now). We communicated with each other via big whiteboards that let us know what everyone was doing at any given time and how it was progressing. We talked through test techniques with our dev leads, who were incredibly skilled people.

Looking back, at the time, I thought we were doing so many things wrong. In hindsight, however, we really were doing a *lot* of things right, and I am proud of that team.

Hiring misses: When we turn someone down for the wrong reasons

Filtering through hundreds of resumes can be a daunting task. Some people use recruiting agencies to help them filter the obvious misses, some go through all of them manually (I tend to fall into the latter group). Since I've recently been filtering through resumes again, I am reminded of a time when I learned first-hand just how much I missed out on when I didn't hire someone for something that today, I would find fairly minor.

It was 2007, and I had just gotten a job with a local nonprofit, starting their QA department from scratch (they had *zero* testers before me!). I sat across the cubicle aisle from a guy, let's call him Steve. Steve was a DBA, somewhat systems guy, overall smart guy. On my third day, we were all across the street at the pool hall playing pool at lunch time, when Steve finally decided to out me. He looked at me and said something like, "Okay, I waited until your third day. You don't recognize me, do you?"

Panicked, I am sure that I spent a few seconds (felt like minutes), trying to figure out who the heck he was. Why should I recognize him? ("Oh jeez, did I go on a *date* with him?!?!")

Finally (out of sympathy for my obvious flailing around a bunch of people I'd only known for 2.5 days), he said, "You interviewed me at (company x). Obviously, you didn't hire me."

WHAT?!?!?! I interviewed this guy and didn't remember him.

I said, "Oh, God, please tell me I was at least courteous and professional with you about it." (Not that I would be anything but....)

He laughed and said that I had been (Thank *goodness* for that!), and that he had been lacking in scripting skills. There was much joking about the incident for a while (I told him he was lucky, that I had done him a favor, that the company had since gone under.)

Over the next year and a half, I had the opportunity to work closely with Steve. I got to know the way he thought about the world, the way he approached problem solving, the way he thought through everything that he did, and the pride he took in his work. We spent many long hours and late nights working on problems together. We had a blast doing that, of course -- calling in pizza, having fun, coming up with private memes ("red is bad, makes angry grr"). It wasn't long before I realized just how dumb I had been for not hiring him when I had the chance. To this day, I'd sacrifice a lot to convince him to come into testing (he likes this DBA thing), and I'd hire him in heartbeat, without hesitation, any where, any time.

And I didn't hire him because he didn't have enough experience with scripting (something I could have taught him in a few days, likely....).

I realize that it's probably rare that people end up later working with someone they chose not to hire after an interview. Even rarer, I think, is compounding that with learning that they would have been a *fantastic* hire.

To this day, I think very carefully about what skills I choose not to hire over. I talk a lot about looking for the "testing mindset", and I feel that there are very few skills I cannot teach someone in a reasonable period of time. In fact, when I think of the kind of people I look to hire, their inquisitiveness and desire to learn usually mean that they can learn technical skills in a fairly short time (certainly a lot shorter than trying to teach someone with all of the technical skills I need to be inquisitive and have a desire to learn!).

Executable Specifications using FitNesse and Selenium -- STAREast 2010

At STAREast 2010, I presented a session called "Executable Specifications using FitNesse and Selenium". To set up the system I was using, you will need 3 pieces:

• The sample blog engine as the application under test
• The FitNesse files (here, these contain SeleNesse for convenience)
• Selenium RC server

Optionally, you can find my slides here

In that talk, I used a sample set of english-readable tests against a locally installed Microsoft blog engine, available via the Web Platform Installer. This was the application under test.

Blog Engine .NET Web Platform Installer

Below please find a link with a zip file that contains the directory structure with all of the FitNesse and SeleNesse files needed. To begin investigating, download the zip file and extract it somewhere that you can find it.

Executable Specifications using FitNesse and Selenium

Then, open that folder and execute the "runFitnesse.bat". In the resulting command prompt window, you should see the following:

FitNesse (v20091210) Started...
port: 8080
root page: fitnesse.wiki.FileSystemPage at ./FitNesseRoot
logger: none
authenticator: fitnesse.authentication.PromiscuousAuthenticator
html page factory: fitnesse.html.HtmlPageFactory
page version expiration set to 0 days.

That will tell you that the FitNesse server is up and running. The most common causes of trouble are the JRE version on your machine (make sure you have 1.6+), or the port that FitNesse is starting on. If that appears to be the case, edit the runFitnesse.bat file and change that port number (8081 might work, for example).

As soon as the FitNesse server is up, open up a browser window and enter the following URL: http://localhost:8080/.

That "front page" will also direct you to download the Selenium server -- my favorite way to take care of this is Sauce RC, found here: http://saucelabs.com/downloads. It makes running the Selenium server dirt simple.

The FitNesse front page has a brief description of the system and how it runs. The "TestBlogEngine" link will take you to the tests themselves.

For further exploring, the FitNesse and Selenium systems have established communities for support and learning. You can also follow the SeleNesse project, and join the user group to learn more.

I am more than happy to help with any questions or trouble setting this system up. It can be confusing or overwhelming at first. I would suggest starting off on the examples that exist and making small modifications to learn how the system works.

Selenesse dotnet is GO

Selenium + FitNesse = Selenesse

Chris McMahon and Marisa Seal took on a new project late last year, maintaining and extending some work that Gojko Adjic had done for FitNesse, called WebTest. They named it Selenesse. Selenesse combines the FitNesse wiki format and framework for defining and executing tests, with the UI browser driver, Selenium.

When I first found out they were doing this I thought it was neat and could use it myself. Since they work in the Java space and I work in the dotnet space, I decided that I could contribute to their project by doing a dotnet version, so that myself and others in the dotnet space could use it and extend it as they needed.

It was particularly interesting to me for a few reasons. I am a big fan of the wiki format for test writing and execution, first and foremost. I usually write my Selenium tests in a C# Nunit class, meaning that what the test is *doing* can be somewhat difficult to shake out (even with DSLs, we're still talking about code). Certainly, my developers can get through that, but nobody outside of this team can.

I am looking forward to involving my current team's business-facing people more in our software creation process. I believe that one step toward that is to work closely with them on defining what they want and at what point we can feel like those things are "done-done". I hope that by writing tests in a format that they can read, I can quickly walk through as many of the things that will represent "done-done" as we can -- and do that early and frequently.

So I took to writing the dotnet version of Selenesse. I struggled for a while and nearly gave up on it. The structure of what is being done basically looks like this:

Selenium RC dotnet client driver <-> SlimSeleniumDriver <-> FitNesse

I was able to call any method that existed in SlimSeleniumDriver, but not the native functions in the Selenium RC dotnet client driver. It was weird and frustrating, and no matter what I did or how I wrote it, I just couldn't get it to work.

Enter Mike Stockdale (@jediwhale) to the rescue! Mike has written fitSharp, another dotnet version of some FitNesse functionality. Selenesse dotnet uses fitSharp. It turned out, my code was just fine, but there was apparently some weirdness in file locations -- I placed the Runner.exe file in the same folder as my dlls and suddenly, it worked!

So, I introduce Selenesse dotnet. Click here to download all of the source (this will change as we get more organized). Go into the dotnet-selenesse folder and you will find the FitNesse wiki root and the src folders.

Not included in that package is the Selenium RC Server. I use Sauce RC (highly recommend it!!). To execute tests, the Selenium RC Server must be running.

I'll not get into more detailed instructions here -- look out for them in the download itself. There are instructions from Marisa and Chris's initial implementation in the wiki already. These will evolve over time. In the mean time, please feel free to contact me for help if you want to get set up and are confused or are having issues (setting up seems to always be difficult for me).

What? A 12-year-old at Agile Coach Camp?

Yep.

And it was amazing.

Why would I do such a thing as bring my 12-year-old to Agile Coach Camp?

Well, in all honesty, it was part laziness on my part at first. But it turned into so much more!

A colleague and friend, Catherine Louis, suggested to me 2 hours before registration started the first day (registration was 4pm on a Friday), that I go ahead and bring my 12-year-old to this first night of Agile Coach Camp. It was much more informal and social, she pointed out, and it would be easier for me. So I did.

He was a hit! He adds (usually, and here as well) a bit of humor to many things that I do. We went through a series of lightning talks on Friday evening that largely turned into individuals talking about their position papers and what they had hoped to get out of the weekend. I was triggered to get up and talk after a "development manager" spoke, since it was exactly that role I had come hoping to learn better techniques for dealing with. As I stood up talking, I said something along the lines of "If you know me, then you know I have a habit of being blunt and sometimes pissing people off." It became quickly apparent to me that my 12-year-old had done something funny, as the room erupted in laughter. (Yes, he had: he raised his hand in a "Yep, like me!" gesture).

As the group was breaking up for the evening, a few people approached us and asked Steven to return the next day.

My motivation for allowing him to come the second day was somewhat selfish (enabled by others asking for him to come back): I want for him to learn "how it's done" in the real world. I know that many of the topics are above his head (but what can the exposure hurt?). I want him to see the mechanics of people working together, thinking together, learning together and enjoying it, following their passions and communicating with respect and open minds.

Undoubtedly, he got all of that out of this weekend and more.

What I *wasn't* expecting was the impact *he* had on the other attendees! So many people approached me about his being present that it was almost overwhelming. He seems to have touched the hearts of a few people and inspired others. I saw someone (eek! What was his name, again?) else bring their daughter on Sunday! It was contagious ....

People *asked* for my 12-year-old to talk to the group as a whole. They encouraged him, they praised his behavior, his openness, and his "hacking" skills.

Driving home on Saturday evening, I got to listen to him describe how he felt less nervous after meeting all of those people, hearing what they said to him, and even talking in front of all of them. JACKPOT! What I was watching was a young adult gain a little bit of self-confidence.

I believe there is no greater gift.

Thank you, to all who attended Agile Coach Camp. I apologize if his presence was a negative experience for anyone.

Oh, and I am grateful to Mike Cottmeyer for walking with him down the path of "hack my iPod", a phrase I am certain to hear ad nauseam over the next few months.

You never get a second chance to make a first impression .... or do you?

I absolutely have to blog about this. For most people who attended Agile Coach Camp in Durham, NC this weekend, you are likely already somewhat familiar with this story, but I think there is a *really* valuable lesson worth sharing here.

I'm going to tell a story. When I have permission (assuming I get it), I will reveal the identity of the person in the story. I want to, if he'll let me, because I would like to be able to publicize what he's doing in the future.

At a conference last year, I had the opportunity to attend a TDD clinic. We were pairing in this clinic, and I ended up with two partners: someone I had never met or heard of -- let's call him Joe -- and someone I had really been wanting to meet -- let's call her Sarah. I found myself in a triangular-shaped pair, one of three very strong-willed people.

The experience was not a good one, for anyone involved. I'm not a developer anymore in my day job, and I only felt like I had so much authority. Both of my partners were developers, and I quickly found that Sarah and I had very similar ideas of what pairing should be like, but that was *very* different than how Joe paired. Sarah and I felt like our opinions were not being heard, and that Joe was trying very strongly to dictate to us exactly what should be done, down to exactly what words I should type. I can say that at one point, sitting in the middle of the two of them, I literally had Joe say "Type this" and Sarah say "No! Don't type that!"

Hopefully, I have gotten across that this was not a positive experience for any of the 3 of us. During a break, Sarah and I managed to find a friend -- let's call her Kathy -- and she agreed to come into the session and work with Joe, so that Sarah and I could work together in a way that was more comfortable for us. Certainly, this felt like the cowardly way of (not) dealing with the issue, and part of me wanted to address it directly, but I didn't get there.

In all honesty, I have not thought terribly much about this situation since that conference. I told the story to a few people at the conference, but not since. I had simply marked Joe off as someone I had a personality conflict with and would not want to work with.

So, why would I tell you today that Joe is now literally in my top 10 list of my absolutely favorite people? If given the opportunity, I will work with him in a heartbeat.

I believe that this example shows the power of an open mind, and the power of not judging people based on a single experience (obviously, this applies in both directions).

I arrived at Agile Coach Camp Friday night, registered, and made my rounds. Headed over to the bar, and who do I see? Well, there is Joe. At some point, I had seen his name on the roster and thought "this should be interesting, but I should be able to just avoid him". I don't think we were a whole 5 minutes into hanging out when the topic of our experience at the conference last year got brought up- by him. He set the tone flawlessly, by indicating that he knew me through a negative experience that had been traumatic, though largely his fault.

Let me just say, I really don't care to point fingers at or lay blame on anyone, so I do actually tend to struggle with someone who has just pointed a finger at themself.

He then put the ball in my court to describe the situation. I tried, as best I could to describe what had happened in a fairly diplomatic way, saying that we were in a situation where our different styles of pairing conflicted with each other. I did take my description a step farther, however, and described for the table how he had dictated to me exactly what to type.

So, here it was, this elephant was on the table, had been exposed, laid out bare. I was *incredibly* impressed with his humility. It really contradicted the arrogance I had seen in him last year. I appreciated that we both got to laugh about the experience. I learned a side that I had not known as well. I heard about how traumatic it had been for him (which also contradicts the arrogance I had seen), and the circumstances he was in at that time. I heard the stories that others had told him of what I had said. Honestly, I had no considered that it had upset him; he had seemed pretty oblivious to it at the time.

So I spent Friday, Saturday, and Sunday with an open mind. I watched him and interacted with him as if I had met him for the first time this weekend. The more I saw, the more I not only gained respect for him, but wanted to talk to him and share and learn from him.

I saw a person who is clearly fantastically passionate about what he is doing -- coding, refactoring, or teaching. I saw someone who has a wealth of knowledge to share, so much so that at times, you can almost watch it bubbling out of his ears. I saw someone who really *does* know what he is doing, inside, outside, and around. I got a taste of just how much I could learn, and just how parallel my passion and recent path is to many of the things that he has been doing as well. I bounced ideas off him for ways I can contribute to my community, and learned through discussions with him that things I thought I knew, I don't. He is aware of and describes his own weaknesses without hesitation.

In closing circle (this was an Open Space conference), we each talked about our experience at the camp. I sat in my seat, ready to describe the transformational experience to the group (by that point, a few people had heard the story). I was proud of myself for keeping an open mind and not letting the first experience cloud my view of him through the weekend. I was grateful that he did the same with me and was open to addressing the experience directly and had also been open to not judging me. I was grateful that I had not missed out on the opportunity to connect with another person in software who is clearly passionate, smart, and has a lot to offer. As I waited for my turn, he got up to tell the group about his experience this weekend.

Whaddya know, he told this whole story, in much the same way I have now. He said, "They say you never get a chance to make a first impression. Well, maybe sometimes, you do."

Joe, I look forward to working with you in the future and contributing to this community as a team.

How to handle the Windows Authentication pop-up with Selenium RC

For the first pass at this post, the scope is going to be pretty narrow. I'm going to try to use terminology that makes sense, but it may not be entirely accurate. I think that when I was trying to solve this problem, it's part of why I struggled.

I was working on a Selenium script for a newly built internal QA web site (yay!). When I go to this web site, however, before the web site loads at all, I get a little modal dialog box that asks me for authentication:

Well, Selenium has no capability for dealing with this box. I found, after much searching for terms like "selenium authentication", that putting the username and password into the URL was not going to help me. I have come to learn that that kind of authentication is called "HTTP authentication". If that's what you need, you should be able to solve it via this Selenium FAQ post: Selenium and Basic HTTP Authentication

I tried it, but it did not help.

It turns out, what my site was doing was a form of Windows-based authentication. And, as it turns out, it's not something Selenium can take care of at all. If hard-pressed, you can use something like AutoIT to script that part out. I don't yet need something that robust, so I decided to go with simpler solutions. I did find this great post from Atlassian blogs about writing a Selenium Container to deal with Windows Basic Authentication.

In any case, for the time being, I have created a Firefox profile just for use with Selenium, and then have told the Selenium server to use that profile, rather than creating a clean profile every time.

So how do ya do that?

Start by creating a Firefox profile. How to do that is actually pretty well documented here:

Mozilla Support: Managing Firefox profiles

I should note here also that I have seen it recommended that whatever profile you create here should be in a different directory than the default profile directory that Mozilla uses. I did do that, for easy access, at the very least.

There's a really great blog post here, about some other profile configurations that can be made to optimize automated testing. There are some great settings in there that will save you heartache.

Once I created a profile that I intended to be used for Selenium, I started Firefox under that profile. In order to have the authentication dialog stop appearing, I had to go into the configuration for Firefox and tweak a few settings:

In the URL bar, type "about:config"

Tell it yes, you'll behave, and then you see a long list of configuration parameters. In the Filter box, type "ntlm".

You'll see 3 entries ... we care most about the "network.automatic-ntlm-auth.trusted-uris" one. In this one, type the server names that you want to stop this behavior on. For me, I just typed "qa1,localhost" (qa1.domain.com is my test server).

The Atlassian post above indicates that you should also change the "network.ntlm.send-lm-response" to true, so feel free to do that, too (I didn't and it still worked for me, so ..... just try it and see what works?).

Then, you've got this profile ready to go. So the next thing is to tell the Selenium server to use that profile. When you start the Selenium server, pass it the following parameter:

-firefoxProfileTemplate "path-to-profile"

As a matter of preference, if you're not using Sauce RC, I'd highly recommend it. You can download it for free here: Sauce RC

It will run your selenium server for you, and has a convenient "Preferences" page where you can put in the parameters you need. If you're like me, you always end up getting stuck on some dumb syntactical issue and pulling your hair out. This saves my hair, and maybe yours, too.

For the record, I am aware that I didn't cover IE or Chrome, or any other browsers. It's just because I haven't gotten to them yet. I will post about it when I do. Also, I'd love to hear your feedback if you try it and work through any other details or complications. I'd like to make this post as robust as I can ...

TEDx is awesome!

Oh boy! I have been missing out! I hope that I can make sure that other people I know don't miss out, too, by telling everyone who reads this about the TED conferences.

Just a few months ago, I learned about the TED conferences. I'm pretty sure I heard about it through a friend on Twitter who was going to one, and the more I looked into it, the more I loved the videos I found on the website. So, I started watching the videos, usually downloading them and sticking them onto my iPod to watch whenever. At some point, I found a few videos that I thought my son, Steven, would like. Turns out, he did: Gever Tulley, Sir Ken Robinson, etc.

So TEDx is just locally organized events carrying on the spirit of TED. I was so excited when I found out that there was one being organized locally. This one was called TEDxTriangleNC, and I am only sorry that I did not get involved in it sooner. It lived up to my expectations and then some.

I should say early that I brought my 12 year-old, Steven, with me. There's a story behind it, and if you want to hear it, just drop me a line, I'll be happy to tell it! I wasn't entirely sure of the speaker/topic list beforehand, but I wanted him to go to one of these inspiring and thought-provoking conferences. Steven was a hit, as basically the only young adult (I don't think I am allowed to call him a child any more!) in the audience. Zach Ward, the MC, caught on to him pretty quickly, and even had him read the lunch menu and acknowledgment.

The early set of talks on technology were particularly fun and relevant for me. Andy Hunt gave a great talk on sketching for mind mapping, basically. I hoped that it spoke to my 12 year-old, because he struggles with remembering stuff :) I was excited to see him talk because as a technical (and passionate!) tester, I certainly know his work, and knew he lives locally, but have never connected with him.

I have to say, though, I was on pins and needles, the hair standing up on the back of my neck, when one guy gave a talk titled, "Where are the fathers?" Here I sat in the audience, next to my 12 year-old son. A child who has basically never known his biological father, a statistic that I have fought since the day I found out that I, at the time a sophomore in college living with her parents, have fought since the day I found out I was pregnant. Here he presented a slew of statistics: most people in jail grew up in fatherless homes, most drug addicts grew up in fatherless homes, a dozen or more of these. "Where are the positive statistics?" I wondered, while I sat, watching my son intently. He later said it was his favorite talk because he could relate to it.

Hugh Hollowell, of Love Wins Ministries, gave a talk about the chronically homeless, and their lack of relationships, that both stuck with me and gave rise to many questions from me. Luckily, I had the opportunity to find him at the after-party and talk with him.

There was also a woman who read a poem she wrote after a horrifying near-car accident, where a car slid across the highway in front of her several times, with her own children and another's child in the car with her (geez, I can't remember her name!). David Beaver talked about the "Overview Effect", experienced by only those people who have the ability to see the Earth from space, and just how minimizing it is for their perspective of our day-to-day issues.

Funnily, I also got to connect with the group of people organizing the local Pecha Kucha night, here in Raleigh. It was great, because I had sent an email and volunteered mine and Steven's services for whatever they needed, and when one of the ladies heard me talking, she realized that I was the person she had been exchanging emails with! *THIS* is a *fantastic* group of people, and I am so excited to have met them, and I look forward to building relationships with them from here on out.

In short, I have decided that I absolutely LOVED TEDx because of this: it exposed me to people who are *passionate* about *something*, most of them involved in things other than software development. I love my software development community and connections there, both remotely and locally, but it was a really amazing experience to have a day to spend with other people who are just *passionate*. I feel like we run into many many people all the time who are just going through the motions, and I feel like finding others who have a passion and follow it is the exception, not the rule, unfortunately. At TEDx, I got to find a *bunch* of these people, and I am exceptionally grateful for that.

OH! I should mention one other thing .... in bringing the token young adult, I got connected with Ashley Cooper, who lives in Asheville, NC, but who is organizing a TEDx *youth* event out there. Of course, I gushed about what an awesome idea I thought that was, and just how much I loved that TED was reaching out to young adults. Before I knew it, she was introducing me to others as the "person who is organizing a local TEDx youth event here in Raleigh!" It makes me chuckle, but seriously, I am going to do that. I am scared out of my mind that I won't have what it takes to organize this, but I *so* want to see it happen. I really think that kids should be seeing these types of things and getting involved, and I look forward to being a part of that locally. If you want to help, *please*, *please* let me know ... I've got a couple of people who have volunteered, but will need plenty more.

Testing Legacy Apps

I'm making my slides from my talk today available here for all to see and slam. The slides themselves are fairly content-sparse, because I really do hate having a bunch of text on slides when I'm talking. People try to read while I'm talking, or I read text that's clearly on the slides, neither of which seems productive. So the slides are clipart-heavy. In addition, however, I am also going to post my mind map from when I was creating this presentation.

The basis of the presentation centers around my most recent few years of experience: how to handle targeting a test strategy on a legacy system. I've seen a surprisingly large number of companies that either "go agile" after having only manual testing for a while, or companies that have been around for a while and just never had a test team at all.

In these cases, trying to create a test team or convert a team of manual testers to more "agile" testers, often times while the whole organization is transitioning, is an incredibly daunting task. Personally, I've gotten overwhelmed at times with all of the things that need to be done -- how do you automate when there's still all of those manual tests to be done? My presentation relies heavily on the expert advice (via books and blogs) from Mike Cohn and Michael Feathers. In any case, here are the slides and the mind map (in pdf format).

Please provide feedback .... I think this is a talk I may try to give more often, and would love to ensure that I have the most broad base of input I can get. Thanks in advance :)

Testing Legacy Apps Powerpoint

Testing Legacy Apps mindmap (pdf)

Welcome to the virtual Agile world!

So, today I gave my very first conference presentation. It was really my first presentation outside of my own team or business scope. I gave a talk on "Testing Legacy Apps" with a high-level strategy for how to tackle organizing the testing effort for a legacy (read little to no automated test harnessing) application. I've been on teams undergoing this effort several times in the past few years. Sometimes, it's a company that has never had a test team at all. Sometimes, it's a company that has had testing, but all testing was done manually and there was no automation at all. (In this case, by "automation", I am talking about things like unit tests, automated GUI tests, and/or all of the computer-executed tests in between.)

In any case, the point of this post is to talk about SecondLife, which is where I gave my talk. SecondLife is a virtual world, where people are represented by avatars, and they interact with a virtual world, created by others in that world (or themselves). I've said that I was giving a talk in SecondLife many times in the past few weeks, since AgileBill4D (Bill Krebs) asked me to speak.

The response is always the same facial expression. The look that says "Ohhhhhh, you're living an alternate, orgy-filled, sexually deviant life on the side, eh?" Being me, I do tend to launch immediately into the defense of SecondLife, now that I have been in it. I have to admit that when I first met Bill and he talked about SecondLife, I thought the same thing. But over time, his description of what he was doing in there have kind of grown on me. Let me tell you what Bill is doing there in SecondLife.

Bill has created an entire area in SecondLife for Agile training. He uses the space to hold training classes around the world, where he can create a space that looks much like an ideal immersion space (I'm thinking Agilistry Studios, via Elisabeth Hendrickson). Without having to spend money to travel to client sites around the world, he holds classes in SecondLife and teaches the concepts of agile. With a headset, he can talk as if on a conference call, or even an individual phone call (as if through Skype). With the ability to converse and share things in the virtual world, he can even pair program with someone sitting anywhere else in the world!

This picture shows my SecondLife avatar, TestyDawn Darkmatter, in front of a scrum board at the Agile space.

If I understand correctly, in the text chats, there is a translator available, so that the two people speaking don't even have to be typing in the same language! The translator will translate between the languages, so that each person can type in their native language. I can imagine that this would really help with some common cross-language communication issues!

I understand that some colleges and universities are using SecondLife to teach classes, too. It seems like it's much like the distributed learning classes that I have seen in webinar format, or like GotoMeeting. Since SecondLife offers both text and voice chat, classes can be held to a broad audience. Something I heard today that I had never thought of was that people who are deaf can still participate through the chat portion. It really was great to realize that this virtual world was not limiting to people with disabilities.

The conference looked much like any other small to moderate sized conference. There was a large room with many rows of big blocky black chairs, and a HUGE screen in front. There was even a podium in the corner for the presenter to stand near, all real-life-like.

In preparation for the conference, I became accustomed to how to navigate through SecondLife. It takes a bit to get used to the movements for my avatar versus controlling camera angles and views. You can zoom, pan and tilt the camera in order to get a better look at things. It takes a few hours to get a bit used to it. Someone has also asked me about customizing the avatar, and I'd like to address that as well. When you sign up, you choose a generic avatar to represent you in SecondLife. There are free things you can pick up to customize that avatar, and there is a whole component built in to change the appearance. The appearance covers the actual avatar body -- things like skin, hair, eyes, body type, etc. It reminded me of the Sims, honestly. Then out in the world, you go and find (or buy!) clothes, maybe hairstyles, jewelry, shoes, accessories, etc. This is something that you can spend as little or as much time on as you want to. I did spend a few hours shopping for some professional clothing in order to give my talk.

After a hard evening of shopping, I spent a little bit of time relaxing by the campfire. The crackling of the fire sounded very relaxing.

I am sure that there are places inside SecondLife that are not things I want to see or people I want to interact with (tho I bet it would help if I could find a skirt that actually covered my avatar's tush!). I can say that I have not run into these places or people. I have kept to the Agile space and Rockcliffe University (next door, I think) for the most part (other than clothes shopping), and there is a lot of neat stuff in those places.

As far as giving the talk went, I bet it was very similar to giving an actual talk. I think the major thing I noticed (that made me nervous), was that I couldn't see anyone's facial expressions or body language! Because of that, I had *no idea* if people were paying attention, or interested or not. It made the interactivity slightly more difficult, though it picked up at the end of my talk. I had a powerpoint slide deck, and though Bill made it so I was able to click through the slides, I used Bill's help and just asked him to click the slides for me (I was not confident enough in my camera navigation ability!).

Overall, it was a pretty neat experience and I'd totally be willing to do it again. I suggest checking it out. Look for me (TestyDawn Darkmatter) or Bill (AgileBill4D) for a little guidance if you want.

Here are a few links for some more information:

SecondLife (the software requires a download, but there are multiple platform versions)

Agile Worlds Conference wiki

Agile Dimensions (in SecondLife)

Agile Bill Krebs (the guy behind the curtain)

A funny story

You have to have a sense of humor to be a tester. Seriously, you have to laugh at things that **nobody** else would **ever** laugh at. You have to be able to see the most crazy, off-the-wall things and rather than lose your mind, laugh at them, and then deal with them.

If you're a developer, especially a developer who has worked for years without a QA department or a professional tester at all on your team, you don't *have to* have a sense of humor, but it sure makes everyone's lives easier and makes for a room full of awesomeness if you do.

Let me tell you a funny story.

I had this bug fix to test. The bug was that when submitting a commerce-type action, if the name of the group was greater than 50 characters, the commerce transaction failed. The solution was to truncate the name (in sending the transaction) if it was greater than 50 characters.

Still in learning mode and lots of manual testing aiding that, I went into the UI of the QA server so that I could create a group name that was > 50 characters. The field in the UI prevented me from doing that. So I pulled the developer over and asked him what was going on. I figured if the UI prevented it, that was great, then the problem wouldn't happen, but what about records in the database that already had group names greater than 50 chars? Had we run a db script to modify them? Had the UI change just been done to prevent this bug from happening again?

He explained to me that the UI change had been done some time ago, but that we had not modified original records in the database. In those cases, the name would be truncated when the commerce transaction went through. So I went into the database to create myself a record with this quality and then I planned on going back into the UI to attempt the commerce transaction.

SQL Server told me no go on creating a group name like this: "Test One this is a really long group name because I want to test greater than 50 characters and I had to make a long name". It turns out, the database constraint on this field was a varchar(50). WTF? The database would not let me have a value that exceeded 50 characters, so how the heck could this issue even EXIST??

So this time I slid my chair over to the dev desk and asked how that could *ever* happen, and why were we fixing this bug that could not possibly exist. He said to me "Wait, here's how we are going to make it happen." I sat and watched him right-click on the table in SQL Server Mgmt Studio, choose Design..., and then go in and change the field to varchar(100).

I STARTED CRACKING UP AND THEN I YELLED "YOU CAN'T DO THAT!!"

He laughed too and then tried to explain to me that the production database really had that column set to varchar(100) so it was okay. I started laughing harder and said "WAIT! WHAT? The QA database doesn't even MATCH the production database?!?!?"

(as completely crazy as this story sounds, and please take your jaw off the floor, the following is an example of why I really love this team)

At about this point, the dev team lead came over and asked what all the hubbub was about. After we laughed through the explanation, during which I was described as being "a bit dramatic", which I was (I can kinda get a bit OMFGWTFLOL when I encounter these types of things), we agreed that we needed to have a QA web site up that had a QA-only database that was an exact copy of what was on production. We also agreed that from this point on, all changes to the database would be done on development, and then dev/test would check it out there, and they would be scripted such that when dev code was promoted to the QA site (let's call this the "exploratory" site), database changes would also be promoted with the code.

It was as easy as that. The three of us laughed about this craziness, figured out a way to set things up so that we weren't doing that one small thing in a crazy way any more, and just like that, we solved the issue and moved forward. As funny as the example is, I think it's a really great example of how little by little, a cooperative, respectful team can get things done.

And it's so much more fun when we can all laugh about it. Good thing I have a sense of humor!

Let's not forget what makes a good tester a good tester

In the past year or so, I've spent more time than not trying to find really good "agile testers" to hire. In this search, I have also had many conversations with other people about what I am looking for, what they are looking for in hiring, and how we can find what we are looking for.

Lanette Creamer asked a question recently about whether people searching for agile testers seem to be starting to focus too much on technical skills over *testing* skills. (By the way, Lanette will be looking for a job soon -- if you have an opening or might during this year, I suggest taking a look at her blog, Testy Redhead, and contacting her for further discussions.) As someone who has and will continue to hire testers to work on agile teams, I'd like to lay down my priorities in what I look for, and make an appeal to other hiring managers not to forget the qualities that make a really great tester.

So, if I had to lay out a bulleted list of what I am looking for in a person to join my team, it would look something like this:

• Passion: I am looking first and foremost for someone who is passionate about what they do. I want someone who enjoys testing, someone who will be on my team for the long haul and not just use it as a stepping stone.

• "The testing mindset": This one is hard to quantify, and I am relatively certain that I won't do this description justice. But here's a shot at it: I believe that many great testers are naturally curious, naturally analytical, and are critical thinkers. I believe they are particularly good at seeing through a problem down to its root issue. I believe they usually enjoy puzzles and logic problems. Many very good testers I have known are the kinds of people that see a typo or grammatical error on some publication and it stands out to them like a sore thumb.

• Technical ability: Coding ability is icing on the cake for me. I love to have it, but if it's not there explicitly, something that indicates an ability to learn to code is all I really need. I've said for a while that I think it's *much* easier to teach coding skills than "the testing mindset".

So when I am sitting in front of a pile of resumes, what process do I go through to try to find these people? It is by far not a perfect process, but here is *roughly* how I try to find great testers.

• Before I have resumes, I must have posted a job description. I try to make my job descriptions stand out from the norm. My classic role model for this is the Atlassian QA Engineer job description: http://www.atlassian.com/about/careers/listing.jsp?jobID=48 I do not require experience on an agile team or automation or coding skills.

• A resume that stands out: (Let's assume I always do resume scanning/filtering on my own rather than using a recruiter) I found last year that a large percentage (just over 50%?) of the resumes I received were very bland. Many of them appeared to be nothing more than a broad list of technology keywords squished onto a few pages. Unfortunately, listing a whole bunch of technologies you have heard of (they can't possibly be masters of all of these technologies!), tells me *nothing* about what you actually *do* or how you do it. I look for a resume that describes your accomplishments and tells me what initiatives you are going to bring to my team. I also look specifically for signs of continuous improvement, both in themselves and in their roles.

• During phone screening, I can usually get a good feel for whether passion exists or not. I tend to ask candidates about themselves, what they do, what they like about testing, and what they don't like, and what made them apply for my position. I tend to ask the typical biggest accomplishment and biggest disappointment type questions. I learned this year to ask questions about what they do outside of work (favorite blogs, books, websites, etc) and to pause long enough to let them say more than just their answer. Some people make it pretty clear at this point that they really want to do something else (like be a developer) or that they just need a job, period.

• For those that I want to talk to in person, I've started giving them a testing exercise (thanks to Patrick Wilson-Welsh) to do between the phone interview and in-person interview. I've chosen to do it this way because I don't really want to filter out people just because they are nervous in an in-person interview. In this example, if they can follow and test Java code, that's great, but if they don't have that particular skill, I send them to just the target website of that exercise for testing, and ask them to jot down a list of what they found and questions they have. I encourage them to communicate with me and ask questions freely. I have actually had people "self-select" at this point and refuse to do it.

It's worth noting that this exercise is what gives me the most information about their analytical and testing skills. Their responses to this will tell me a few things. I will get to see how well they think through the problem and which things they have questions on. I'll get to see how comfortable they are asking questions (I want someone who is not afraid to ask questions). Hopefully, I will also get to see them find some bugs and evaluate how they report those bugs.

• The in-person interview: It has been suggested to me that I work through the testing exercise in more detail with them in person -- kind of like a pair-testing exercise. In the future, I believe I will incorporate this more, because it makes sense. In general, though, by this point, I am fairly comfortable with the major qualities and fundamentals. During this stage, I tend to describe the current environment, along with the biggest challenges and hurdles to jump. I ask them how they would approach some of the real problems or tackle some of the actual challenges.

Obviously, there are many many resources available out there on how to find good people. Social networking has become a really great resource for recommendations for job applicants and shouldn't be overlooked as a source of finding people who can be specifically recommended. Johanna Rothman has an entire blog dedicated to Hiring Technical People. Books have been written on interviewing and lots of websites offer tips and advice on questions to ask. I'd like to hear from you about particularly good or bad interview experiences (from either side of the table) that you've had. What have I missed here?

My first published article

Oh yay!! My first article is out! Lisa Crispin co-authored this with me, and it's kinda cool to see it :)

http://www.agilerecord.com/

(you do have to register, but it's free)

I can't possibly post this, however, without also giving a shoutout to all of the awesome women in the latest ST&P Magazine: Women of Influence. Find it at http://www.stpcollaborative.com/

Nervous about an interview? Try this!

I think for most of us, being on the interviewee side of an interview is *hard*. Personally, I am always really nervous when I feel like I am being judged. I don't like being the center of attention. I have trouble with public speaking for these same reasons. An interview is a judgement of my professional abilities, and to not be offered a position after an interview is a *rejection* that hits a nerve. It's enough to make anybody nervous.

In public speaking, many people have little tips and tricks to help with being nervous. They may tell you to picture everyone naked (does anyone actually *do* that??), or to focus on a single person, make eye contact, and pretend like you are speaking only to them.

For interviewing, I found a way of looking at the interview that seemed to really help alleviate my nervousness before and during an interview: I pretended like I was just chatting with someone I had met at a conference.

I went to Agile 2009 in August, and I met a great many people that were in all kinds of different positions. Some were testers, some were developers, some were coaches, some were Ux experts. Some were consultants, some worked for very large companies, some very small. The range of experiences and situations was pretty big. I found that conversations were easy to get into with every single person I met. I'd ask a bit about where they worked and what they did, and what they were hoping to get out of the conference. I'd tell them a bit about me and what I was hoping to get out of the conference, too.

Sometimes someone would say something about an issue they were trying to solve that I had experience with, and I would be able to share some of my experience with them. Of course, this was a two way street, and I got a lot of great advice too. The point is that I did this enough times that in just a few short days it became pretty natural. If you've been to a large professional gathering, I'd guess that you've done much of the same thing.

So the next time I found myself on the interviewee side of the table, I told myself that I was just talking to another person I had met at a conference. I think that this idea addresses two main points of an interview: it helps me to learn about the company I am interviewing for (after all, an interview *is* (or should be) two-sided), *and* it helps them to get insight into what *I* can do for their team should they hire me.

When I ask them about what they do, I learn some more than just a job description provides about the company, the team, and the role. I can ask specific questions, like what a day in the life of this role looks like. When I ask them about their biggest pain points, I get insight into where their weaknesses are, and whether I think these are things I want to deal with or tackle.

Asking about biggest pain points is doubly beneficial, though, because then I can also look for things I can relate to. I look for things similar to what I have experienced in the past. When I find them, I can then discuss my own similar experience and what happened in that situation. In doing that, I provide the interviewer with information about how I can help them, how their hiring me will benefit them and make me the best candidate for the position.

Is it possible that I won't find anything I can relate to? I suppose, but I don't think it's all that frequent. If it happens, it may mean that I'm not a good fit for that position anyway.

I also think that to whatever degree I can pull this attitude off, it takes some of the pressure off of me too. I learned many years ago that I interviewed the best when I didn't really *need* the job, likely because I wasn't paralyzed with terror for my job status.

So, take a deep breath, relax, and just chat. Your passion and expertise will come out naturally. :)

How well should testers know the customer?

In an ideal world, our whole team (all of those people involved in creating a product) would all be on the same page, and the team would include customers. The customers on the team would be able to tell us immediately when something doesn't make sense from a domain context, and we would not waste any time on the things that don't make sense.

In my experiences, few teams are ideal. So let's assume that you don't have the cell phone number of your customer, *and* let's assume that much of the development team is not intimate with the deepest details of the domain of their product. Are there ways to minimize waste, still? Sure there are ... Here is a story I tell people a lot and I figured I would share it here.

I worked in a job once where I was in charge of running the QA team of a small start-up. Their software focused on the bioinformatics researcher. We made heavy use of statistical algorithms for genetic comparison -- sometimes pairwise searching, sometimes aligning, sometimes tracking experimental data over time. Our software did a lot of visualization of this data, so that these researchers could easily track down the information they were looking for to guide their next step in research.

The company was small enough that it didn't really have anyone who represented a BA kind of role. We had a "Project Manager", and "Software Leads", but QA really ended up representing the customer in most things. At times, we ended up actually being customer support as well. I had noticed while we were growing that the new developers lacked domain knowledge, and many times, when we would submit bugs ("These results can't possibly be correct"), they had no idea what was incorrect because they didn't immediately see *why* it was incorrect.

So one of the things I did to combat this issue was train my QA team in the depths of domain knowledge. We learned how to perform the algorithms BY HAND. We split the algorithms between us, and each became an "expert" in a group of these algorithms. We spent a lot of time learning the command-lines and working through examples manually.

As a result, I believe that my little circle of influence was pretty efficient. The testers could look at a visualization chart and immediately flag the parts that were problematic. We could understand what the customer was talking about when they came to us and reported an issue. We could even ask them the necessary questions to pin down the source of the issue (most of the time!).

Since that time, I've worked on a few other teams where many people on the team (dev, tester, etc) did not have depth of domain knowledge. I have seen how many issues slip right on through, because nobody in the technical team realized there was a problem (and we all know how expensive things are to fix once they're out in the wild). Troubleshooting issues that *are* identified takes longer, because the root of the issue may not be immediately clear.

So, how well should testers know the customer? Well, testers and developers alike should have as much domain knowledge as possible, and should be as intimate with the customer as possible. Especially in the absence of an actual customer (or lack of constant access to one), the more domain knowledge the technical team has, the more likely they are to find issue early and track them down easily.