Confessions of a Passionate Tester

Are you the one holding you back?

2010-05-28T22:58:00.005-04:00

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

2010-05-17T11:14:00.002-04:00

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

2010-05-16T14:38:00.003-04:00

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

2010-05-02T14:29:00.007-04:00

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

2010-03-29T09:57:00.002-04:00

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?

2010-03-21T20:38:00.005-04:00

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?

2010-03-21T19:24:00.004-04:00

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

2010-03-16T14:17:00.007-04:00

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!

2010-03-07T10:02:00.004-05:00

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

2010-01-15T15:40:00.002-05:00

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!

2010-01-15T14:48:00.005-05:00

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

2010-01-12T21:24:00.002-05:00

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

2010-01-09T20:54:00.004-05:00

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

2010-01-07T15:09:00.003-05:00

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!

2010-01-03T08:45:00.003-05:00

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?

2010-01-03T08:10:00.002-05:00

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.

Change your organization, or change your organization

2009-11-15T19:24:00.003-05:00

That's what Michael Feathers said to me at Agile 2009. It was the end of Patrick Wilson-Welsh's Ugly Code vs Clean Code clinic, and I had gathered a group of people to see if they could help me solve my problem: an organization with a *huge* legacy application (2.5 million lines of *true* legacy code -- no unit testing, no automation, eek!), stuck in a time long since past, where the development team is surrounded by a closely guarded fortress, and the test team was really just there to have someone to blame when customers complained.

After he asked me a series of questions (which really just confirmed that I had already been trying all the things that an expert would have suggested), he said something that stopped most of the group dead in their tracks for a split second: "Change your organization or change your organization". It was a phrase I had heard before, yet at that moment, it hit me like a ton of bricks.

There are countless resources out there for supporting those people who are "change agents", who help spark change where they work, who have gone through or are going through Agile transitions. There are resources for those who are dealing with the more difficult aspects, such as people who just resist change. Markus Gartner wrote up a great summary recently on his blog.

There are many techniques for pushing through resistance, but how can you tell a fight that isn't winnable? Or, at least, isn't winnable for you?

It seems to be something you just "know", from what I can glean. And it is certainly not specific to organizational change. Kenny Rogers sang that wildly popular song The Gambler, "You gotta know when to hold 'em, know when to fold 'em, know when to walk away, know when to run..." The question I have always wondered is "*HOW* do you know?"

I suppose it's not an answerable question at face value. Each situation is different, filled with countless variables, and there is not a single, universal answer.

What is the dark side of what happens to a change agent who is outnumbered, lacking in authority, and just shut down at every turn? Markus's term, "cultural infection" was what happened to me. The crazy culture that I inserted myself into became too much for me to bear, and infected my personal and family life. That was when I knew it was time to fold 'em.

The thing that has gnawed away at me for all of my (relatively short) time as an Agile champion, is "What happens to the people who just don't do well working this way?" or "What happens to the people who don't *want* to change?"

Sometimes, they are pushed out by those who do want to change. I've seen that, people who become so miserable because their interest in working in silos makes them the odd man out, and they eventually get so miserable that they leave.

But what happens when there are more people who prefer to work that way than people who want to change? Or worse (in my view), there may be more (in the organization) who *want* change than those who don't, but the group that doesn't want to change is concentrated in the people who develop the production code?

If an entire team of developers does *not* want to change to a more collaborative environment, or better, to Agile, how can any other department succeed, even if they *do* want to work in a more collaborative way? Can you incent people to change if they don't want to, or have no reason to change?

Believe me, I've tried. I've followed the patterns in Fearless Change, made the countless arguments *for* Agile available on the web, posted slides from various talks on my cubicle, talked to people until I was blue in the face, decided to run *just* my QA department in this fashion, asked the "just try it for a short time" questions, run some small tools on my own that would help the current development dilemma, show graphs and line charts and cost analysis studies, put together presentations. Still, I am forced to sit and wait until a release "in a pretty package" (yes, that has actually been said to me) is ready for my test team to have at it. Still, I get that pretty package, and can't do anything with it because the software doesn't install properly.

I've learned that there are organizations where even though the old-skool Waterfall style of doing things has so clearly gotten them into trouble, they don't see that. Worse, the developers continue to be held up on a pedestal, regardless of those signs. When this happens, the culture of the *whole organization* has obviously supported it, and possibly is continuing to support staying *just the way they are*.

