Question: Let's say a developer fixed a bug or refactor a component which can affect many places in the application. As a tester how do you define the scope of the regression tests so you don’t miss any bad side effect of those changes? Is it a Dev job to clearly define it? What if he is not clear?

Answer: 
As testers we won't set hard boundaries for testing, that's why organisations push for test automation, CI/CD and so on. We expect to get 100% (almost) test or feature coverage for each new build.

But if you are in an organisation that doesn't have test automation then some times test completion deadlines could make you feel challenged. In such cases, few of the things i follow are:

1. **Sanity testing**

This decides the entry criteria. Here we check that basic things are working, you navigate to different pages and see things looks testable and functioning.

2. **Smoke test:**

Test the most critical features

3. **Using critical thinking and common sense**

If you are really time-limited, use critical thinking to choose components that would be affected. For instance, if a header element is updated, then ideally you should check all the pages that use it. But for time-limited, task think about pages that have too many components and could cause alignment issues if any component changes size. 

4. **Never stop testing**

The final rule is to test more and keep testing even after you approve the candidate. Never stop testing
Every software testing company uses both test automation and functional testing to handle these kinds of situations to cover 100% of the feature coverage.

However, if we don't have automated scripts then for those cases we can perform smoke, sanity and regression testing:

Smoke testing: In this, we decide if the QA build is stable and all critical areas of the application are working as expected.

Sanity testing: In this testing QA team checks the basic functionality and workflow of the application and verifies that it is working fine or not. 

Moreover, test all the components that you think have an impact on the changes done by the developer. Execute all the test cases of those areas if time permits.

Do not stop testing the build until the code goes to the live environment to find out all the issues that came after pushing refactored code in the system.

Dev team can suggest the areas where code is refactored by providing the root cause analysis. Rest of the things QA team can handle by performing testing around those areas.