Tuesday, February 21, 2012
10 reasons why You are NOT a Professional Tester - Part 2
A look back at the first 5 reasons
I believe that at least part of the reasons why You are NOT treated as a Professional Tester in your company are:1. You think testing is not a technical profession, and so you don’t even try to understand the code behind your product!
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”.
3. Your only interaction with a Customers is when your Support Team asks you to reproduce a bug from the field.
4. Risk management is something you practice only in the context of Life Insurance.
and
5. You don’t have a plan to improve the value of your testing.
Now a look at the next 5 reasons
Why You are NOT a Professional Tester!
6. You
think your job is mainly about writing and running predefined Test Case
Scenarios
There is so much more than only running scripted tests:
- Providing feedback on the design of your application.
- Analyzing the Risks of your current development plan and project.
- Providing informal feedback during the development stages.
- Developing an automation framework that will help your developers maintain the stability of the product while they work on it.
- Running tests, but definitely not only those you scripted before hand.
- Analyzing the results of your tests and the rest of the information available to you, to provide insights into the status of your product.
- Providing feedback on the process.
And I could go on & on…
In short, the value of your job goes way beyond executing test-steps and setting them to pass or fail!
7. Automation (and scripting) is an Advanced Science, and a project you will work in the future – in your spare time.
STOP coming up with excuses why not to work on automation!!
This is another side of the technical shortcomings of some testers but from a different perspective.
Automation is not a magic pill or the cure to all the problems faced by testers, this is only a sales-pitch-lie from many tool vendors. But still, there are times when using scripts or tools to do part of your dirty-work will make it more efficient and save you time.
The problem is that, again here, some testers feel they are not technical enough to do this, and so they choose not to use automation or scripting to improve their testing. In a sense it is like striking stones or rubbing sticks to light a fire, and refusing to use a lighter while saying that for you it is easier this way…
8. You do most of your testing while standing high on top of you Ego
A good tester is a humble tester! We need to know how to provide feedback, and even more importantly how to receive feedback from teammates and peers.
Many testers get frustrated when team members (specially programmers) give them unrequested feedback on their testing, or when they are queried on a bug that was not found or a test that was not run. Many times there are good reasons for all these “misses” and we only need to keep calm and share this information, but lot’s of testers take these questions as personal attacks on their professional integrity and reply with loud tones or harsh words.
In the same way as you need to know how to report your bugs and provide negative feedback to your project team, you need to know how to receive constructive criticism from your peers.
No one expects you to be perfect, but they expect you to be professional about your mistakes and to learn from them as well as from the feedback you get from the team.
9. You don’t keep track of your professional skill set and the areas where you need to improve next
One of my best managers in the past used to talk about our personal “Virtual Toolbox” as the set of skills each of us carries with him and uses when needed.
Do you know what tools you carry in your toolbox?
- What tools are in need of improvements or updating?
- Which are the tools that you keep needing, and that you may want to acquire next in order to improve the quality of your work?
Testing is without a doubt a craftsmanship, and without the proper tools (virtual and actual) you will not be able to create the required product.
10. The only idea you have about a career path involves becoming a manager or moving on to another career
Some people get into testing because they think it is a good path into programing. Others do because they don’t know what testing is about and it sounds cool to “play” with applications all day long. After all, how hard can it be, right?
Part of them can end up been good testers (at least I hope that I did!). But most of them will end up frustrated, counting the days until they can stop testing and start doing the work they really wanted to do. While others don’t appreciate the real challenges of testing, and think the only way to move forward is to start managing people.
It is true there are challenges and rewards to managing a testing team, but there are also countless disciplines to conquer that are not related to management and that may give you even more challenges and bigger rewards (and definitely a lot less headaches!)
My point is that, if all the time you are looking to do something else and not focusing on how to test better, there is no way you can do it more professionally. So think if you are in the right place, or if maybe you should simply be looking for something else…?
Want to be professional? Start by looking at testing as a profession!
Looking at these ten points from 20,000 feet I think the line connecting them is the call to change our general approach to testing.The first step is to start considering testing as OUR Profession.
Once we absorb this first step, the second one is to look at what we are missing in order to become better testers. What areas should we develop? How do we need to approach our work and the relationships with our customers and teammates? And what can we do NOW in order to increase the value of our work?
The third and last step (at least for this short approach) is to plan ahead how to improve, and to realize that as a profession we have much to learn before considering ourselves gurus or experts (if there is such a thing…)
The important thing is to realize that the change needs to come from within, and not from some God-given decree or from the title next to the name in our email’s signatures
10 reasons why You are NOT a Professional Tester - Part 1
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.
To be continued in the next post…
8 Tips For Effective Testing
The result of work is not determined by the time expended on it. Moreover, labor costs and the result aren’t related anyway, especially in testing.
Work on result rather than on increasing of amount of work. And prioritization of tests is the first and the most important step in this direction.
2. You should always document the priority of functionalities, coordinate it with PMs and analysts.
3. If there are tasks with different priority levels, you should always check the task with a higher priority (if it is possible, and if tasks are independent).
4. The tasks should be better done in turn. You need to do one task, to finish it and to move on to the next one (if it is possible). Because:
- there is less overhead by switching between tasks
- a result appears earlier on one problem at least (or else we have 10 tasks, performed 85%, with no benefits).
However, the situation changes if the tasks are interdependent .
5. We put emphasis on the word “document”! .. If the release is the day after tomorrow, and everyone is in hurry, then no one will remember verbal agreements, and a high-speed buttons clicking will begin. It’s more important for you to check the efficiency of the basic functionality.
6. Make it a rule – Big tasks should be divided into smaller ones. Determine their priority and sequence. Otherwise you’ll risk to face a chaos.
Create a set of tests:
- What should necessarily work ;
- What should work by release;
- What should work only operatively.
7. As a result, you can appreciate the efforts required for a release build testing – and not the time spent by aimless interface clicking.
8. If you have prioritized your tasks, you can always say that you don’t have enough X man-hours for verifying the tests with the Y priority.
Traditional and Modern Way of Software Testing
Traditional (old) way of software testing:
- Requirement
- Design
- Code & Build
- Testing
- Maintenance
For example, fixing an error in maintenance is ten times more expensive than fixing it during execution.
But many organizations have improved this way of thinking and choose modern way of software testing. In this philosophy testing should take place in every stage.
Modern way of software testing:
- Requirement => Testing
- Design => Testing
- Build & Execution => Testing
- Test => Testing
- Installation => Testing
- Maintenance => Testing
·
In the requirement stage software
tester can check if the requirements are met according to
the client’s wants.
·
In the design phase tester can verify
whether the design document covers all the requirements. In this phase it is
also possible to generate rough functional data. Software tester can as well
review the design document from the architecture and the accuracy perspectives.
·
In the build and execution phase testing
team can execute unit test cases and generate structural
and functional data.
·
In the testing stage we can run the
system test cases and verify whether the system operates according to the
requirements.
·
During installation software tester need
to check whether the system is compatible with the software.
·
Conclusively, in the maintenance stage
when any fixes are made QA team can retest the fixes and follow the regression testing.
Subscribe to:
Posts (Atom)