Challenges of QA Testing to Manage running project and support ongoing Adhoc and Production Issues

Hi All,

I have a question we have a small company of only 2 QA resource. We follow Agile methodology for QA Testing. For new Clients & enhancements we give the QA estimates and client who are the Pharma company are made aware of the deadlines by the Client service team. In between during the Sprint we get small Adhoc request or Production issues which are for different clients and which are rush item in order to support the current running business. Our current challenge is we have limited QA resources but since the deadline for the new client is not going to be postponed since it was committed and we still need to complete the small adhoc request and production issue.How can we overcome this challenge. I would appreciate if someone can provide a solution. Since this client is a new client we cannot use risk based testing approach.


1 Like

Hello Pete Peter, I have a couple of suggestions that may help a little but I feel I have to comment on what is potentially the route cause first. If I’m reading your post correctly, you give estimates which are immediately turned into deadlines by a none IT team?

Again from reading it feels like it was this other team that ‘committed’ to this work?

So, a couple of suggestions. Are you in a position to pair or mob with the developers working on the request and solution? This would potentially reduce the time to develop.

Could you get the whole team (definitely the Client team too which seems to have created this problem) testing the product / fix / request to generate quicker feedback. They would need guiding but we have found testing our releases as a team, including product owner, business reps, developers and scrum master is a great way of generating a lot of coverage and feedback quickly.

Good luck and definitely discuss the nature of estimates with the other team when you can.

Welcome Prashant. If you can talk about following the above approach, teams will start owning their own quality. If testers are not “embedded” inside a team, this will otherwise be the case, because it fits some business models which most of us don’t like. To me, it feels like you are a shared resource, and the only thing you can do, is require everyone to go through the ticketing process, and for you to be clear that you are using KanBan backlog (I think I get your dilemma), and not Sprints. I assume dev teams are in fact doing sprints. So if the company is happy for this to be the case, it just needs to be made common knowledge.