I am reminded of a Jerry Weinberg quote: "Things are the way they are because they got that way".

I'd be willing to bet that even when an organization is this deeply rooted in their ways in the face of adversity, some can still embrace change and come out of it far better than they have ever been. I don't know how to tell the difference between those that can and those that are bound to continue repeating the same mistakes.

I've talked before about the "wall of pain". If an organization never lets those responsible feel the "wall of pain", they will rarely have any reason to change. For me, I've hit my personal "wall of pain" before the organization hit theirs.

It's still a bug, and your denial does not change that

2009-11-13T14:34:00.002-05:00

UGH!! I've had this frustrating discussion with a developer recently that is really annoying the heck out of me.

In the particular scenario being discussed, this product has a history of not installing correctly. It's a (mostly) .NET desktop suite of programs with a central processing engine. The most common installation errors involve components not registering correctly. The crazy thing about that type of issue is that it manifests itself, for this particular product at least, in fairly inconsistent ways. Sometimes, a user function doesn't work (while sometimes it does!). Sometime, the processing engine locks up unexpectedly.

In the past 4 months, I am certain that I have seen the number wasted man-hours troubleshooting something that ended up being an installation problem climb well into the hundreds. In QA alone, I can cont at least a week, times 3 people. I'm already at 120 -- not counting support, developers, product management ....

There was a customer issue that they had spent the past 2 weeks troubleshooting, only to find out that a file had not been registered properly. So product management asked the developer the following:

Is there an identifiable bug in the installation code that we could track in Bugzilla for inclusion in a future release? Or is this issue a one-off?

And the developer's response was that there was no bug in the installation code, so there was nothing to fix. He went on to explain that the files has just not registered properly or were corrupt. He said that uninstalling the suite should have cleared the problem. (I don't want to copy his response, just because it's fairly product-specific.)

So this was my response to that (I was actually fairly nice in it, because seriously, it drove me *crazy* to see that "it's not a bug" statement!)

Though I can see where there is not a clear bug in the installer, I don’t think that is the same as “we are missing something and should implement some checks”.

It just really seems to me that *any* install that we do should be checking itself, that it installed correctly. I have seen dozens of man-hours wasted in just 4 months, on what came down to things not installed properly.

“It didn’t tell me that it didn’t go right” is a bug, in my book.

Now seriously, let's look at this issue.

If the software does not install properly, that's a bug, right?

If the software fails to install properly, AND does not indicate to the user that *anything* has gone wrong, that's a bug, right?

If this install problem causes the software to not work, that's a bug, right?

Is it considered okay to ask the customer to uninstall and reinstall their product (no trivial task, mind you) when it's not working? Okay, anybody but Microsoft?

Has 10 years of testing led me way far astray from the basics? Am I way off base here?

Lanette Creamer suggested that the developer was right; that it wasn't a "code bug", but rather a requirements failure. This is a valid point, but for some reason, I hate having to "frame" things in a certain way to placate a defensive person.

The bottom line is that this product is doing something it should not be doing, and it is impacting the customers, the developers, the support people, the QA people, the product people ... IT SHOULD BE FIXED. Seriously, don't throw blame, don't deflect attention away from yourself.

Let's instead sit down together and figure out where the problem is and how to solve it.

Harmony is beauty

2009-11-11T09:44:00.006-05:00

First and foremost, if you read my blog. I have to suggest that you go grab yourself a copy of Beautiful Testing. It's a great read, and has inspired this post.

I've been inspired by reading this book. I've been reminded of my passion, of the reasons I have chosen to do what I do. After all, I chose to be a tester, I haven't just fallen into a job and decided I should deal with the hand I've been dealt.

I didn't always want to be a software tester. As a young child, I wanted to be a marine biologist! Actually, I wanted to study the neurological systems of dolphins. I was convinced that I was going to figure out what it was about their brains that made them so smart. I still have the book that inspired me then, 9 True Dolphin Stories.

