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?

Testing Computer Software - A must-have for QA Personnel

(click the image)
 Who this book is for: Testers and Test Managers Project Managers-Understand the timeline, depth of investigation, and quality of communication to hold testers accountable for.

Conventional Testing Is Dead ... Long Live Testing

My response to the following article

www.agilebuddha.com/Traditional Testing Will Be Dead Soon

---

Point-1: QUALITY is at the root of our profession, in all things, in all ways

If we are to define traditional testing as point-and-click behind a desk, or using a mobile device, then the old ways were in serious need of evolution. The fundamentals for testing reside in the extraordinary lengths by which we go to to find defects. But, the entirety of quality assurance is just that ... assure the quality of the product. That includes the processes, plans, and methods that are employed, and the people who execute these plans.

Successful automation program relies on disciplined practices. A tester can be good at coding, but has added value when the fundamentals of QA are at the heart of the test cases.

Testers need to be good programmers as well moving forward ... they should be able to learn and evolve latest automation frameworks and work with scripting technologies to stay relevant.

I concur with this sentiment as it reflects my current situation and the glaring deficiency in my skill set. I acquired many skills in management but that pales in comparison with the need to know coding and at least one testing framework.

Point-2: Automation is a means to an end, not an end unto itself. This new trend is forgetting that.

Automation is not a panacea. It will not find low-hanging-fruit. It cannot suggest new test methods. It is a matter of perception as to the worth of a QA tester, but what automation WILL do is reduce the time taken to execute menial tasks freeing up time to concentrate on more important matters.

I remember testing an app looking for a memory leak. A simple loop with a count marker iterated through the process of taking a photo repeatedly until the app crashed. A second execution of this script a few seconds less before crashing.

The point: by hand, finding this memory leak would have been tedious and undoubtedly taken hours. Employing automation in conjunction with continual manual testing, I was able to report my findings with supporting evidence.

Point-3: Sloppy is as sloppy does! Automation will not credit development hours to the timeline if the developer remains undisciplined and careless in their work.

This was my battle as a QA Engineer. In my research, I came across many many frameworks that were too limiting, too expensive, or not completely what we needed. Appium so far has proven to be the leading tool (one that has gotten a lot better to use since its first few versions last year, I might add). As I write this, I have made the commitment to fill the knowledge gap and learn this tool along with learning JAVA. What started out as a WANT is now a MUST HAVE. I recommend this to everyone not already onboard with automation or programming.

Test engineers need to be product experts, quality advisers and analyzers of risk.

Conclusion:The ultimate end of QA is far beyond bug-finding, way more indispensable than opening and closing tickets, and too valuable to be relegated to writing test plans and test cases.

It is imperative to be versed in all things relevant to Quality Assurance, but the age of automation is upon us. Manual testing, month-long full regression test cycles, and iterative testing are all a thing of the past. Like the old Model-T giving rise to a sleek 2015 Ford Fusion, QA Analysts give rise to Software Engineers in Test and are becoming full fledged members of DevOps.

Like it or not, this is only the beginning!!

What Food Service Taught Me about QA

What I learned in 2014

I confess to you, my audience, that it has been a long long time since my last blog post. Something I do not intend to repeat this year.

As 2014 has come and gone and a new year is now upon us, a lot ... I mean a lot of lessons were learned from the many projects I was assigned to test. But of the truths that have become self-evident, one constant remained certain - my past has taught me well.

I wasn't always in Quality Assurance. Matter of fact, I wasn't in the IT field until my early 30s. When I graduated college, I had aspirations to become a writer or publishing agent.

Then the internet happened, and I found myself steadily growing in my current position as a waiter. I made it to bartender, pastry chef, eventually a personnel manager responsible for a staff of 65 waiters, 12 supervisors, and 9 bartenders.

At some point, I turned 30 and realized this wasn't the life for me.

As I transitioned to IT from my former life, the following lessons have served me well:

• Garbage In, Garbage Out
  How a meal is presented is determined by so many factors: mood of the chef, the time to cook the meal, etc. The quality of the ingredients will determine the product.

  The same goes for a project. A rushed assignment, with minimal information and a lack of product knowledge, coupled with an unmotivated tester who's been undermined will lead to a very sub-standard product.

• Work Clean
  A clean workstation is vital to the success of a product, be it a 4-course meal, or a multi-faceted website with a robust backend. Cleanliness means, the developer's coding habits are sound.
  
  His / Her work environment is well-maintained. The product requirements are approved and not lacking.

• Be Versatile
  When I was young, I had a pretty full schedule as a waiter, but eventually the work got lighter. Then I learned how to bartend, then eventually to supervise others. Since then, my schedule got fatter.
  
  

  The point is that versatility is key to a successful career as a QA Analyst / Engineer / Manager. One has to think like an end-user; have as much product knowledge as a business developer; approach the project like a project manager; and test wit the creativity of an artist.

  Never limit yourself to one skill set. Always keep learning something new and challenge yourself.

• Everyone Matters
  One day I happened to be in the kitchen when I saw the owner of the restaurant willingly roll up his sleeves and help the dishwashers out. I never had more respect for someone as I did that day. That was how I knew what good management looked like.
  
  I learned no one person is more important than any other on a project.

  While the perception may be that QA is at the bottom of the totem pole, never forget that it takes a strong base is the foundation for everything. And quality is the foundation that holds everything up!
  

• Have The Right Tools
  Good cooking requires quality of ingredients, precise measurement, and the right tools. Not a lot a chef can do with a dull knife.
  
  The same goes for testing. The right tools includes having the right state of mind (motivation), having the right mise en plase (PRD, Test Plan, Test Cases, etc.), and a solid understanding of what the scope of testing entails.
  
  It behooves a tester to have proper product knowledge so as to fully test and provide support to the developers.
  

 Conclusion: I took a lot of dinner orders, served a lot of drinks, and pleased a lot of people with my service.

I learned people will always come back for good food, good service, and a great atmosphere. So it is with business that repeat Clients will stay based on great service and a quality product. And its our job as QA people to be a part of that effort.

!! Happy New Year !!