Stop

4 Things All Testers Should Stop Doing

We all have bad habits, some of them are personal, and others are professional. And, considering QA has grown and matured over the years into a separate IT industry people who have worked as testers for quite a decent while now have surely gained numerous habits as well. Some of them are great, they deliver value, simplify processes and ad pieces of souls inside very single designed test cases whilst others are really bad things to do, but we are already used to them.

It’s like smoking. We all already know it’s bad, yet those who do smoke always have a hard time quitting. Here are several great examples of just such bad habits we should all consider quitting as soon as it’s possible, unless we want to get project-cancer:

  • Pride: every tester experiences pride when a defect is located. We are out there, in the field to break the product. That is what we are hired to do and that is exactly what we get pay-checks for. There is neither time nor place to be the nice guy to developers, everything of matter has to be logged and reported. But, at times, we are too proud with what we do and simply irritate everyone around with pointless bugs we have located. Many testers create issues in places where there aren’t any around. Always remember that there are priorities, deadlines and requirements.
  • Too much exploration: many testers neglect test-cases and test-data design. There are ‘best practices’ and great techniques for a reason. Nobody says you should only follow the script, but you can neither treat it lightly.
  • Documentation: pretty much the previous issue, but under a different angle. Testing is not at all about finding bugs, it’s about reporting them in a reproducible way. What is the real point of knowing something is wrong if nobody else can get to the issue? (especially the ones who have the power to fix the defect)
  • Power is not in numbers: It’s never the amount of defects you should be headed to, but their value. If you have located 10, 30, 50, no matter, defects during the session priorities them fist and then only decide what to do with them. Some may require rapid attention from developers, others can wait. No actual matter what the case, you should be responsible for highlighting places that require immediate fixes and if you will report a whole bunch of multi-level bugs, you will only achieve chaos. Developers are like children; don’t make things even more complicated for them.

This pretty much sums up my top 4 bad habits lots of testers share. What do you think?


TestFort Blog

About TestFort Blog

TestFort blog is an official blog of TestFort QA Lab company and is dedicated to various QA and software testing issues.


no comments yet

Be the first to comment this post!

Would you like to share your thoughts?

Software testing & QA blog by TestFort © 2017

×