How do you adjust test estimates and schedules based on feedback and changes?

What is meant by "test estimates" here - what is being estimated? Duration of tests? Effort required? The opening paragraph makes an assertion without clarity: "Test estimation and scheduling are crucial aspects of software testing"... I'd have thought crucial aspects were quality, expected functionality, understanding use cases, intended audience etc.

Getting insight into the impact of any change will help them make an informed decision as to what needs to be tested Manually. We should always avoid duplicate testing and wasting our time on areas that arent impacted. How do we do this? Use everythign we have in place already. Review Pull Requests, Unit Tests, Understand what is and isnt automated, and ensure you understand what the automation is asserting on, review SonarQube or similar tools, and review any prior test evidence to see if impact areas were already tested as part of the initial change. Using all this information, you should have a good picture to inform your decision on what Needs to be tested to reduce the most risk and get the product out the door.

This is such a great consideration - and one often missed, I believe. Such is testing, the likelihood is that not all requirements are captured and when UAT comes around, naturally, gaps are discovered. Once this information is harvested and shared amongst the project team, test (and project) artefacts need to be reviewed and updated accordingly. This is not reinventing the wheel and is a consideration that rears it’s head on every project or tech update that takes place. My advice to clients and customers is to always recycle and improve test cases and suites, where feasible. Automating regression suites will also alleviate time and resource in the long run, too. It’s important to always find time to improve the test artefacts.

Communicate as soon as possible. Never spend time doing your best to finish within an estimated time. Don't be proud, they are estimates for a reason. Once the whole engineering team knows the hidden complexities, it's easier to deliver news to the rest of the business. Always learn from the new knowledge and use it to make estimates more accurate.

Whether we like it not, every teams core focus should be to get software out the door and into our customers hands as quickly as possible, to a high standard of quality. We cannot find all the issues in a product so as Quality advocates our focus needs to be reducing the risk of our customers finding anything that will ruin their experience of our product, Not to find and fix "All the bugs". The best QAs keep this in mind and should priorities test cases / suites in a way that goes from Must, Shoulds Coulds/High Risk to Low Risk, and be prepared to pull the trigger when its needed to, but not compromise where we simply cannot. Dealing in absolutes is key and keeping the key players in the loop at all times is in everyones best interests.

"You can use tools such as project management software, email, chat, or video conferencing to facilitate communication and collaboration." is unimportant. What we should be concentrating upon is WHAT we say, to WHOM, WHEN and WHY: - communicate variance between expected and actual test results to key decision-makers to have them understand the risks associated with early release - understand required effort to fix reported issues (for a cost/benefit analysis) - ensure issues are communicated early and often to keep people informed. Part of this requires effective stakeholder analysis: who needs to know, and why?

Re-estimation and re-scheduling of work will likely occur if there has been something missed, an unknown impact appearing, late scope creep, etc. Basically it should be the exception. Not the norm. When these things happen, keep the key stakeholders in the loop, understand what Must be done to mitigate the most risk, and work from there. Then learn from the experience and put things in place to avoid these situations going foward. E.g. more impact analysis and testing at the User Story phase/shift left and do more basically.

Why is there so much emphasis upon estimation and guesswork, and less upon quality and actual work? What benefit does "you need to re-estimate and re-schedule your testing activities" serve?

There are always improvements that can be made to how we test. Sometimes we cant see these when we go sprint to spint, release by releases, so I would recommend you take a pause once in a while and interrogate every single thing you and your team do when it comes to all things Quality. Starting form Idea to Delivery. Find the gaps, the 1%'s and get them out there in the team. Keep pushing on and share your ideas. And dont be afraid to think big! "What if we didnt do regression testing?". Always aim for more Quality gates ealier in the cycle, and you will see an ease in downstream *shudder* pain.