Software testing is a very rewarding job.
However, it also has numerous challenges that we face on a day-to-day basis.
In this article, I’ve listed challenges that I have faced in my software testing career as well as various colleagues.
If you are new to the QA world, then it might be worth understanding what is involved with software testing first.
Table of Contents
Not testing enough
As testers we’re never entirely happy with our test coverage.
We may have tested every requirement, but there’s ALWAYS more we want to get our teeth into.
One of my software testing challenges is not being able to test enough due to lack of time or resources.
I’m looking forward to the day when we have unlimited time and an unlimited budget.
Yeah right!
Working on multiple projects and over-allocation
Working on various projects simultaneously can be very difficult.
Especially when your projects are at their busiest periods.
Being over-allocated on a project is a tester’s worst nightmare.
Not only does it cause a ton of stress, but quality may suffer if you are not fully engaged in all your projects.
One of the key challenges is being able to balance several projects at once whilst still delivering on quality.
For example,you might be allocated on 2 projects at 50% each.
I can tell you from experience that this is going to be tough.
I know of projects where a person could be assigned to three projects with an allocation of 25%, 25% and 50%.
This is an absolute nightmare.
Why?
I have experienced this.
The 25% soon becomes over 50% and 50% easily becomes 100%.
What eventually happens is your test resource is overallocated by 200-300% and it becomes unsustainable after a while.
Please stay away from this is you can.
Bad planning is partly at fault to this.
BUT.
Projects also face problems, sometimes these are unknown and not factored in.
There are always an array of issues that creep up.
Now, if this happens on multiple projects, you’ll have a tough time trying to manage.
If you ever find yourself in this situation, SPEAK UP and do not think everything is ok.
You MUST look out for your mental health.
I’ve found that most managers are great and will always do what they can to help you.
The Challenge of Ad-Hoc Projects
I don’t like working on ad-hoc projects that just randomly pop up.
They usually impact your existing projects.
However, in some cases, ad-hoc projects are imperative to the business so can’t be avoided.
For example, an urgent change request for a PRODUCTION defect fix may be required.
This can sometimes steer you slightly off course but maybe for the greater good of the organisation.
If your organisation does historically get Ad-Hoc requests, you should factor in a small percentage of your project schedule to this activity.
A defect is found in PRODUCTION after deployment
This is an unpleasant challenge that every tester may face at some point in their career.
Now imagine this.
It’s the day after the deployment into Production.
You’re keen to know how the code release went.
Your stomach is in your mouth and you’re nervous anyway.
A defect was found and they had to roll back to the previous release.
Ouch!
The first thing that stakeholders will generally ask is;
‘Why wasn’t this found in the Test environment’.
So why is this a challenge?
You have to prove that this was either tested, out of scope or another reason
If the issue identified is significant then what will ensue is potentially a considerable effort to finding out if the issue was tested.
It will be up to you to prove your innocence on this one.
In the world of software testing, the tester is usually guilty until proven innocent.
Unfortunately, it seems the mindset of the majority of people outside the test team is that “Testers are miracle workers” and we can find anything.
While that’s can be quite a compliment, its not a compliment when you find yourself in this scenario.
It’s not their fault, to be honest.
The truth is that we cant find everything.
In some cases, we miss the ball.
For that, we have to stand up and face the music.
In other cases, a defect was already found and signed off by stakeholders as a known issue.
It’s mentally draining and stressful.
The mitigation here is to ensure that there is regular open communication between all stakeholder teams.
This can be in the form of project meetings and status reports.
Also, make sure you get all approvals and sign-offs.
Ensure all communication is in written form such as email.
A verbal confirmation is NOT enough.
When you learn to do this, you’ll reduce your risk significantly.
Reputation management for the test team
When a defect is found in the production environment, it can be heart-wrenching.
It’s not a pretty sight.
It’s not just your reputation on the line but the whole test function.
If this happens often, trust in your team and process will falter.
It can have a big impact on your entire department.
You may be worried about what other people and teams think of you.
You may have a knock of confidence in your ability.
Rest assured, these things happen.
Nothing is perfect.
Its life.
Please don’t beat yourself up over it.
My sincere advice is to learn from it and take measures to prevent it from happening in the future.
When you are dictated a testing timeline by a non-test team colleague
This is one of those situations that can be annoying.
What happens is that you’re given a high-level project schedule by your Project Manager.
This schedule essentially gives you a testing window.
You’re probably asking.
“How does a Project Manager know how much time to allocate to testing?”
It’s a good question.
Most of the time from my experience anyway, its just an assumption.
A figure simply pulled out of the air that ‘looks’ good to fit the planned timeline.
I’ve become used to seeing these plans and tend to ignore them. You should too.
It’s not entirely the PMs fault. They need to present a plan to the Project Board so something is better than nothing.
Under no circumstances should you accept a plan that a PM has compiled without your input.
Now the only exception to the rule here is IF the project has a hard stop date which the organisation has no real control over.
For example, real-world events such as a pandemic, regulatory or legal requirements.
You should always however work to try and achieve any timelines that are given if they are achievable.
After all, we are all on the same side.
The Learning Curve
A key challenge of being a software tester is the learning curve.
As a consultant who goes into various organisations, understanding how processes, systems and applications work are just a few of the key challenges you’ll face.
As Software testers though, this is an inherent part of your nature and what you do so I’m hoping this is something you’ll take in your stride.
Understanding complex requirements
Reading and translating requirements into testable conditions is only one part of the equation.
Understanding complex requirements at a granular level can be quite challenging.
To be honest, I love and thrive on complex requirements as it allows you to think on your feet and be somewhat creative with your tests.
What it also allows you to do is to ascertain how resilient requirements documents are.
With requirements documents, constant static reviews allow us as testers to ask thought proving questions at a granular level.
As a result, I have found that documents usually get updated which allow higher quality tests to be created.
Challenging yes, but I feel this is one of the stages of testing where you can show your knowledge and worth.
The feeling of being able to test complex requirements in detail and proving them out is something that gives me a buzz.
Understanding integration with other business applications
Software Testing isn’t just about a single application.
There can be many layers of additional complexity where other applications are involved.
These could be internal or externally hosted applications.
For example, internal communication with your organisation’s finance systems or an API to externally hosted banking systems.
Understanding infrastructure requirements
Testing software sometimes means that you need to understand how hardware and infrastructure work together.
For example, there may be specific requirements for internally and externally hosted applications.
Security requirements could be an example of infrastructure considerations that need to be taken into account.
Another example could be “all applications need to adhere to a single sign-on via [vendor application]”.
This is especially true and can be challenging when working in very complicated or regulated environments with strict governance processes.
To understand this, you would normally need to speak to someone like an IT Architect, developers and maybe even IT security.
It totally depends on your system and organisation.
Understanding the Testing Scope (WHAT to Test)
It all comes down to WHAT you are going to test. Or the Test Scope.
You’ll have to face many of the challenges mentioned in this article to ascertain what the test scope is.
Once we have an overall picture of requirements, timelines, budgets, hardware/software infrastructure requirements, we can only then start to figure out the scope of testing.
One of the key challenges is understanding not just what to test but how much testing to conduct.
Understanding the Approach to Testing (HOW to Test)
The Test Approach defines HOW you will test.
For example, which area of functionality you will test, the kind of data you will use etc. It is slightly more granular than the test scope but not as detailed as the test plan.
It basically sits in the middle.
Generally, you’d need to cover both the Test scope and Test Approach in a Test Strategy document.
Putting this all together can be quite challenging but can be quite fun.
Training other team members
I love mentoring people. Its something I thrive on.
I love putting in processes and trying to give my team whatever they need to grow and excel.
It’s challenging.
It’s tough.
But with the right people, it can be very rewarding and efficient.
More recently, I’ve spent a lot of time training and mentoring people.
I’m more of a go-between.
A catalyst to help get the job done.
I’m not worried about being a ‘Test Manager’ or a high profile job title.
I’m no Billy Big Shoes.
As long as the work gets done, that’s what matters.
If you ever get involved in training, be prepared for some challenges ahead.
It will require tons of patience and nurturing.
If done right though, it can be amazing.
Ensuring consistency of quality work across your team and project
When you have a decent-sized team which spans across several countries and time zones, ensuring consistency across your department can be difficult.
If you are responsible for processes or governance, one of the biggest challenges you’ll face is “consistency” of documentation and work across your department.
Setting expectations and how to achieve these will probably require lots of training sessions with your teams.
This is an ongoing process and never ends.
Delivery under extremely tight deadlines
Since software testing sits towards the end of the SDLC, there is an additional pressure to hit deadlines.
As you enter the test execution phase primarily, you’ll start feeling the pressure from your project and will be asked regularly if you’re on track to complete on time.
It can be really challenging if your project has faced delays attributing to other teams.
Time to plan, strategize and think
When you’re under a lot of pressure to deliver, it can sometimes become difficult to just sit back and actually ‘think’.
I’ve found this really challenging during the planning stages where you have to think strategically but collegues also require your time.
However, this is part and parcel of being a Test Manager.
My advice is to block out times in your calendar and make yourself unavailable.
Do NOT spend hours after work doing this.
Documentation
Executing tests is a lot of fun.
However, there’s a part of testing that I find many people don’t like too much.
Documentation.
As a tester, you’ll be expected to write lots of documentation.
However, the challenging part is to consistently deliver documentation that is of the highest quality.,
Most people can write a report, however, writing a document that is consistently of high quality can be quite difficult.
Especially for those who writing is not a strong point.
Don’t worry though.
With the right training and following some best practices, you can also deliver good quality documentation.
You can’t be in a QA function if your documentation is poor.
Following Processes and strict Governance
Process, governance and red tape are there for a reason so you SHOULD always follow it.
Especially when you work in regulated environments.
Following processes to a Tee can often be easily overlooked.
However, this can present itself as an unnecessary and major challenge later during an audit if your documentation did not follow the correct governance procedures.
It’s always best to put in the pain first so you don’t have to deal with it later.
I get how tough this can be when you’re going through a peak time during your project.
However, there’s no running away from this unfortunately.
The learning curve involved with learning a new application
Learning a new application is part of the challenge of software testing.
I love this part of the job,
The key challenge here is that you often don’t have enough time to learn the application as in-depth as you want.
You often only have a short space of time to familiarise yourself with the application via documentation or a walkthrough.
Even this isn’t enough, but you have to be smart with the information you absorb and that which you need to know.
My personal approach to this is to really go through the requirement documentation documents such as the BRD, Functional Requirements and any High-Level Design documentation.
If you can Business Analysts, end users and developers to tell you as much as possible as early as possible, then this is a really good way to understand the system.
Stakeholder Management
If you want to know what a software tester does, you’ll know that stakeholder management is a crucial part of the job.
Being able to communicate with project stakeholders is a skill in itself and can present a challenge to those that might have an introverted personality.
Managing stakeholders requires you to be thick skinned, knowledgeable, sharp and in some cases charming. ?
Software Testers vs Software Developers
One of the most well-known challenges you’ll face as a tester is dealing with software developers.
This well-known rivalry has been around since the day of software development and continues to this day.
There has even been research papers such as this been written on it.
It goes something like this.
Tester: I’ve found a defect
Developer: It’s not a defect, it’s as designed.
In short, developers may struggle to accept the issue you have raised is a defect.
On the flipside, testers may not accept the defect they raised is NOT a defect.
What usually then transpires is a triage call between many different teams.
My advice to YOU as a member of the test team is:
- Do not assume every ticket you’ve raised is a defect
- Be impartial and sit on the fence (this will help your credibility).
- Have a little humour and personality (this always helps lighten the mood)
- Listen to all sides and come to an agreed resolution.
- Open up the lines of communication between both parties.
Ever Changing Documentation can be a challenge
Software testing is an ever-changing business.
Even with document sign-offs, there tend to be last-minute changes or amendments all the time.
I often see requirements being added, amended and deleted frequently.
In an agile environment, its very common to have this.
Just ensure you have a watertight process to capture these changes.
Being able to adapt to the new changes is something you’ll need to take in your stride as a Software Tester.
Educating non-testers of your job
Over the years, I’ve worked with dozens and dozens of project managers.
The one thing that I’ve learned, is that do not assume that every single Project Manager knows how the testing process works.
The key challenge here is assuming that PM’s know your process and testing in general.
This is wrong.
To overcome this challenge, what I do is to have a kick-off meeting and introduce the testing process with every project that I’m assigned to.
This ensures the expectations between both parties.
It acts as both a refresher and a new learning experience for your non-testing colleagues.
Not only will they appreciate it but they will be able to support you much better.
Summary
Like with any role, you’ll always face challenges.
Above were just some of many of the key challenges you’ll face as a software tester.
I’ve found that they’re not impossible to deal with, they just require some experience and nerves of steel.
It all depends on how you deal with them.
In most cases, the challenges mentioned above are part of your role.
Embrace, accept and enjoy these challenges and take them in your stride.
I hope this info helps and you still feel that software testing is a good career.
All the best.
