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
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
I know it won't happen that way, but I will at least start pretty early.
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
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
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?"
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