How *NOT* to win the hearts of developers, part 2

So, this next one, for me, points out something that I felt was a difficulty in being a tester with development experience.

I don't believe I handled it the best way, but hope that I can use it as an example and teach, perhaps, better ways to deal with developers.

Not long after I started, we were developing a way to download data from our website to a file. The requirements said that the file name had to be alphanumeric, with spaces allowed. This seems easy enough to test, right? So, in the file name field, I held down my shift key and I went all over the keyboard:

~!@#$%^&*()_+|}{":?/.,';\][=-`

As I expected, I broke the site. Broke it in a bad way, like big exception on the screen. Wowee ... I filed a bug. It got worked on, and I repeated my steps in the file name field.

~!@#$%^&*()_+|}{":?/.,';\][=-`

AHA! The SAME THING HAPPENED! Incredulous, I walked over to the developer's desk, sat down, and talked about the issue with him. He pulled up the source code. I couldn't believe what I saw. It looked something like this (pseudo-code):

for (each char in filename field) {
if (char == !) {
pop message up to the user about invalid chars;
if (char == @) {
pop message up to the user about invalid chars;
if (char == #) {
pop message up to the user about invalid chars;
if (char == $) {
pop message up to the user about invalid chars;
if (char == %) {
pop message up to the user about invalid chars;
if (char == ^) {
pop message up to the user about invalid chars;
if (char == &) {
pop message up to the user about invalid chars;

and so on .....

*GASP* I absolutely could not believe what I saw. CS 102 taught me better than that. So I said to him "Why are you doing it that way? Can't you use something like a regular expression?" He said something like "Oh, well, Java doesn't have regular expressions." Me: "Um, yes it does. I have used them. In Java." Him: "Well, I don't know how to use them, so this will work for now."

Huh? Angry that he had tried to pull a fast one on me, absolutely shocked that it was being done how it was being done, I left the conversation. I ended up talking to a few other people, informally, about my concern, but nothing happened immediately. Of course, he found out I had complained about him (I don't suppose I expressed it in the nicest way), and once again, I had created a dev vs. QA situation.

Eventually, I worked out the relationship with said developer, and made it a friendly one again. That code was never released.

As I thought about it later ... I realized that I *did* know how to do what needed to be done, but I let his strictly "tester" view of me prevent me from trying to teach him how to be a better developer. In hindsight, when the conversation hit the "Well, I don't know how to do it" point, I should have been able to say, "Okay, let's work through this together and let me show you. Let's find the regex class ..." etc. I have found since then that our developers are generally pretty open to sitting down together with me and letting me show them a way to do something that I have used before.

Laughing at myself yet again ... in a more true to agile way, the team works much better when testers and developers can just sit together for a while, and non-confrontationally (I don't think that's a word, but it's a quality I strive for) discuss the pros and cons of using certain strategies for solving problems. I have seen many problems solved really early when I pair program/test with a developer as they code, when I can ask the questions and point out the things that I know will come up in my testing. It just makes sense.

How *NOT* to win the hearts of developers, part 1

So, I had this crazy idea that I would try to do this blog in some chronological order, since a lot of the early posts will be historical lessons.

I know it won't happen that way, but I will at least start pretty early.

I recently attended the STAREast conference, and during Janet Gregory's agile testing talk, I heard her talk about some qualities that an agile tester should NOT have that sounded eerily like me. The team got a kick out of my presentation to them after I got back, where I talked about how testers who acted like "quality police" did no good for an agile team. It was a big lesson for me, and very humbling.

So let me tell you one thing NOT TO DO when you are trying to help a team of developers transition to agile. Come to think of it, it reminds me of a Thomas Edison quote about being able to tell you 10,000 ways NOT to make an electric light bulb .... (I grew up just a few towns south of Edison, NJ).

In any case, in one of my first official testing assignments at Rainbow, I had very much a "quality police" mindset still. Their adoption of scrum had not yet quite kicked in, and they did a whole bunch of development and then gave me a final product to test.

And test I did. That night, working fervently from home, I sent an email out with 37 bugs in it (bugs over email? I will address this later). Though I was rather proud of myself at the time (37 bugs! YEAH!), it turned out the team was not quite ready for that. There were complaints of not being able to tell the status of the issues I had sent out, not knowing who was working on what issue, not knowing which issues they were required to fix ....

In short, I had created chaos. A testing and development nightmare. I had, unwittingly, pitted myself against the development team, thus splitting our budding agile team into dev vs. QA. I have a tendency to come on strong ... and the team learned it early and thoroughly.

Recently, I have suggested a few changes to the way we do things ... now, our testers are involved at the initial stages of user story development. We can run the web site locally and check on things the moment that a developer has finished some part of development (get latest, build, go to localhost website). I think most importantly, formal bugs are not submitted within the scope of a sprint's user story work ... if a tester sees an issue, he simply walks over to the developer (or IMs him or calls him) and says "hey, I see this thing, can we look at it together?"

I have watched these few changes bring our testers and developers closer. I have watched how much more comfortable they are talking to each other. I have learned how to become a more agile tester, and how much more effectively and efficiently a team can run when approached the right way.

Zero to Sixty Agile Testing

So, here is my first blog post .... let me give you a little introduction and some background to my current story.

I am Dawn, developer-tester and tester-developer ... I have my BS in Comp Sci from Clemson University. I spent 6 years with a bioinformatics company, starting as a part-time tester, and eventually becoming QA Lead. I had a large part in creating their QA department -- policies, procedures, bug tracking, training, the whole gamut. We used Test Director and WinRunner for a while. I was able to keep my hand in some development, for our internally written bug tracking system and for a project I was technical Project Lead on for the NSF. I can still remember hearing the word 'agile' for the first time while I was there.

When I left that job, I did some .NET development for a while. I developed several enterprise applications, from website/database to mobile/web services apps. I learned a LOT there, like all of the reasons why I don't want to be a developer full-time.

I was happy to get a QA Engineer job at Symantec when I decided full-time development wasn't working for me. However, not long after I got there, Symantec decided that our local office wasn't worth keeping open, and I found myself looking for a job, along with a few hundred other developers and testers. Symantec was one of the best jobs I have ever had.

To my surprise, at about that exact time, a local company, just 2.5 miles from home, had posted for a QA Engineer position that I was a perfect fit for. They were hoping for someone with at least a familiarity with development, and as it turned out, they had never had any formal QA. Luckily, I had experience building a QA department from the ground up. I will call this company 'Rainbow' from this point on.

This is where I get my "Zero to Sixty" reference .... this development team had just started Scrum, just 2 weeks before I started. So ... not only had they never had any formal testing of their products, but they were just starting the transition to an agile team. The road has been bumpy, to say the least, but I have found that as much I thought I had to teach these guys, I have learned some incredible lessons along the way about agile and how testing fits in.

I hope that this blog will tackle, one by one, many of the lessons that I have learned, and the ones that I have taught along the way ..... so buckle your seat belts (yes, I realize how completely dorky that reference was), and get ready.