Top 10 signs of a Bad Tester

If any of sounds like you, please take corrective action ... now!

Dear Readers,

Some time ago, I came across this top-10 list of what makes a bad tester. I'm sure we could all add to this list, so I invite you to do so. As I transition to a role in management, I've studied some of the points and will be adding my opinion in ("blue").

The list was subjective, based on the author's own perspective of what made a bad tester, and proper credit is given (paying this forward).

Enjoy! Top Ten Bad signs ( Augusto E.,  Principal Agile Test Engineer at Paddy Power PLC): 

Tester spends long hours sitting at his desk testing with the headphones on 

• This can be taken in a couple of ways. If a tester is spending long hours at their desk because they're in the midst of a full regression (manual or automation), test plan / test case write-up, or closing tickets, then its not the worst thing. But if this is a pattern of behavior akin to dissociating from one's environment, team, or workplace then it could be taken as bad.

He doesn't talk to Developers

• A big mistake if you are in the planning or testing phase of a project. A developer will be your ally when it comes to deducing bugs and putting forth a quality product. Failing to do this, dear tester, is a failure to do your job properly. No one is an island!

Developer don't talk to him

• See my previous comment. If you have not allied yourself with a developer, you are in a sense alienating yourself from the team. Your value will be diminished by this. Please stop doing this and get to know your developers ... a.s.a.p!

He doesn't talk to Product owners

• A tester who has not talked to a project manager, business analyst, or other such product owner is essentially lost at sea, in a raft, without a paddle, food, or water when it comes to testing effort. Failing to talk to a product owner is failing to acquire the necessary information to do the job (at all phases). If this is you ... stop doing this or find another job.

Product owners don't talk to him

• IF you find this to be true, dear tester, make some effort to correct this. Information is your weapon in the effort to deliver a solid testing platform. If you don't have the tools you need you won't succeed.

He doesn't talk to the customers

• This is subjective. If your job is in the Customer Service / Client Relations field, you will need their feedback to help in the quality effort. Otherwise, conversations with customers are best left to those in those roles.

Customers don't talk to him

• See my previous comment. The author of this list makes the point of the a tester being alienated.

Nobody looks for him for questions

• This is a problem if you are not perceived as valued member of the team. I can't stress it enough how bad this is, dear tester. If nothing else, you are the advocate of Quality. You need to know as much as a producer, work with a developer, and think like the end-user. You wear many hats and have tremendous value to the team. Your voice needs to be the most heard.

Nobody looks for him for opinions

•  Again, yours is the voice of Quality. You need to be heard above all others. If you have been successful in your job, you can provide insight into what makes a quality product. There is no place in QA for church mice. 

Communicates only through mail and bug reports

• Unless you have a sore throat, or some other ailment that keeps you from being able to physically speak, you would be wise to leave the desk and liase with your fellow team members. And I'm not including a sprint meeting, or stand-up. I'm talking about being able to sit with a developer or producer and get it done.

Missing defects, especially critical ones

• Where do I begin with this one. I can't stress it enough how BAD this is for you, dear tester. Its easy to miss a bug if the feature was not scoped properly, or if time was limited. But if you have had enough time, been given proper information / documentation to get the job done yet you still missed an obvious critical bug? 
• A bug that was missed because it was tester error illustrates an egregious problem with person assigned to the project, especially if they are not motivated to succeed. A good manager will be attuned to this and take the necessary action to prevent a repeat occurrence. If however, there is no change then decisions need to be made. 

No accountability / trace-ability

• I'm a huge proponent of trace-ability. When test plans and test cases are written, they provide tangible proof that you, dear tester, know the project you have been assigned to and have the testing tools necessary to get the job done. IF a bug is missed, one can look back and see where the problem occurred.
  
  I had a situation where a serious bug was missed (reported by the Client). The issue was escalated and an all-hands meeting was conducted. It turned out the issue was environmental, stemming from a particular race condition when connectivity to the network was lost (and the device went to sleep mode).
  
  The point: while it was easy to blame QA, our response was positive and constructive. We had accounted for all possible scenarios and had documentation (approved and signed off) to provide insight into the testing effort taken. We took accountability without playing the blame game. The bug was something attributed to a 3rd-Party API and the issue was immediately resolved. All was made right again.
  
  Accountability and trace-ability are HUGE in our line of work. Failing to take accountability for failure is less a flaw in testing, and more of a flaw in the person. 

Mind what you have learned, dear tester, serve you it will (yoda voice). 

This list was not meant to call you out (if this applies) but rather to point out the "bugs" in who you are as a member of the team. Take strides to improve who are and what you mean to the team and the company.