Are you a Professional Tester?
Chances are
that if you are reading this post you are…
And I don’t mean this because I wrote this post – there are countless other testers who have better stuff to share than I do!
I mean in general, if you are reading a QA-related article in your free time in order to improve your testing skills, you fall into the small (& hopefully growing) number of engineers determined to be Professional Testers.
There were answers ranging from “because testing is not formally taught in Universities” and all the way to “because testing is new and people are still learning how to do it professionally“.
I searched in vane for someone to come and throw the blame back at us, the testers, saying the reason we are not considered a profession is because many of us are not professionals in the way we do our work.
But I guess people were too busy been self-pitying and unjustly-victimized in order to notice that most of the blame resided on us.
Based on my limited experience, everywhere I’ve seen testers taking their work seriously and striving to improve intelligently, I’ve also seen how they were treated with respect and how their work was appreciated thanks to the value it provided to the Organization.
So to the point:
1. You
think testing is not a technical profession, and so you don’t even try
to understand the code behind your product!
If you work on Software Development you should understand at least a little about software engineering.
As a tester, you need to be able to read code in order to analyze your product and understand how changes and fixes can affect it and cause additional bugs. The days of hiding behind “black box” vs. “white box” testing are over.
You can still get away without writing any code if you don’t want to, but as long as you refrain from reading the code you will be missing a very important input to your overall testing process.
2. You are not involved in the process until you are hit in the head with a build by development and told to “go and test it”
Answer yourself truthfully: When do you start getting involved in the development process?
In theory we’d like to start during the requirements gathering and analysis phase, together with the rest of the team. But in practice we hardly provide any inputs before we are “hit in the head” by the first build from our developers looking for feedback on their features.
Why does this keep happening? Most testers will say that it is because of the “viscous-circle” of been the last link in the development chain; we are always extremely busy testing when “the others” start planning.
But in truth, if you cannot spare 2 hours a day to take part of a feature design meeting it means you are a lousy time manager. It also means that the only reason you are not part of the development process earlier is because you don’t make it a priority; or in other words because you don’t want to!
3. Your only interaction with a Customers is when your Support Team asks you to reproduce a bug from the field.
Part of your job description is to test your product based on the way it will be used on the field and to catch the bugs that will be important to your users once the product is released.
In fact, your job is to be your customer’s advocate within the development team. To plan your tests and set up your environments based on their working behavior. You are also expected to provide functional feedback based on their needs and constraints.
If this is the case, then how can you simulate field work and represent your users if you don’t know them? When was the last time you visited a user to understand how he or she uses your product? Can you really relate to the work they do with your system and with the constraints of their working environment?
I guess the answer is NO.
Go and visit some of your customers! Until you know and understand your users, you will keep doing a lousy job as a tester.
4. Risk management is something you practice only in the context of Life Insurance.
There are a small number of simple truths in testing; maybe the most trivial of them is that “no tester will ever have enough time to test everything”. This is where Basic Risk Management comes into play, helping us prioritize our work in order to know what needs to be tested (and tested first) and what can be assumed to work based on the results of other tests.
But as I said, this is only the basic side of Risk Management… The more advanced side of it, and one that provides no less value to your team is the one that is not directly related to testing at all!
Every testers knows there are areas of his product that are more risky; areas where there are always more bugs and where the work of the team is always delayed due to unscheduled and unplanned circumstances.
It is part of our job as testers to be aware of these areas and remind the team about them during all stages of our projects. This way we can choose whether to develop the features using different areas of the product, or if necessary schedule more time to stabilize the system, accounting for these “unplanned issues” that will always present themselves.
You should strive to shed light on the issues, whether existing or potential, affecting your product. Helping the team to set realistic objectives and reach your goals on time and on budget.
5. You don’t have a plan to improve the value of your testing.
The Testing Profession is in many ways uncharted territory. There are many paths that will take you into testing, and as many ways to improve professionally once you are part of the Testing World.
Most of these “testing improvements paths” are individual, and will be a mix of the individual capacities of the tester, together with the needs and constraints of his current workplace, and the information sources available to him at the present time.
In short, there is no ONE WAY to develop yourself professionally as a tester, and these improvements will not be easy or come quickly. So, unless you decide you want to seriously invest in your development process, and only after you understand how to achieve this goal, will you be able to really improve your testing skills and the value you provide to your organization.
How do you achieve this?
Start by mapping your strengths and weaknesses as a tester, then decide what areas do you want to develop (that will also be valuable to your Organization), and finally look for the means available to you to develop these skills.
One thing is certain, it will be completely impossible to improve if you leave it to chance, or to another tester to tow you along during his personal development process.
And I don’t mean this because I wrote this post – there are countless other testers who have better stuff to share than I do!
I mean in general, if you are reading a QA-related article in your free time in order to improve your testing skills, you fall into the small (& hopefully growing) number of engineers determined to be Professional Testers.
In search of the Perfect Excuse
Last week I saw another discussion in LinkedIn asking “Why is testing not considered a profession?“ by many people in the Industry.There were answers ranging from “because testing is not formally taught in Universities” and all the way to “because testing is new and people are still learning how to do it professionally“.
I searched in vane for someone to come and throw the blame back at us, the testers, saying the reason we are not considered a profession is because many of us are not professionals in the way we do our work.
But I guess people were too busy been self-pitying and unjustly-victimized in order to notice that most of the blame resided on us.
Looking for the answers in the mirror
Let’s be honest, wherever we are not treated as (testing) professionals it is because we have not made it a priority to behave like professional testers.Based on my limited experience, everywhere I’ve seen testers taking their work seriously and striving to improve intelligently, I’ve also seen how they were treated with respect and how their work was appreciated thanks to the value it provided to the Organization.
So to the point:
What are the 10 main reasons
you are not a Professional Tester?
1. You
think testing is not a technical profession, and so you don’t even try
to understand the code behind your product!
If you work on Software Development you should understand at least a little about software engineering.
As a tester, you need to be able to read code in order to analyze your product and understand how changes and fixes can affect it and cause additional bugs. The days of hiding behind “black box” vs. “white box” testing are over.
You can still get away without writing any code if you don’t want to, but as long as you refrain from reading the code you will be missing a very important input to your overall testing process.
2. You are not involved in the process until you are hit in the head with a build by development and told to “go and test it”
Answer yourself truthfully: When do you start getting involved in the development process?
In theory we’d like to start during the requirements gathering and analysis phase, together with the rest of the team. But in practice we hardly provide any inputs before we are “hit in the head” by the first build from our developers looking for feedback on their features.
Why does this keep happening? Most testers will say that it is because of the “viscous-circle” of been the last link in the development chain; we are always extremely busy testing when “the others” start planning.
But in truth, if you cannot spare 2 hours a day to take part of a feature design meeting it means you are a lousy time manager. It also means that the only reason you are not part of the development process earlier is because you don’t make it a priority; or in other words because you don’t want to!
3. Your only interaction with a Customers is when your Support Team asks you to reproduce a bug from the field.
Part of your job description is to test your product based on the way it will be used on the field and to catch the bugs that will be important to your users once the product is released.
In fact, your job is to be your customer’s advocate within the development team. To plan your tests and set up your environments based on their working behavior. You are also expected to provide functional feedback based on their needs and constraints.
If this is the case, then how can you simulate field work and represent your users if you don’t know them? When was the last time you visited a user to understand how he or she uses your product? Can you really relate to the work they do with your system and with the constraints of their working environment?
I guess the answer is NO.
Go and visit some of your customers! Until you know and understand your users, you will keep doing a lousy job as a tester.
4. Risk management is something you practice only in the context of Life Insurance.
There are a small number of simple truths in testing; maybe the most trivial of them is that “no tester will ever have enough time to test everything”. This is where Basic Risk Management comes into play, helping us prioritize our work in order to know what needs to be tested (and tested first) and what can be assumed to work based on the results of other tests.
But as I said, this is only the basic side of Risk Management… The more advanced side of it, and one that provides no less value to your team is the one that is not directly related to testing at all!
Every testers knows there are areas of his product that are more risky; areas where there are always more bugs and where the work of the team is always delayed due to unscheduled and unplanned circumstances.
It is part of our job as testers to be aware of these areas and remind the team about them during all stages of our projects. This way we can choose whether to develop the features using different areas of the product, or if necessary schedule more time to stabilize the system, accounting for these “unplanned issues” that will always present themselves.
You should strive to shed light on the issues, whether existing or potential, affecting your product. Helping the team to set realistic objectives and reach your goals on time and on budget.
5. You don’t have a plan to improve the value of your testing.
The Testing Profession is in many ways uncharted territory. There are many paths that will take you into testing, and as many ways to improve professionally once you are part of the Testing World.
Most of these “testing improvements paths” are individual, and will be a mix of the individual capacities of the tester, together with the needs and constraints of his current workplace, and the information sources available to him at the present time.
In short, there is no ONE WAY to develop yourself professionally as a tester, and these improvements will not be easy or come quickly. So, unless you decide you want to seriously invest in your development process, and only after you understand how to achieve this goal, will you be able to really improve your testing skills and the value you provide to your organization.
How do you achieve this?
Start by mapping your strengths and weaknesses as a tester, then decide what areas do you want to develop (that will also be valuable to your Organization), and finally look for the means available to you to develop these skills.
One thing is certain, it will be completely impossible to improve if you leave it to chance, or to another tester to tow you along during his personal development process.
No comments:
Post a Comment