After a marine biology course and choking through learning the ocean zones, I shifted my interest over to genetics. There was something about genetics that was *beautiful* to me. I was amazed at how the whole system *worked*. Granted, sometimes it goes awry, but at an incredibly rare rate. I liked it because it is so *simple*, and yet so completely *complex*. I was amazed at how 4 simple bases could turn into a *human being*. (HA! In the middle of writing this blog post, I went to Barnes and Noble and happened to come across a copy of Matt Ridley's "The Agile Gene"! I'm a Matt Ridley fan, and this title is a re-title, but very coincidental timing!)

When looked at that way, genetics and computers are rather easily related to each other. In genetics, a 4-letter alphabet turns into some complex stuff, like human beings. In computers, a 2-letter alphabet turns into some complex things, too, just not as complex, and too often, not as smoothly. So in a lot of ways, my switch from genetics to computer science was an easy one.

When I work toward making software beautiful, I have in my head a picture of how it's done in genetics. Those systems are exponentially more complex than software, and yet, there has somehow developed a *synchronicity* (Is that a real word?), where even given countless variables, the system is responsive and *works*, regardless of the state of all of those other variables.

Isn't that incredibly beautiful?

Reading Beautiful testing, I saw these same ideas threaded through the chapters.

Matt Heusser talked about math in terms of number theory and proofs, including some commonalities in nature (the Fibonacci sequence and pi, for example). In studying mathematics, Matt found an appreciate for what he calls "aesthetics" (and what I've likely been calling 'harmony'). His sentences on the aesthetics in mathematics hearkened back to my appreciation for genetics for the same reasons.

But it was Chris McMahon's chapter, relating creating software to an artistic performance, that inspired me to think about the way I work on a software team in a new light. He mentioned the way a band rehearses together before a performance. I have seen some *amazing* bands, where I watch them communicate with each other silently. The slightest gestures can be made, some not even perceptible to the audience, and the rest of the band follows suit.

These things happen all over the place! A new mom once told me that she enjoyed me coming over because I "just knew" what she was going to need before she did. Well, of course I did, I've been through the mom thing before. I used to ride horseback (dressage, actually) and with some of the horses I trained on, the *slightest* shift in my body weight caused the horse to change direction. I had to learn to control every muscle in my body to only send the messages I intended. Have you ever seen a couple, who at a party, seem to be able to send signals to each other with just a glance of the eyes?

Coming back to testing and software, it seems that the very best teams work in much the same way. They are able to shift direction, together, without falling out of step with each other. They are able to fill in for each other without the need to go through hoops to do so, and they trust each other completely. They all care about the same things, and work together to accomplish their goals, following the same values.

As a tester, I love the fact that I get to strive toward this kind of harmony, while also managing the effects of so many other variables: the customer, usability, risk, time, cost, value, technology, the business goals, product management, etc etc. For me, being involved in testing means that I have my hands in everything, and spend my time trying to make sure that they *all* work together seamlessly. As a tester, I must represent the customer. I must represent the potential customer. I must represent the developer. I must represent the business. And, I must tie all of these together in an intricate web, ensuring that the outcome represents all of them and is responsive to any variation in their needs.

THOSE are the reasons I am drawn to Agile. THOSE are the things I see in the teams I have had exposure to that I think work *really well*. THAT is why I love testing. Testing *is* beautiful.

The difference between motion and action

2009-11-10T13:11:00.001-05:00

I just read this amazing blog post by Steve Blank, and felt compelled to share it.

I'll just post a link now, though I suspect my own spin on it may be coming ...

The Difference Between Motion and Action

Making Quality a Priority

2009-11-09T14:54:00.002-05:00

Here is a quick PowerPoint presentation I think may be useful to some other people, too.

The intended audience is business people or executives who still need a little bit of understanding in what it means for "quality" to be baked into every part of software development, from inception through to release, and in what it takes as a team to have the best collaboration between developers and testers.

Please feel free to use it, modify it, etc. And as always, if you have feedback, let me know!

Making Quality a Priority

What if you could design your ideal "software creation" plan?

2009-10-21T15:49:00.007-04:00

So, a special situation has been presented to me, and I'm going to try to solve it in a collaborative way. It's short notice, but I have what I have, you know?

I've been given an opportunity to develop out a roadmap for ensuring that our very LARGE legacy product heads in the right direction from this point out. Their current focus is apparently centering on the word "stability" Roughly, stability, to them, means that what we have designed our product to do, *works* and is satisfactory to the customer (things like performance cannot be ignored here, for example).

This team (people/process/infrastructure) roughly works on the level of a bunch of unorganized college kids, so there is a lot of room for improvement. They need some fundamentals put in place, for sure -- Automatic builds, CI, unit testing ... (clearly the list goes on from there). Although I specialize in testing, I believe that our executives now understand that "we can't test quality into our product" -- we have to be doing things with quality from the beginning. As I think about all the things this team needs in order to be working in a fashion that does actually move them forward, I want to be sure to optimize such a transition.

I want to hear from others, however, about what *they* would do, if given such an opportunity. I want to brainstorm as a group how people *wish* their teams worked. Let's draw up an ideal "software creation" plan -- beginning to end, all of the pieces.

I have a space available for a physical location, for those who are local. Please send me an email (address at the top right of the blog) for specifics.

I'll be offering a remote-in ability, too. I've created a GoTo meeting that offers both VOIP connection and phone-in connection.

I'll tentatively plan on holding this at 7:00pm EST today, Thursday, October 22 (Sorry! I meant the 22nd!).

1. Please join my meeting.

https://www2.gotomeeting.com/join/604606915

2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone.

Dial 630-869-1014

Access Code: 604-606-915

Audio PIN: Shown after joining the meeting

Meeting ID: 604-606-915

Getting Started with White

2009-10-12T16:19:00.002-04:00

I've recently decided to dive into the world of Project White and MS UI Automation, since this is relevant to my current project. I had to create a tutorial for a team to get set up to use white to begin with, so I decided that I could share that tutorial with everyone else as well. It goes into some detail about Visual Studio as well, and is intended for an audience that has not necessarily done automated testing through Visual Studio before.

The tutorial uses MS Visual Studio, C#, White, and UI Spy to create an *extremely* simple test. My intent was just to show how to set it up. Next time, I will describe starting to write tests, including common functions in White and writing good tests.

Please, please offer feedback. I would love to be sure that I am doing things the best way possible!

White Tutorial

be the worst

2009-10-07T11:05:00.004-04:00

Huh? Did I just say "be the worst"? Yep, I sure did. But before you go telling your boss that I told you to be the worst tester you can be, let me finish the phrase!

First and foremost, I have to give credit where credit is due. I saw this phrase first from Chris McMahon -- he says that this meme has been around the music business for a long time. He credits Pat Metheny, who said, "...try to be the worst guy in whatever band you're in. That's the secret."

Given the context, what I am saying is "be the worst of the people you are surrounded by", or "surround yourself with really great people."

At Agile 2009, someone told me that Elisabeth Hendrickson decided to learn by inserting herself into the best teams she could find. Even before I encountered the "be the worst" quote, I had begun bouncing around the idea of how I perceive myself versus those I work with.

I think back to an early job in my career, straight out of college. At this place, I remember thinking to myself with some frequency, "These people are *SO* *SMART*! I feel SO DUMB when I am around them!" I often tried to just keep up with conversation, hoping to fake it long enough to avoid appearing dumb, too! Looking back, how I wish I could have gotten over my own insecurity and taken the opportunity for exactly the opportunity it was! What I should have been thinking was "Wow, these people are *SO* *SMART*! I want to learn everything I *can* from them!"

What can we get out of "being the worst", and why would anyone suggest that?

I think we can get a *lot* out of it: learning, experience, growth ... In working with people who have a set of skills that you wish to expand for yourself, you can see first-hand, on a day-to-day basis, and under a whole slew of circumstances how that quality is manifested. Sometimes it might be a technical skill. Maybe it's a communication skill.

As I have grown in my career, I have begun to feel like the "dumb one" less and less. I think that my passion to get better and better at the things I want to be good at, have made it more and more difficult for me to *be the worst*. What have I done in response?

I've become *way* more active in the agile community. In that way, I can surround myself (though not as frequently as I would like) with those people I see as *way* more skilled than I am in certain things. I found this out with certainty at Agile 2009. I love talking to Elisabeth Hendrickson for her insight into agile testing and human relationships at work. I enjoy Lisa Crispin's company for her amazing ability to be a great agile tester, without falling back on programming the hard things (like I do!). I met Patrick Wilson-Welsh, and admired his passion, sense of humor, and ideas on good, clean TDD. I had conversations with Michael Feathers and Bob Martin to try to gain some insight into my specific legacy code issues. I had great conversations with Antony Marcano and Andy Palmer about testing tools and frameworks. I *pair programmed* with Abby Fichtner to gain from her development experience. Of course, there were many others ....

In this way, I forged relationships and surrounded myself in a way that I could *be the worst*. I'll keep saving my pennies to go to conferences and keep being active in the agile community so that I can keep *being the worst*.

Do others try to put themselves into situations where they can *be the worst*? How do you keep yourself always learning and always surrounded by those you can learn from?

Does having a separate maintenance team hurt efforts toward accountability?

2009-10-05T13:03:00.002-04:00

I was recently thinking about a situation that puzzled me, and came to a realization that makes me a bit nervous ....

I have had exposure to some teams where even though they are in firefighting mode more often that is comfortable, and/or even though their customers are unhappy, and/or even though their software has a *lot* of bugs, they still don't seem to "get it" and try to do things in a better way.

I have sat, baffled, looking at people who lead these teams, my jaw on the floor, wondering why the people leading these teams are passing the buck on the team's responsibility for problems, and instead presenting a magic show to prove why the problem is not theirs.

And today, something hit me: I was thinking about what would cause someone to change; what would make it so that they finally felt the need to do something different, and the term "the wall of pain" came to mind. This term comes from a blog post I read a few months ago, "Fighting Technical Debt with the Wall of Pain". What would instigate change? Enough pain that it feels necessary, in order to escape the pain.

This reminds me of Parenting 101: How do I stop my 12-year-old from making irresponsible decisions? I make them painful enough that he will be sure to avoid the pain. Luckily, these days that is as easy as "Oops! Your PSP ran away! I can't find it!", or "Where are your Playstation controllers? Gee, I don't know ... I guess maybe they will return when you start doing the chores that you are responsible for."

BUT ... BUT ... what about companies where the new development team is a separate entity from a maintenance team? What if the developers who are writing new code are sheltered and protected from the results of poorly written code? In some cases, it goes something like this:

- Development team writes software ... Maybe they fix a few bugs along the way. Sometimes, if bugs come up and it can be proven that they existed in previously written code, they may shrug them off as not the result of current work, so not their problem right now.
- Development team's schedule gets squished, and as it gets closer to release time, only the *most* important bugs that are proven to be the result of their current work, are even looked at by the team.
- Release happens. At this point, product is a released product, and the workflow now looks like this:
- Customer has an issue, customer calls Support. Support tries to reproduce it, and if they can, they file a bug. Bug gets reported to Maintenance team, and they work on it.

In the above scenario (which exists in some companies), the team that originally wrote the aforementioned poorly written code never sees the wall of pain. Seriously, for the most part, there is absolutely zero repercussion to them directly for bad code.

In a case like this, the responsibility for well-written code falls upon those who are internally motivated to do their best, and strong enough personalities that they fight the push to get *something* out *faster*, well-written or not. I believe that this type of personality does not describe the majority, and the whole team falls into a pattern of continuing to write poorly written code. What is there to stop them?

Has anyone had any experience helping a team to transition into a more agile-like process from a situation that looked like this one? How do companies like this adjust to fight this pattern?

I wonder if it would help to break up the idea of "new dev" versus "maintenance" teams, and instead cross-pollinate into functional teams. In this case, there would be a team for one specific module, component, or module, and they would handle both new work and bug fixing/maintenance. Would this strategy work?

Confessions of a Passionate Tester

Are you the one holding you back?

Building a test team ...

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

Executable Specifications using FitNesse and Selenium -- STAREast 2010

Selenesse dotnet is GO

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

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

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

TEDx is awesome!

Testing Legacy Apps

Welcome to the virtual Agile world!

A funny story

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

My first published article

Nervous about an interview? Try this!

How well should testers know the customer?

Change your organization, or change your organization

It's still a *bug*, and your denial does not change that

Harmony is beauty

The difference between motion and action

Making Quality a Priority

What if you could design your ideal "software creation" plan?

Getting Started with White

*be the worst*

Does having a separate maintenance team hurt efforts toward accountability?

It's still a bug, and your denial does not change that

be the worst