DevOps Zone is brought to you in partnership with:

Dawn Cannan is a software test evangelist who has been working to integrate testers as members of software development teams and improving the working relationships between testers, developers, and everyone else for the past 9 years. When not speaking at testing and agile conferences and user group meetings, she spends her time working in the open source community on the .NET version of SeleNesse, a plugin making it possible to create Selenium tests in FitNesse. She also writes actively, publishing articles and posting to her blog at passionatetester.com. Dawn is a DZone MVB and is not an employee of DZone and has posted 8 posts at DZone. You can read more from them at their website. View Full User Profile

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

06.06.2011
| 9717 views |
  • submit to reddit
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.
References
Published at DZone with permission of Dawn Cannan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)