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: 
I believe it is important to look at test coverage at something that

### Needs to be adjusted as features grow and change (proactive)

as *opposed to*

### Ensuring that things that happened in the past are prevented (or at least detected) by adding tests for them (reactive)

The problem with the second approach (particularly common in traditional waterfall and command & control environments) is that it leads to an ever growing and slowing set of tests that, over time, give less value as more issues arise in using, managing and maintaining them - which is done by costly humans. The number of features and bugs times the number of devices and versions is always more than can be tested anyway so all testing requires some form of scoping down already. At worst you end up using KPIs for number of bugs and number of tests to measure quality effectiveness. 7000 UI tests should not be a point of pride in most organizations but I have seen them be in some.

Also, when discovering and fixing a bug or indeed making any change in functionality the order should also be:

* Will unit tests be enough to cover this new condition ?
* If not, will integrated tests cover it ?
* If not will E2E non-ui tests cover it ?
* If not, will an automated UI test cover it ?
* If not, will manual testing be practical to cover it ?

For example if the change is in a back-end routine that prepares data seen in the front end, you want to *avoid testing backend code changes by front-end tests whenever possible* Instead you use *unit* tests to test the differences. Often the hard part here is communicating this to the business. That takes care and tacts and excellent communication skills such as listening first.
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