Over the last six months our project has deployed 2 major releases and 2 minor releases. Depending on how your organization is structured, Requirements analysts may or may not be part of the testing efforts. I have been fortunate to work closely with the testing teams as we tested and eventually deployed our solution.
I have developed a deep appreciation of the art and craft of testing from working with these talented people. Much like crafting good requirements is an art form, so too are is crafting and executing a good test plan. Here is my layman’s view on what makes great testers.
For starters, a good tester has to view the world very differently from a Requirements analyst. We instinctively look at the world in a constructive way – how do I build something that helps my users and meets their needs. Testers instinctively look at the world in a deconstructive way – how do I take this thing apart, push, pull and tug at it to see if it holds up or simply breaks into a thousand pieces. My initial encounters with them were a bit stilted since I was coming at them with a completely different world view. But once I got over this, the encounters became downright enjoyable in a perverse way as I tried to anticipate how they were going to break this thing I was trying to build.
Good testers instinctively go for the corner conditions or exceptions. I am convinced that the good testers never read the Normal Flow of Use cases. They go straight for the Alternate flows and exception cases. And then they identify a host of alternate paths and exceptions you would never have dreamed of in a million years. Not all of them are necessarily valid but they get you thinking in ways that a structured mindset finds hard to do without some prodding and encouragement.
Good testers behave like users. So what is the big deal in that? Well I have learned the hard way that users do not necessarily think or behave in a structured, rational and predictable way. Implicit in all requirements are assumptions about user behavior when they use the finished product. Good testers challenge these implicit assumptions and make you reconsider your world view and how the product should be designed and built.
Good testers are thorough. This is one of the fascinating aspects of the tester psyche. On the one hand is a seemingly pathological desire to break things and behave like a toddler in a toy store – touch, poke, grab, pull and tug at anything in sight with little or no predictability and leave a path of destruction behind you. On the other hand is an almost regimental rigor and thoroughness to their efforts – a method to the madness. It is this ability to hold these totally contradictory impulses in their heads at the same time that makes them good at what they do and unique.
Good testers see the big picture. It is easy to get narrowly focused on your little part of the project or development and miss the big picture in terms of dependencies, unintended changes or impacts to other downstream systems and other similar nastiness. Good testers understand that they are testing a feature but also the whole application and switch between these two world views constantly.
So, if you put all of this together, you end up with a great tester. They perform a little understood or appreciated function. But having worked closely with them, I have developed a deep respect for who they are and what they do.