Bring the stakeholders into the conversation. Get their priorities as to the features they care feel are important to their user base. Advocate for the features you have analysed as important based on risk, issues, known/previous faults.
By setting out the priorities for the work where both technical and business features have been analysed together with estimates + a little buffer. I have found that tech and business stakeholders have a greater understanding of where you are coming from and your needs to meet their expectations and priorities.
If they still want to squeeze, then ask them what features they are deprioritising. get it in writing then make sure the constraint on coverage is captured in the reporting.
To build on what @denissey was saying with regards to engaging stakeholders.
Get a view on what āgood enoughā looks like.
Frequently as testers we aim for testing all the thing, trying to derisk everything, finding all the bugs. That takes a lot of time and effort and frankly might not be needed by the team. Engaging with stakeholders to ask what good enough looks like for a safe release allows for pragmatism when looking at what to test within a tight timeline.
Remember: quality doesnāt mean completely perfect, it means fit for purpose for a person at a time trying to do a thing.
This is in addition to all the other good stuff to give ourselves time / champion quality, such as:
Weāre under contract to deliver certain things to clients at certain times. They are under regulation to deliver it to their clients or the various state institutions.
Any deadline missed means thereās a fine to be paid, or a contract breach with other consequences.
Thereās a constant communication and balancing act between us and the clients.
Internally (business/managers/devs) we try to be as transparent as we can on the current situation, of what weāve developed, what weāve tested, what issues we have, what we need to deliver, and how we might deal with them to keep the client relationship in check.
Some of what we do:
some days we work a bit more compared to others;
we communicate often with each-other and support each-other to not have dead time/spots so things go forward smoothly and everyone is busy with what matters;
we adapt to do another task/role weāve not done before;
we have every 2-4 weekly status meetings in various forms/groups;
If one thinks about the business value and how that is obtained, I think the goal and how to achieve it is clearer for people in the product team.
The pressure from stakeholders is normal to have, shortening the testing cycles is also fine. A tester doesnāt have to own the product quality, they assess it with the resources they have, in the time that they get, with the goal thatās needed from the management.
I also donāt think testers āneedā to advocate for quality, if thatās not their job; sure they could and maybe should, but itās not wanted/required/mandated in many places.
I wouldnāt link directly risk of missing timelines with quality of the delivered product. Quality is subjective and itās the value brought to a person at some time. Someone else owns it and they decide what is valuable to them at the time of delivery.
This is such a relatable question. As test engineers, we often find ourselves navigating the tricky space between business pressures and the need to uphold product quality. Iāve been in situations where the testing cycle time got slashed because of last-minute commitments or more scope got added to the cycle and itās never easy to manage.
This is what I Usually do:
I make it a point to communicate the risks and trade-offs transparently to the stakeholders ( I sit with them, so I have access to them). Instead of just saying, āWe need more time for testing,ā I put it as, āHereās what we risk if we skip X test, and hereās the potential impact on customer experience.ā
Have been a big advocate for early involvement of testers into the cycle. This is where I get my āwhat ifā questions answered. This is not always feasible, but even a small nudge in the process can make a difference.
Prioritizing and Partnering is something that I always do. When time gets squeezed, if you have a clear understanding of the critical
paths and must test areas, we focus on those. Partnering with the business and dev to align on what absolutely cannot fail helps everyone feel more confident on what we are releasing.
Another thing we donāt take into consideration is the immense pressure the business and dev teams are usually under. So our team, we usually work to be part of the solution and not be someone who always raising blockers.
Finding that balance between risk and return is always contextual. But, by having open and honest conversations with everyone involved has been a key in my experience.