Sometimes, for various reasons, there are a lot of expectations that we set for ourselves that aren’t always true. These expectations often lead to a lot of disappointment and distress because none of them are going to be met, as they weren’t valid in the first place.
Today we want to list a few of them and also in a way start a forum for discussion on what the rest of us testing professionals think regarding this topic.
My personal experiences in the following areas listed tell me that I am on to something. But I would seek all of your opinion all the same. I invite you all to participate.
What You Will Learn:
First here goes my top 3 Misconceptions:
Automation testers do not have to bother themselves with manual testing
Nothing could be more far-fetched than this statement. Automation testing, as we stated repeatedly on STH, is testing also. It only differs in the area of how testing is performed. It also should not be forgotten that, automation testing always succeeds or follows the manual testing process. Sometimes, automation testers and manual testers are the same. Also, not all projects are automation projects.
So, we are testers first, and it is important to remember that before we make the specialization our main area of focus.
Having worked on one automation project does not and ideally, should not ruin us for manual testing. Manual testing is a skill that we all build on; it is the fundamental and our foundation. Automation testing is great. It is the closest thing to magic we have in our QA field. But considering one to be inferior or superior to the other is not the attitude we want to see in the field. Automation testers perform a manual testing role in some projects and manual testers perform automation in other cases. They are not mutually exclusive. In fact, the differentiation of testers as manual testers or automation testers is quite disturbing. Let us not encourage this culture.
Test leads do not ‘test’
I had a colleague at a client located in the US, where we were both handling a module each in a project. He had 3 offshore resources reporting to him and whenever he made effort estimates or test plan, he always did so taking into consideration only 3 people for test design and test execution. When this came up in an audit meeting and he was asked why he was not counting him (my colleague) to be involved in these activities, his answer baffled many of us. He actually thinks it is beneath him as a test lead to write test cases and execute them. He would not bother with those tasks because he thinks they are ‘lowly’ and that he would only overlook or coordinate the process.
What followed in the meeting is not relevant to us, but let me tell you that he is not alone to feel that way.
The reality is that, the industry standard for coordination efforts is just 10%. Test lead is also, always a part of the QA team, which makes a lead responsible for contributing to the testing activities. Agreed, there are other tasks as well. So, a percentage of the QA lead’s bandwidth, however small it might be must go towards testing activities. We have to prepare yourself to be a tester doing all the tasks you would normally as a QA team member for the rest of our careers, or it might be time to consider a switch in fields.
Testers doubt everything and that are the forever ‘skeptics’ in the IT industry
Imagine how difficult life would be when if we did not trust anything. A skeptic’s life is the toughest to live. If it were true that we doubt everything – we would even be questioning the very existence, implementation and efficiency of the software – which means we are working while believing that the product is useless. Do you think that’s the right attitude? Can we really do justice to spending a good amount of time working on a software system while we think it is absolute garbage? I think not.
When in need for some guidance as to what kind of mindset is best, the quote by a former US president, Ronald Reagan comes to mind –“Trust, but verify”. Even though the context is completely different, this hits home like nothing else would.
Therefore contrary to popular belief, we testers believe in the software’s ability, performance, efficiency, productivity, its purpose & capabilities and we always root for its success when it hits the live world.
But, we want to make sure that it is at its absolute best. We test keeping in mind, that the product is great and that we need to identify and remove anything that might negatively impact an already terrific product. We actually believe in it and are ardent fans of it. Isn’t that true? It is for us and we are sure that it is the same for you too.
We hope that this article has put to rest some rumors that have been going on in the IT circles about the QA community. (Just kidding..!)
What do you think on the above list? Agree? Disagree? Somewhat agree/disagree?
About Author: This post is written by STH team member Swati S.
As we mentioned in the beginning of the article, we hope this post would be a great initiation for long, productive, enlightening discussion on the subject in the comments. Common, let’s hear it.