Test plans never account for everything, at least in my experience, especially edge cases. And it's rare that I've seen any QA team do a full regression test of the entire site. There's only been a few times where I've seen it authorized, and that's usually after a major refactoring or rewrite.

I'm not in QA, I write code, so I defer to whatever they decide for these things usually, these are just observations from what I've seen.

I just try to make sure I test my code enough that there isn't anything terribly broken when I check it in and fixes I need to make tend to be relatively minor (with a few exceptions in my past).

Also I'm not necessarily talking basic functionality here. I'm currently working for a client that's very picky about the look and feel, so if a few pixels in padding get adjusted where it's noticeable, or a font color or size gets adjusted a bit, in one place and it affects something else, there could be complaints. And a test plan is not likely to catch that, at least not any on any projects I've worked on.

Let's say that there's some sort of list component that's used in like six other places (that's maybe not obvious because there's different configurations or something).

Six months later I work on a new page that incorporates that component that requires some sort of change in that component that could theoretically break it elsewhere, at least how it looks or something, like alters the padding or something in a way that shoves things onto the next line in one of the instances.

If I don't mention what other places that component is used in my comments, are you going to know where all to look for the other instances of that component? Even if you look at the source code, it will only show changes, it won't say 'oh this component is used elsewhere' unless you actively bring up the source code yourself and do a code search yourself.

Because it's a visible component, maybe you'll just have the memory that something that looks like this is elsewhere, but maybe you won't remember. Or maybe you're fairly new to the project and aren't aware of these other parts of the site using it.

What about something that's even less visible, like something that takes in data and then sorts, transforms, and adds metadata to it? Then I make a change to it to accomodate for some new requirement on a new page. Maybe it's used for four other locations, but the changes only shows the function being altered and the new page using it. That change I made broke it elsewhere, but I don't mention where else to check in my notes. Are you going to think to check each place where data is loaded to make sure it's working correctly, without me explicitly telling you to check those spots?

If you can, great, you've got a real intuition for this that I doubt many QA people have. I don't even know to check these other places sometimes, and I worked on the code myself and can do a quick text search to see where else it's being used.

This was why I said what I did. It's not just about 'that area', the change could potentially affect another application in different repository entirely sometimes, especially if a shared library is involved. I've literally had like four or five of these situations happen in the past six months of my current project, where my change broke something elsewhere.

Usually I caught it, but I also told QA to check it explicitly anyway since I don't usually test things 100% (since I'm not QA). When I was a more junior developer, I missed these things more often and QA would sometimes miss it also since they didn't know to retest something.