Challenges are normal. It is when you look at them as opportunities, a gold mine and as obstacles, a land mine. I have had my share of ‘opportunities’ over the years in the IT industry.
Some came with the role I was playing, some general. This is my attempt to record them and to reach out to the community to see if any of those resonate with you and maybe, in a small capacity help you and let you know that you are not alone.
Here’s my top 10 list:
What You Will Learn:
Top 10 Challenges A Testers Face At Work Place
#1) Company’s culture:
This is the honorary first item on the list because being in the IT services industry had me hopping between multiple clients, teams, locations, and companies. I loved being part of some teams and some, well, I wouldn’t repeat the experience.
- A team that I worked for started at 6 am. Another one insisted on working until 6 pm.
- One made contractors enter the building through a different door and another that did not even believe in swipe card access.
- One made us leave all mobile devices with memory, Bluetooth or any other connectivity outside while another company played wonderful music at the workplace all day.
- Some companies follow a strict hierarchy with their CEO’s attaining celebrity status and another that has no cubicles and everyone was equal.
What I realized over time is that there is no one right or wrong way; it is just their way. Given time, we will always adapt to the circumstances, but if you don’t after giving it a fair chance, find the exit nearest to you.
#2) Different Time zones:
Do you stay at the office or up at home in front of the laptop at 11 PM or 5 Am trying to catch up with your teams that are geographically distributed? This is all too familiar, isn’t it?
There is really no antidote to this problem (May be, coffee?) Use clocks that show you the exact time at different locations (world clock on your smartphone works too), perfect communication protocols in a way that there need not be meetings for issues resolved over email and practice time-zone conscious scheduling to avoid this problem to a major extent.
Recommended read => Onsite – Offshore Model of Software Testing – Make it work for you
#3) Cross-cultural differences:
I have worked in both India and the US. Although corporate culture is fairly non-ethnic, where we are from impacts our behavior and understanding.
For example: “Hi, How are you?” is a common greeting in the US. It does not necessarily mean they want to know exactly what you are feeling at the moment. However, when I was new in the US, I used to think, “I was just in a meeting with this person a moment ago. What would change in such a little time?” :) Good for me, I learnt fast.
Also, in some cultures, talking less indicates quiet contemplation while in others it simply means, it is boring or you have nothing to say.
When you try to understand these small nuances, you understand people better and can function in a better way.
Testing/QA specific challenges
#4) No documentation:
The classic. Many teams still believe in verbal communication and keep little reference material about how the software became what it is today. Rapid development cycles only made this more intense.
However, this is really one of those cases of challenges becoming opportunities.
Engage in conversations with your development, business analysis or technical teams. Research the application; set up references looking at similar applications and their standards. Understand the end-user perspective. Get adventurous with exploratory testing.
For more direction, check out => How to Test an Application without Requirements?
#5) Unstable environment:
Usually, QA teams suffer from inferior environment set up that we have to really be ready to make the most of what we have.
For example: The server that gets overloaded and needs a restart few times during testing, the logs that need clearing often to make sure that there isn’t an overflow, etc.
Bring these problems to the forefront and make sure you get environment support during testing. For commonly happening cases, get the access to the servers with the steps to do some simple maintenance, such as restart, clearing queues, etc.
Recommended read => How to Minimize the Test Environment Defects
#6) Tools being force-fed:
Sometimes we know that a tool is not fit for the job. We have no choice but to continue using it because the clients/teams already have licenses and would not want to go for a new one until the current license runs out.
I had to test a Mainframes application on HP QTP without the Terminal Emulator add-in. In this case, I had the tool but not the correct configuration. There was little I could do about it, so I had to switch between Normal and low-level recording modes as a workaround.
It is not fun, but you learn alternatives. Or at least, you will reach to a definite conclusion as to whether the alternatives actually work or not.
Also read => A to Z guide on selecting an automation tool
#7) Some applications just don’t cut it:
Have you ever tested an application and started to wonder,” How can this even be called software when it’s a bug producing machine?”
I have had this special privilege where most of my day was all about simply reporting bugs and reporting bugs some more. Some areas of the application get cut off as a result of these bugs. The whole spectrum of severity throws you off your game and it gets overwhelming where you start thinking, “Is there a point to what I’m doing here?”
Overtime, I have learnt to stay firm on my decision that the software isn’t ready to test and to reject the build. I no longer look for a silver lining when there isn’t one.
Did you ever have a developer bang the conference room table as soon as you explained a defect? Yes, that happened to me. :) I later came to know that it was his form of expression and not aggravation.
I also had a team member who at first came off as uncooperative and rude but was really just shy. This person would hardly say a few words or meet the eye when asked for status updates. I was very close to putting a negative performance review and escalating had I not realized that the same details can easily and elaborately received from him through email. It is the one-on-one conversation that he wasn’t comfortable with.
Everyone is different and deserves a benefit of doubt. Don’t be too quick to judge and respect boundaries.
Also read this => How to Manage Test Team Effectively
#9) Lack of feedback loop:
Sometimes you go days at an end working on and obsessing over a deliverable only to find out at that it wasn’t supposed to this way.
Or you work from a remote location with your team located elsewhere that you feel isolated and have no one to bounce your ideas off of.
Or you receive feedback that is not exactly helpful. Let’s say you created a process document and they said it was good. You don’t see the process document published or put to use and you are left wondering what happened to it. So, the feedback ‘good’ did not do any good here and is almost a non-feedback.
Seek honest feedback and create a community to discuss your ideas. Not often the easiest to do, but without the positive reinforcement that this step provides you are left demotivated.
#10) Preconceived notions:
Well, we know there are many prejudices in the workplace around gender, nationality etc. I am not going to go into specifics here but unless we start looking at the world as a global village and everyone equal, the world, and the workplace both become toxic.
About author: Thanks to STH team member Swati for sharing these top 10 challenges faced by the testers.
Now, it’s your turn.
Which of the items in the list had you surprised or nod your head in understanding? What challenges did you face and how did you overcome them?
Please share and comment!