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.
2 comments:
Awesome article. Every tester/QA should read it!! The attitude to describe the bug/problem of developers done code is really matter.
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.
I'd like to recommend the book "First Break all the Rules" by Marcus Buckingham - notably chapter 4. I found a ton of great advice in the book and a few revelations.
Best of luck.
Erin
Post a Comment