What makes a GREAT Tester?

Testing software is more art than science. I believe you can teach someone to write a program easier that you can teach them to adequately test the same program.

When you write an application you likely work from a set of defined specifications. These specifications are typically drawn up by non-technical application users.

To adequately test the same application not only to you have to come up with ways to test the defined specifications, you have test it for the unexpected, undocumented but not unlikely situations the users are likely to subject the application to.

You can teach someone to create a online form according to specifications, but how do you teach someone to think of all the likely situations an application’s users might come up with, let alone how to create test case to test them. It takes a special type of person to be a great tester. You have to be able to sense and keep the proper balance between multiple spectrums of personality.

What makes a great tester?

• They are passionate about testing but not as passionate as not to know when you’ve spent more time testing than the risk of error warrants.
• They are passionate about teaching good testing methods but know it takes more time to teach good testing methods than to just do it themselves.
• They love solving puzzles, but they know there are some problems that are beyond a tester’s ability to explain.
• They know that by learning and observing they will become a better tester. They never stop learning and they practice their testing trade everywhere. They learn to see more and understand more of their surroundings than people around them but they are still focused enough to get to ‘Get Things Done’ when needed.
• They take notes detailed enough to give the reader a mental picture of the testing session and defect but know that too much will keep them from ‘Get Things Done’.
• They know that not every bug will be found and fixed, but doggedly try to find and fix as the most troublesome defects before release as possible in the time they are given.
• They have a background in a variety of programming disciplines, but know that they do not and cannot know everything. They know a problem when they see it and can develop a plausible explanation for it most of the time.
• They know and use the best available tools, and realize what may be the best tool for one situation is not for another. And that the available tools change constantly.
• Beyond the expected results, they also report “FYI” results. The “FYI” results are those defects that go beyond the existing requirements, and may or may not be of interest to the project’s members. They understand it is not up to them to determine what defects are important to the project.
• They know when to say “NO” and they stick by it.
• They don’t terminate an issue just because they are unable to reproduce it, they think out of the box, and if necessary call for help to find an explanation for the issue.
• They actively work to improve themselves both technically and socially. And have taken steps to implement and ensure progress in both areas. They are well versed with the latest thoughts and theories and they set, track and accomplish their goals.
• They are creative and innovative in their testing but understand that most of the time the best solution is to work within an established framework. They know the boundaries and strive to stay within them whenever possible but will deviate from them when the benefits are undeniable.
• They take the time to plan their testing solutions before they implement them, and document their results before they release them. But realize that excess planning and documentation can inhibit their ability to “Get Things Done”.
• They are patient and understanding of both clients and project members, and demonstrate the ability to enlighten both, with advanced methods and concepts. But realize that their solution is not the only solution or even the best solution. They work together with the both clients and team members to arrive at the best overall solution for the given timeframe.
• They have the ability to accurately estimate the time and effort required to test a given set of requirements. But realize that requirements are rarely complete when given to be estimated. They plan for the unexpected and are not surprised or disappointed when the unexpected happens.
• They have the respect of both team members as well as clients and know what to do with it. They recognize and respect the abilities of all their peers and actively work with them to make them their very best.
• They realize communication between and among themselves, clients and developers is a key element in the successful completion of any project. They take active measures to enhance and insure adequate communication between all participants, without creating excess procedures which limit their ability to “Get Things Done”.

I’ve hit the high points of what makes a great tester but I know there are more that I haven’t touched on. In the spirit “Getting Things Done” I submit this to you for your comments. I hope I’ve gotten the balance right, but if not I hope you will let me know.

Sphere: Related Content