Did you know? DZone has great portals for Python, Cloud, NoSQL, and HTML5!
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
Email
Views: 5618
  • submit to reddit
The DevOps Zone is presented by DZone with partners including ThoughtWorks Studios and UrbanCode to bring you the most interesting and relevant content on the DevOps movement.  See today's top DevOps content and be sure to check out ThoughtWorks Studio's Continuous Delivery Whitepapers and UrbanCode's Webinars.
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.)

ThoughtWorks Studios and UrbanCode, the sponsors of the DevOps Zone, are champions of the DevOps movement.  Their deployment tooling solutions focus on the entire software development lifecycle, involving all parts of an organization, which helps facilitate a migration to the DevOps philosophy.

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.

Comment viewing options

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