This third post on the use of titles for software testing focuses on being a tester. Not that if you are a software test engineer or in software quality assurance (previous posts) you do not test or can think of yourself being a tester. In my model however I am making a distinction. I believe that being called, or calling yourself, a tester affects the way you see your function or role in such a way so that it is different from that of being a test engineer or quality assurer.
So what is a tester?
Well to be honest it differs. To start-off I see two sorts of distinctions to be made in defining what a “tester” is. The first one has to do with how you approach the title. From an employers perspective, for instance, looking for a “tester” often means that the employer has not felt the need to be more specific. So a tester in this situation can be anything from a software engineer, a quality assurer or all the way up to someone pushing keys for a test that someone else scripted. As uninformative as the job title might be the job description that goes with it usually is much more descriptive. It will tell you if the company favors testing as engineering, quality assurance, as something tailored to their needs or simply as any other job.
That “any other job” approach to being a tester forms the first part of my idea of how testers see themselves. To some testers being a tester really does not mean much more than doing what the “boss” asks you to do. Perhaps that they have an affection to IT or a nag in analyzing stuff, but generally they just as likely could have been doing a completely different job to make a living or to build a career.
This section of the model represents the any-job paradigm
The any-job paradigm does not mean you are bad at wat you do. It’s just that you are not doing it to be a tester. You do it because you need the money, you are on route for something higher, you happened to end up there, or for whatever other reason. And now that you are a software tester you will do that for as long as nothing better comes along. You will most likely even educate yourself to what you perceive is essential or to a level someone, that matters, tells you to. But since your heart is not in it, you go for “proof of knowledge” by showing attendance lists or certificates and likely value that over the actual use of practical knowledge.
My kind of tester
In contrast to this I see a tester who even if he became a software tester by chance, now that he is puts his heart into it. This kind of tester educates himself to get better, he follow trends by reading magazines, blogs and testing books. He visits conferences, workshops and discusses testing with his peers. This tester thinks of his job as a skilled craft. A craft that continuously requires his skills to be sharpened.
This section of the model represents the craftsmanship paradigm
I am sure there are testing engineers or quality assurers that perceive what they do as skilled and they also educate themselves and go to conference. The essential difference however is that a software craftsman goes the extra mile. He does not limit his focus to a technical or process approach. A software testing craftsman has a wider view upon the world. He also gathers technical-and quality assurance skills, but just as likely he gathers analytical, social, management or other skills. Furthermore he does not value one over the other. He lets the usefulness depend on the problem to solve and to the context in which it occurs.
Currently I like to think of myself as a, context driven, software testing craftsman. At what level of craftmanship I am I leave for others to judge.
I do not see my self as a master in software testing yet.
I am however aiming to get there….