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 2

12.01.2011
| 9007 views |
  • submit to reddit
So, this next one, for me, points out something that I felt was a difficulty in being a tester with development experience.  See part one here.

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.

Source: http://www.passionatetester.com/2008/05/how-not-to-win-hearts-of-developers_30.html
Published at DZone with permission of Dawn Cannan, author and DZone MVB.

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

Comments

Jammer Man replied on Thu, 2011/12/01 - 3:11pm

Wow ... the day I let a know-it-all tester try to tell me how to code is the day I start looking for another career choice.

Dave Clarke replied on Thu, 2011/12/01 - 6:33pm

I have only worked with one tester who had any ability to write code. In that case the tester had managed to find his way around tweaking the code generated by SQA Robot to automate testing a web application. His tweaks were sufficient for the task at hand but would never have passed muster for development work.

In the situation you describe above, the culprit is neither you nor the developer. The culprit is surely a culture that allowed code like the sample provided to be considered acceptable. The developer writing code of that ilk is a junior who needs guidance in order to learn his trade and the culture of his team should support and encourage that. Otherwise as a tester you will be doomed to continue to find stupid errors that would never have passed the appropriate unit test.

 

Rick J. Wagner replied on Thu, 2011/12/01 - 8:56pm

I work at a well-known open source company as a support engineer. The QA people write tests that exercise the products, so they know the products inside and out. (Often times, they'll find some problem and also suggest a fix at the same time.) I respect them as much as I respect the developers who write the code to start with and my fellow support engineers (who have the daunting task of understanding someone else's code!) I know there are also organizations where QA is a holding tank for developers who aren't quite up to snuff. The second model is a corporate anti-pattern. QA is an honorable job.

Cosmin Mutu replied on Fri, 2011/12/02 - 3:04am

As a developer I can only THANK YOU for not letting that code fly.

Paul Russel replied on Sun, 2012/06/10 - 8:28am

Both your part-1 and your part-2 seem to say you approached someone else from a position of superiority as opposed to from a position of collaboration. The problems had nothing to do with agile, just basic working relationships. It's good to see you were able to work things out.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.