Home > QA > How to deal with common situations in QA area

How to deal with common situations in QA area

I know you are probably thinking, why do you need to talk about it ? Unfortunately, I can spend hours here talking about the situations that a big part of QAs go through everyday. Maybe you are not a QA, but you have to deal with one of these problems as well.

So, I will talk about the most common problems and how you can deal with them:

 

When you have been telling management about a problem for weeks and now you’re just like

 


This is a classical problem, QAs should raise their concerns about some issue that they see it is coming. As a QA you know how the end user uses the product and you can see some upfront failures, scalability issues, etc.

Your job is to point the issue and raise the concern. Now, it is up to your manager to act on the problem or not.

 

 

 

 

When you hear about “small last-minute changes”

 

This is completely common in agile (personally, I don’t think this is a major issue), we just need to be aware of the risks. If we keep this in mind, it is okay. In the end we are not machines, and most of people don’t perform well when working under pressure compared to a normal day.

My advice is to be cold blooded when you have these last minute demands, just go to a place where you can focus and ignore any outside distractions, put some music on if you think it is better to concentrate.

 

When a new feature comes to QA in the last day of the sprint

 

Be realistic, as a QA you probably already know the percentage of the bugs you will find for each developer’s ticket in the first round of tests. This experience improves according to the time you stay in the company and know the quality of the work of each developer.

When this feature arrives to QA, be realistic and raise the point that it has good chances to be back in development and not finished until the end of the sprint.

 

When a bug slips through to the production environment

 

Don’t cry ! haha This is completely common, and this is not always QA’s fault. QA is just the tip of the iceberg and for this reason you need to know the feature not only on the technical, but also on the business point of view. For this reason the kickoff meetings and all the details are important.
When a bug slips to production it is a series of mistakes, this means that maybe the development team was not aware of some scenario, or the PO was not aware of what the users really wanted, and consequently QA didn’t know about some edge cases since they were not involved in the technical and business discussions. You know when you missed something and you know when you didn’t test something because you were not aware of the implications/impact.

 

 

When no one recognizes QA

 

This is really sad, but after some years you get used to it. I mean, it is not ideal, most of the recognition comes from the developers themselves or  the QAs that work with you.
Learn to motivate yourself without waiting for any recognition from your managers. I mean, if you love what you do, you don’t need anybody to say how good you are at it. If you have a feedback about your work, take the positive and constructive criticism to improve yourself, ditch the negative ones. Do what you like, as long as you are learning and you are happy, it is okay.
Advertisements
  1. Muhammad Saad
    September 5, 2017 at 3:18 pm

    Great article. Thanks for writing and sharing it

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: