7 Things I hate As A Tester
Testing is fun.
In the product’s success, quality is very crucial.
The testing journey is filled with intriguing challenges and invaluable lessons.
Having spent two decades in software testing, I’ve witnessed the ebb and flow of methodologies, tools, and expectations.
In this article, I try to shine some light on 7 things I hate as a tester.
And I have seen many other testers also resonating with these.
Please let me know if have any other points to add.
Let’s go.
Here are the 9 things I hate:
- Unclear requirements.
Requirements are the base for developing product. Requirements can be in the form of Specifications or stories. In either case, they should be clearly mentioned and documented.
In my career, I have encountered many situations.
Where the foundation of a project, its requirements, appeared shrouded in ambiguity. Such vagueness is a double-edged sword, sowing frustration for both development and testing teams.
I have seen ambiguous requirements in some projects. That is really frustrating. For both the development team and the testers. If these requirements for the product are not clear, it can be difficult for me to know what to test.
This is specifically irritating of the new product. This can lead to missed bugs and a poor quality product.
Note: Without requirements also, we can test the product. That will be exploratory testing. I will write about it some other day.
- Unrealistic expectations.
Testers are custodians of quality. It is expected from everyone- the company, leaders, managers, product managers, users, customers and all other stake holders that the product released is of high quality.
Some times I have seen unrealistic expectations.
Stakeholders have unrealistic expectations about the quality of the product. I was in situation where I was asked to test and certify the product in a just 2 days !.
Mind you, that one was the major release.
The product had many new feature, important bug fixes.
This had put pressure on me and other testers to find bugs and to release the software before it is ready. Even if bugs were reported, they were pushed for next release !
Also about automation.
I have seen some managers expecting 100 % automation coverage. That is- all test cases should be automated.
*Also read : How I select test cases for automation?*
This is very rare. Not all test cases can be automated. Usually.
In my projects I would aim to achieve minimum 80 % of the test cases to be automated.
- No test automation.
I have also seen some projects without automated checking !
Testing is boring sometimes.
Because, I have to keep executing same test cases Again and again. The regression test suite, for example is executed for every release.
This makes testing a boring task.
Automating the checking process is the solution for this.
Test automation helps me to be more efficient and to find bugs quickly. However, not all organizations invest in test automation, which can make testing more difficult, boring and time-consuming.
It is some times frustrating to execute same set of test cases again and again.
- Unstable test environment.
Test environment matters.
The environment which I test should be stable enough. The environment must be consistent. And be available all the time.
I have faced issues with this.
In one of the projects I had worked, application was not accessible. The next day, application was accessible, but was failing to login.
After reporting, login issue was fixed. Later I found that it was giving 404 error whenever I clicked on any links. This situation is really frustrating. I had to keep an excel sheet with date and environment issues faced !
Time was running out for testing. But the QA environment was not stable. Testing was not progressing.
Also, some times I had to think a lot if the issue is a bug or environment issue.
An unstable test environment can make it difficult for testers to find the information they need and to run their tests effectively.
- Poor communication between teams.
Communication is king. Agree?
There should be clear communication between the teams. Product team should clearly document the requirements. Developer should request for any clarifications in those. Testers should report the bugs clearly.
Any deviation this can make a huge impact.
When there is poor communication between the different teams involved in the product development process, it can lead to problems with testing.
The communication is not only about requirements. It can be about the scheduling of the project release, just as an example.
I as a responsible tester, estimate testing effort and provide that info to all the stake holders. The product and development team also need to document their time lines.
I had faced this communication gap. Once planned product release date was not announced. But leaders and Product managers had discussed this and was not communicated to engineering team (development and testing teams). May it was a miss.
When product manager mentioned the release date in one of the meetings, all were surprised. Hardly 2 weeks were left when that was discussed.
Everybody had to slog in those 2 weeks.
Time available for regression testing was only one day. You read it right. ONE day. I had to change the testing strategy and only had to perform risk based testing.
Read: How do I do regression testing?
Huh..frustrating !
- Lack of resources.
I need to have all tools to test.
Testers often need access to specific resources, such as hardware, software, and documentation, in order to do their job effectively. However, not all organizations provide testers with the resources they need.
In one of the projects, I had to test on multiple platforms. So, we had requested for iPads to test and certify on iOS. But due to SLA issues, we could not get the physical devices. Had to rely on simulators.
Testing on simulators is good. But it is not same as testing on physical devices. Later many bugs were reported by users in production. These were not reproducible in simulators.
So, not having proper resource is really frustrating.
- No career growth opportunities.
Now, this is personal growth.
I work for myself and my company. I want my company to grow. Also, I want myself to grow. Who doesn’t want to grow?
Like me, many testers feel that there are limited career growth opportunities in testing. This can be demotivating and can lead to testers leaving the company.
The organization culture should recognize the great work. Leaders and managers should motivate the team by giving away awards, regular promotions, giving more responsibilities.
Conclusion
These are some of the challenges I’ve faced in my long journey as a tester. And I hate to face them again in future. I hope these mini stories help you understand the testing world a bit better. Remember, every challenge is a chance to learn and become a better tester. Keep exploring, keep testing, and never stop learning!
You will learn more by reading my newsletter !
If not subscribed, do subscribe to my weekly newsletter
Follow me !