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. 

QA Tool: Android Support (Platform Versions)

Dear Readers,
For those of you who specialize in developing, testing, or otherwise using Android handsets and / or tablets, pay close attention to the information listed below.

Below is a screenshot from the android developer portal, and shows a very useful breakdown of the more popular android versions to use.

Keep in mind, this is all pre-6.0 (aka "Marshmallow").

For more insight, click this link - Android Dashboard.

QA Tool: Using Using QuickTime to capture videos‏

Dear Readers,
Passing this useful tidbit of information along. Enjoy!

Using Using QuickTime to capture videos‏ 

1. Open QuickTime Player
2. Go to File > New Movie Recording
3. Assuming quicktime doesn't crash, it will: 
• Mirror the device on screen. 
• If it uses the camera on the computer you can change the video source by clicking the down caret next to the record button.
4. Proceed with recording the video, be mindful of video time (duration). 
• Some bug trackers have a file constraint of x-MB and you won't be able to upload your video

Blind Squirrel Approach: What do you do when requirements are sparse

"Because even a blind squirrel finds a nut once in a while ..."

You may be familiar with this saying, or you may not have ever heard of it before. The message is simple: given the likelihood of failure, success can happen, even in the slightest of ways. How does this apply to QA you ask?

New to the project

You, intrepid QA / Software Engineer in Test, have been assigned a new project, or are filling for someone. If the Test Plan is adequate, you should have all the information you need to successfully complete your task. But what if you don't? Do you panic?

• Solution-1: If a fellow teammate has handed off the project to you, they should already on-board you to the project and provide as much background, context, and other details of relevance. If this wasn't the case, the next-most person in the list is your team lead or manager. The team leads should have some substantial information and are usually the best "go-to" people on the team.
  
• Solution-2: I've always felt the need to read through as much as I can and get a Producer / Project Manager to sit with me and get a proper on-boarding (if the QA Lead / QA Manager hasn't already done so).

Sparse Requirements

So you are now on the project and have been somewhat on-boarded to the project, but the details are still fuzzy. What do you do?

• Solution-1: If you're like me, you investigate. You talk to the people assigned to this project and you get the details you need. I usually start with the developers, before I go to the producer. This is frowned upon, but who better to get the explicit information than from the people who need these details to complete the project. If a developer can successfully code against requirements, you can test against it. Developers will also provide additional insight you may need to consider in testing.
  
  Once the test cases are written (or updated), show this to the Producer for final approval. All will be right in the world.

Lack of Information

You've asked your team lead and there was a lack of clarity (tsk tsk). You asked the Developer for some insight and got none. Now you reach your wit's end and go to the Project Manager. They hand you documents that are sparse of details and have gaps in requirements. What's a good tester to do?

• Solution-1: This may not be a totally true scenario, but let's suspend belief for one second and entertain the likelihood that information is sparse. In the absence of information, a good tester has to take matters into his / her hands and ask for an S.O.W (scope of work), Requirements Document, or something in writing that outlines the expectations of the project.
  
  I've had this happen to a slight degree. The takeaway was that a huge amount of time was wasted doing some unnecessary investigative work to get the information I needed and successfully do my job.

Conclusion

For any QA Tester or Software Engineer in Test (SEIT), information is the key to success. The more we have, the better off we'll be. In my past history and all the way up to now, "I DON'T KNOW" has never been an acceptable answer. If you don't know, its because you didn't MAKE the time to know. If you didn't ask the right questions or do your due diligence, then its on you, dear tester.

If you asked the right questions but got the wrong information then the source of the information is suspect. All the more reason to keep asking questions.

Its our job to understand what it is that we are doing and why. I always ask, "why am I doing this?" not because of some defiant need to assert my position, but more because I want to understand the business logic. Also, I want to understand the scope of what I'm doing and to whom I'm doing it for. All these questions help me be a better tester, not just a cog in the machine.

This may or may not have helped you .. but if I can, let me offer one piece of advice:

ALWAYS BE ASKING?