We all heard the story of the little frogs in the well who thought the world is the well until they came out and realized how big, beautiful and different it is!
Do you think you have lived this story at some point in your professional life? Well, everyone has. Welcome to the world of reality – beautiful testing :).
Today, I want to share 4 mistakes I made when I started my software testing career. You’re Probably Making These. Check out.
What You Will Learn:
- The 4 Most Common Mistakes That Software Testers Make
- #1. Asking questions is not always necessary
- #2. Automation is tough to learn and takes lots of time
- #3. Documented test scenarios include everything and I need not think beyond them
- #4. I am here to find bugs and not to analyze patterns
- Recommended Reading
The 4 Most Common Mistakes That Software Testers Make
As a tester, how many times in your career did you think the following?
#1. Asking questions is not always necessary
We all have inbuilt weaknesses. According to a popular survey, the most common weakness in adults is the fear of appearing silly. Unrealistic fear blocks our growth. Assuming rather than asking is what we are taught.
While testing an online ticket booking application, a tester observed that the user was not allowed to cancel the booked tickets at least until 24 hours have passed since the booking was made. Now, from the end user’s perspective, this is totally unacceptable. But instead of questioning the behavior, the tester assumed that it might be the requirement. This one wrong assumption led the application to fail in the market.
A tester friend, well-known for his question-asking style, once told me that he was laughed at for asking questions about almost everything from coding logic to bug tracking system to how the bug was resolved. It was beneficial to him because he was developing self-confidence and clarity about things.
Never hesitate to ask questions and presenting your view point. As a tester, you have all the rights to ask questions about application’s behavior and its real-time usage data.
#2. Automation is tough to learn and takes lots of time
“Automation” is the word that still gives a sick feeling to many testers.
Many still think –
- Learning automation might take time
- Automation is tough to learn
- Automation is not useful
This is nothing but an unreal fear of change, fear of learning new things, and fear of getting out of your comfort zone.
I would advise you to learn automation testing and keep learning if you want to shape up your career and want to grow fast in this demanding industry.
#3. Documented test scenarios include everything and I need not think beyond them
The trend that was followed so far is- explore requirements, understand functionality, brainstorm, document test scenarios, and send them for review. Once the review is done, testers follow the documented test scenarios. The real-time exploratory testing seems to be of no use as the brainstorming was already done at the time of documentation.
Once the review is done, testers follow the documented test scenarios. The real-time exploratory testing seems to be of no use as the brainstorming was already done at the time of documentation.
This is a totally wrong approach. Let me give you an example,
You are looking at a painting and you continue to look at it for 10, 30, 60 minutes and so on. Initially, you found the painting good but with prolonged exposure to it, you start realizing the flaws in it. After staring at it for 60 minutes, you feel like you know the painting for long and you know all the flaws and positives about it. Leave for the day.
Next day, look at the picture again. Did you notice that color mixture at the corner yesterday? Does it seem ok? Don’t you think that wrong color mixture is actually ruining the overall effect of painting? Surprised that you did not notice it yesterday? Well, that happens. Every day brings us new perspective and new view and with that we look at things differently.
I hope the example clarifies my point of not relying on documented test cases while testing.
Try to do something spontaneous and note the application’s reaction.
#4. I am here to find bugs and not to analyze patterns
We are always taught to mind our business and somehow we are convinced that our business is to find bugs. Anything other than that does not fall into our responsibility range.
Let’s change that mindset today with the best example that I have been using for years.
A newly opened restaurant has no customers even after trying hard. They called an expert to analyze the situation. The analyzer sees that the restaurant does not get any repeat customers despite the variety, ambiance, price, etc. He contacted the one-time customers and from their feedback, he came to know that customers did not like the food (any variety of food) as it was tasteless. New and experienced chefs were appointed immediately and the restaurant now sees waiting customers.
Our role as a tester is similar to that of the analyzer in above situation. We do not need to point out what is wrong but we need to analyze which are the other points that might have been affected due to the bug and is there any pattern of that bug in the application.
With experience, you are expected to provide analytical details rather than just limited testing.
The idea behind this post was to guide the new testers and to remind those old bees that the industry, the demand, and the expectations are changing.
Keep yourself updated, keep learning new and in-demand skills, share knowledge, information and problems, never hesitate to demand better quality and be always ready to contribute for the same.
About Author: This inspirational post is written by STH team member Bhumika M. She is a project lead, carrying 10+ years of software testing experience. She is totally into testing and loves to test everything exists.
I hope these mistakes of my life as a tester will help others to not repeat them.
Are you making these mistakes in your testing career?
As usual, happy testing :)