Did you do any mistake recently?

I did.

But we’re all humans, right? And we’re all likely to make mistakes. Usually people associate making mistakes with punishment which in most of the cases is the immediate action after a mistake is made. And seeing the good part in it is almost impossible, at least while you’re struggling to repair what you did wrong.

Making mistakes can have a positive impact on your professional growth, the only condition is to learn a lesson from the mistakes you’re doing. And during the learning process is almost impossible to avoid making mistakes.

Making mistakes is a lot better than not doing anything. — Billie Joe Armstrong

There is no activity domain in which you’re more likely exposed in making mistakes than in others. Below is a list of mistakes a software tester is exposed to during his/her work lifetime and from which can learn several lessons.

1. Incorrectly evaluate the risks

The job of a tester rely much on identifying and risk mitigation. A good risk analysis can help in identifying what can go wrong with the product you’re testing before it goes to production.

Identifying the areas of concern can massively reduce the costs and time spent afterwards in fixing problems found in later stages of development.

2. Miscommunicate the impact

Miscommunication is always a mistake, even we’re talking about miscommunicate the impact of a bug, the presence of it or any situation that might jeopardise the quality of the product we are testing.

3. Ignore a bug when you see it

Ignoring things like miscommunicate them should never happen. As testers we must address any situation we’re facing — even if we don’t have solutions for these situations or maybe don’t have the bigger picture, it’s better to make them known than to act like the elephant is not in the room.

4. Using the same test data — pesticide paradox

Executing our testing scenarios using the same test date might lead us to the pesticide paradox. Repeating over and over the same test cases with the same test data will no longer find new bugs.

5. Not keeping test cases up to date

If you want your test cases to be useful, keep them up to date. Outdated test cases don’t bring any value into your testing.

6. Criticising developers

A constructive way of giving feedback and a positive communication can make the difference in a tester-developer relation. Try to spot also the good work a developer is doing, not only the bugs or problems found in his/her code. Add positivity into your testing!

7. Making assumptions

As a tester you should never make assumptions! The best way is to ask all the questions you need an answer for, helping you to understand the requirements, what need to be tested, what was implemented or how the application under test is expected to behave.

8. Incorrectly evaluate and measure the effort

Project Manager: “How much would it take you to test this?”

Tester: “Hm, a couple of hours, maybe?!”

Be sure you make a step back and you see the bigger picture before you give estimates.

9. Frequently changing the focus

Emails, meetings, regression testing, test case creation, test case execution, a phone ringing, a person asking something, a patch in production that needs to be tested, another hot fix. I think you all recognise the scenario.

This can have a negative impact on your productivity and quality of your work. I would suggest you to try to find what works best for you and organise your working day accordingly.

10. Copying the acceptance criteria into the test cases

We are sometimes tempted to make this mistake while writing our test cases when we don’t see much value in writing and executing them. Let’s try not just state the obvious from acceptance criteria in our test cases, but also focus on negative testing, edge cases or other scenarios that might make our testing more complete.

11. Incorrectly evaluate the impact of a new functionality/fix

This is translated by one word: regression. It is crucial to understand what other areas are affected by a newly developed functionality or by a code fix.

12. Being scared of using tools

This might happen when you, as tester don’t feel very comfortable with your technical skills. It’s totally fine not to be a super hero in using tools, but I encourage you to be open to any solution that might ease your daily work.

Even you don’t feel comfortable in using tools, you might get help from other testers, developers or maybe online support.

13. Not thinking as the end user

It is better to take the user’s hat and imagine how s/he will use the application you’re testing. It is said that the end user is the best tester which finds more and critical bugs. And we don’t want that, right?

14. Not asking developer’s help

Sometimes we are afraid of being judged or afraid of looking stupid which leads us in trying to find solutions to our problems by our own. It is not a bad thing to be a problem solver. This is not the best practice though when you invest time in doing it instead of asking a developer what you’re trying to figure out.

I encourage you to have a good relation with the developers you’re working and maintain a positive communication. There should be no me vs. you, tester vs. developer kind of situations.