The Software Testing Club recently put out an eBook called “99 Things You Can Do to Become a Better Tester“. Some of them are really general and vague. Some of them are remarkably specific.
My goal for the next few weeks is to take the “99 Things” book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions. 
Suggestion #69: Accept that Developers have a different mindset – Steven Cross
To be honest, I’m torn on how to approach this suggestion. When we say that someone has a different mind set, we are in essence saying “they don’t think the way we do”. On one hand, that’s true, but it’s also an oversimplification. 
Programmers do test, and some programmers are exceptional testers, just as there are a number of testers who can also program very well. With that, I tend to consider the whole “Tester is from Mercury and Programmer is from Saturn” to be misplaced. We don’t entirely “think differently” as much as we “think situationally”. When we are programming, we are in the process of building, of stringing pieces together, of taking components and organizing them so that they stand together as a structural whole. As testers, we think in the opposite direction. We look at the whole, and then we try to break it up into its constituent parts where we can to interpret the interactions. 
To put this into perspective, try on another pair of work boots for awhile, and see how it feels.
Workshop #69: Testers, take some time to create a utility application for yourself. Use any language you want to, or use shell scripts. Create a basic User Interface for the utility, and follow conventions of practice for the medium you use. Ask a programmer to test your code. Listen carefully to the input that they give you. Now ask another tester to test your code. Listen carefully to the input they give you.
There are any number of ways that this can be met, and frankly, the point of this exercise has less to do with the utility/application itself that it does with how people approach programming and testing. 
There are several good books that approach this topic, and can help even a relative novice make some cool tools that follow code conventions. One example for this is “Build Awesome Command Line Applications in Ruby” by David Bryant Copeland. Another is to create the game structure that Zed Shaw lays out in “Learn Python the Hard Way“, or to work through examples offered at Codecademy and make your own variations. Whatever the approach, the goal is to spend the time to program something that goes beyond a simple one off script. Put some time into it, have some dependencies, create some functions that call each other and pass data from one to another.
If a friendly programmer is available, sit down with them and ask them to test your application. Notice what they focus on. Some may very well go in and take a black box approach and see how it works from the users perspective, but don’t be surprised if their first inclination is to go in and investigate the code that you have written. Since they have experience reading through data structures and code syntax, they may very quickly see that you have dead places in the code, that you are not calling certain functions even though you have defined them, or that you are passing variables and not correctly preserving their type in the process.
From there, they may open up the user interface ad walk through the areas that they see based on the code they have just reviewed. In the process, they may offer suggestions by saying “if you were to change this structure/method, then you could more quickly perform these actions”. That may not be the feedback that you were looking for, but it’s very valuable. As a first time home builder, you are getting wonderful feedback and excellent testing of your structural integrity, your foundation, and your scaffolding to hold everything together. They may not focus much at first on look and feel, or on the niceties of the design. They will consider the underpinnings and making sure that the program is standing on a firm foundation, and they will be able to do so very rapidly.
By contrast, when we ask a tester who may or may not have much in the way of programming skills, they will look at the utility/application as though they were a very skeptical user. They will poke and prod and look to see if they can find any areas that would get a user in trouble. We could consider the dedicated tester to be like a termite inspector. They see the walls and the carpet, the nice door fixtures, etc, but they want to see if they can bend back the carpet in the corners to see if there is exposed wood or moisture damage. While the coder/programmer would be looking at the foundation and the structure, the tester is looking at the overlay to see if they can spot areas where the underlying integrity of the structure could be compromised.
These skills are complementary, they are not opposed to one another. Truth be told, each of us uses them just a bit differently depending on what we are doing. When I am in the process of writing automation code, or creating scripts to do various things, I am honestly not thinking about testing it to the level I would if I was external to the programming. Part of me is focused on the interactions and the processes that go into the work, but much of the time, I’m thinking about how to string together the code necessary to be functional, in line with expectations and not be sloppy or incoherent. In short, I don’t think as much like a tester, not like when I am actively testing someone else’s code.   
For me, it is it imperative to get someone else to test what I write, even if it’s just directions for a How-to guide, because there’s often a lot of “implicit knowledge” that goes on under the radar, and I need someone to make sure that I’m as clear as I can be, and that I’m explaining what is needed.
Bottom Line:
We are on the same team, and we have the same goals. We just approach it from different angles. Just like the house builder and the house inspector work towards a similar goal, their job is not to criticize one another’s roles. It’s to make sure that the house in question is comfortable, well designed, livable and safe for the pending occupants. We should do the same. For those who can program, you probably have already walked a mi
le or two in the programmer’s shoes. For those who don’t, you may want to consider learning how to do so; it’s a very enlightening experiences, especially when you are the one who’s putting their code up for scrutiny.