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.
Yeah, it can be silly or a little cute at times, but overall, the snarkiness between the camps, directed towards each other, brings out a bit of animosity that, for better or worse, cause unnecessary rifts and divisions.
The truth of the matter is, at least in the Agile software space, there is a sense of convergence happening, where the role of the traditional programmer vs. the traditional tester is being blurred. Many testers can and do program, and to say that programmers do not test is to be ignorant. There are distinctions between the two, to be sure, but they are not as distinct as we might think. They are complementary roles. One “creates”, the other “tries to break” or “finds what is broken” (we don’t specifically break software on our own). Even with those grossly simplified perspectives, there’s a lot of nuance that takes place between the stereotypes.
Workshop #81: Walk a Mile in a programmer’s shoes, and encourage a programmer to walk a mile in yours.
To really implement this, the tester in question will need to, or want to, actually have a good handle on how to program or have some programming chops to bring to the table. If you don’t have any, don’t despair, you can learn how to do a lot of good work with the bash shell or PowerShell in a surprisingly short amount of time. The point is, tackle something non-trivial. Put some effort into creating a utility, a tool, or some other option that requires you to go above and beyond what would be a “one off” script. A book that describes this process very well is “Build Awesome Command Line Programs in Ruby“. No you don’t have to choose Ruby to do this (though this book would be much more helpful if that is what you did actually use), but use the ideas in this book (or others) to see what it actually takes to create a utility that would be suitable for use by others.
Think about what it would take to do that. Think about what you would need to plan for, how you would design your utility, and how you would document or give hints to your users. Follow all of the conventions necessary for it to be usable to others.
– What did you discover about this process?
– Did you apply all of your testing skills to the code that you wrote?
It’s tempting to say “yes, of course I did” but I’m willing to bet that, if you are totally honest with yourself, you will admit that you deliberately short-circuited many of the inclinations that you have as a tester. Why? Because you are probably focused on “making it work”. You are iterating through, fixing issues, giving it the necessary focus and polish to make it a good app.
Now, hand your program over to two people.
First, hand it over to programmer, and ask them to evaluate the program. Don’t give them access to the source code, or at least, ask them to approach it the way a traditional user would. See what they test and what they don’t test.
Note: this is for your personal consideration and benefit. I don’t recommend jumping up and down on the programmer if they don’t look for the things that you feel you naturally would. You might be surprised that they test areas and scenarios that you personally, as a tester, might never have considered.
Second, give the same code to an experienced tester, and give them the same advice.
– What did they consider that you didn’t?
– How would you incorporate their feedback into what you do in the future?
Programmers and testers are both software developers. That’s the point of the Agile Manifesto (at least in my view of it). We do not do exactly the same things, and we approach the software from a different perspective, but it will help tremendously if we both have appreciation for what the other does. That means understanding what the programmer does to test their code and offer our insights where we can to help them. It also means getting into their domain and working with them when we can to understand what it is that they do.
Software testers, as I mentioned earlier, do not be afraid to learn how to program. A little programming goes a long way. Also, understand that, when I say a little programming, that’s what I mean. You do not have to commit to becoming a full stack developer. You do not have to commit to learning multiple languages and maintaining production code (unless you want to, of course). What I am saying is that we need to understand each other’s skills and what we bring to the table collectively, and appreciate that we need each other to be as effective as possible.