The simple job of a Tester

Let me start by apologizing to my tester readers, since most of this post may seem trivial to you, but this one is for those of you who are not testers and fail to understand what we do for a living   –   Dear testers, feel free to forward this one to your developer friends 🙂

What is so difficult about being a tester?
This is a legitimate question from someone who has never done any good testing or who has never seen good testing being done.  So let’s take a closer look at what a tester needs to do as part of his tasks and what does that require from him with regards to skills and knowledge.

Before he even starts the “testing stuff” a tester needs to ensure that the story or spec actually fits-in with the rest of the application from a functional perspective, this is actually a “dry test” to validate we are developing the right feature with regards to the current product context. To do this a tester needs to understand the application from end to end and also to have a clear idea of how his users work with it, in contrast to a programmer who may be able to write his features correctly without even knowing what they do in the complete scheme of the system being delivered.

Also before he writes his first test or presses any link in his application he needs to make sure the feature has been specified properly and the description provided is not ambiguous or incomplete, assuring that all the stakeholders are in sync and lowering the chances of developing product “3xA” when the user actually wanted “A-A-A“. To do this correctly a tester needs to have the proper communication skills to contact all stakeholders (internal and sometimes externally) and understand that everybody is “in the same page”.

When a tester actually gets to the point of planing and executing his tests he needs to be:
– Part Jack the Ripper to “think” like the bugs and find them wherever they hide.
– Part Sherlock Holmes to tie all the clues together and understand the (elementary and) underlying issues in the system.
– Part CSI to analyze the evidence and point at the possible suspects.
– Part Oprah Winfrey to present a problematic issue in a way that doesn’t offend anyone and allows the team to solve it and move forward
– And finally part Cirque de Soleil acrobat to juggle 7 tasks while walking a tight-rope blindfolded, and still make it look easy and natural..

All through the process the tester needs to be able to detach himself from his ego and have the professionalism and the maturity not only to be self-critical of his work but to proactively seek this criticism from every other team member allowing him to run the most effective and efficient tests. At the same time he needs to be a master politician to provide criticism to his peers without making them feel degraded or insulted.

Once the project reaches its critical dates, a tester needs to become a mix between a navy-seal an ice-cold assassin and a magician; to adapt to all terrains and perform his duty in constantly changing environments, to work under the pressure of project members who all-of-a-sudden remember that the deadlines are inflexible, and to always find a way (either by relativistic quantum mechanics or sheer magic) to fit a 3 week testing schedule into 5 working days.

And if all this wasn’t enough, many times we as testers need to have skin as thick as an elephant not to get hurt by all the accusations of the things we did or didn’t do during the project, and the memory of a gold fish to forget the nasty comments thrown our way by developers or managers while “in the heat of the moment” (even if later on they come to apologize for them).

So if you ever thought testing is easy and any person from the street could come and do the same job your testers are doing I suggest you think about this again, or even better spend 1 week working with your testing team to understand how easy it really is…

About PractiTest

Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.

Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.

With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.

4 Responses to The simple job of a Tester

  1. ElizaF September 21, 2010 at 2:06 pm #

    Dammit, NOW you tell me. I got into software testing 15 years ago because I was told it was an easy job.

    Now you are maintaining that this role is about more than following testcases ??!! (scripted by someone else of course!)

    Suddleny all the cursing and frustrated faces I seem to have been surrounded by for the last decade and a half make sense …. whoops!

  2. Joe Strazzere September 21, 2010 at 12:44 pm #

    Well done, Joel.

    It's interesting that so many people say to themselves “What's so difficult? I could do that!” when they think about particular professions.

    I used to think that about marketing and advertising, until I worked with people who actually held those positions, and learned what it was that they actually did.

    Being in such a profession, it's difficult to convey to others what's involved. I will forward this article to friends from now on.

    And here's a list of what some of my testers do:

  3. joelmonte September 21, 2010 at 1:04 pm #

    Thanks Joe!
    I liked your list.

    It is pretty amazing how we as testers get to do so much stuff directly and indirectly related to testing-the-product as part of our jobs. In a way this is one of the reasons I enjoy testing so much.

    Good point about all other professions, it only comes to prove the saying that you can't judge someone until you've walked in his shoes.



  4. joelmonte September 21, 2010 at 8:12 pm #

    Laugh about it all you can…

    I wrote this one due to a conversation I had yesterday where I explained for 30 minutes to a group of dev leads why they cannot take their “weak programmers” and ask them to test the product (way bellow even running pre-written scripts 'cause they don't believe in wasting time no this anyway, of course!)

    BTW, 14 years ago the guy who hired me to be “The Tester” in his company thought exactly like this. During my first day in the office he took the computer of a guy who was out sick, logged into the product, did a 10 min walk-through, and asked me to “go and find the bugs”. I was a second year student of Industrial Engineering who the day before had been introduced to the fact that software should be tested (as part of my interview for the position). I guess some things never change 🙂

Leave a Reply