It’s the QA’s fault.

I was trying to keep a good posture while sitting on my desk when a tiny window popped up on the down-right corner of my laptop screen. It was my boss:

• Manager: UAT found a bug on one of the flows for X application. Why didn’t you find it? Didn’t you run a regression? Send me the evidence please.
• Me: Hi, yes I did test it, we did e2e with all the possible flows. What combination was he testing? Let me check for the evidence.

As I was searching among the sea of Test runs executed in the past weeks, I could feel my heart pounding out of my chest and my mind going a thousand miles per hour trying to go over what I could have missed, even though I was already working on a new project and I didn’t recall the exact details of the past one.

In the end it was not a bug undetected by me, but a new bug introduced after deployment in UAT region. Some connection with an external service was down.

A few weeks go by and the team is late with the new project. Deadlines were tight but the business didn’t want to push the release to a future date so we are all trying to meet the deadline. I have been sitting idle for the past two sprints while Dev was working on their tasks and now I am with one sprint left to test everything at once.

• PM: So seems like you are going to have an entire Sprint dedicated to QA only. That should be enough, right? Only 10% dedicated to Development and 90% to QA.
• Me: Yes, but I still need to finish testing all the user stories that were blocked in the last couple of weeks and do a regression on everything to make sure nothing from previous sprints is broken. That might led to new bugs being detected and regression then would be delayed until we get the latest code version.
• PM: And how much time would that take?
• Me: It depends on the bugs we might find when we start with the testing
• PM: And what is your strategy to handle the situation?
• Me: More time so we can finish testing and be confident of what we are delivering.
• PM: We have one more sprint so I will book a meeting and you can talk about your strategy to meet the deadline.
• ME: ….

After that situation, there are a couple of things I can do:

1. Prioritize the most important user stories and flows and work with them first.
2. Escalate the situation with my QA Manager and see if he is able to negotiate a better solution.
3. Work overtime and kill myself to meet the deadline
4. Do what I can in the time I have and keep the team updated as we get closer to the deadline.

I did all of them. Some days I worked unpaid overtime, others I worked until 6 pm, I kept my project and my QA manager posted of my progress at all times and I prioritized the main flows before getting my hands on the rest of the tasks.

I found several bugs, some of them were blockers, some of them were mild. Dev team also did it’s best to fix the issues as they appeared, but the deadline came and I wasn’t finished with my testing. I have been at the bottom of the totem pole for months and now on every meeting I am the one they all want to hear talk.
And you know what? Even though the entire project was late, right now it feels like we are not going to make it and it’s the QA’s fault.

What can we improve in this situations?:

Quality needs to be a priority for Developers, Managers, Designers as well as Testers.
Not enough time is spent in discussing an automation approach instead of expecting all work to be manual.
Deadlines needs to be moved to ensure we have a code as free of bugs as it can be, with time to build the proper features for the user.
Quality Assurance has to be a topic of conversation during the entire project, not just at the end.

And most important of all, a reminder that we are humans. We can work hard to build quality, to standardize procedures for better development, for better testing. We can shift left and engage in requirements and design, and we can try to include the most in our automation suite, but we don’t blame.
Bugs will still go into Production, errors will be made, and we have to lose the “Who tested it?” attitude and work in a solution mindset:
How can we solve this issue? How can we prevent it from happening again? Can we include this validation in the test scenarios we cover for regression? Because in the end, it’s not about the role, it’s about the product.

Good luck!