Implementation of changes to projects generates errors outside the implemented area - how to avoid this?

Question

Work organization

I seek advice from experienced programmers, team leads, or just successful web development teams.
-
The following problem systematically arises:
1) Programmers implement something on the site - for example, a new category on the site (or edits on the old category).
2) Checking the implemented (actually according to the delivered TOR) does not reveal any problems.
3) In places that, according to the TOR, were not affected by the inspectors, problems begin. Something fell off here, something there. Something else appeared where it shouldn't have, and so on.
As a result, it turns out that the task passes the test, but the result obtained, if something has gone wrong, is simply catastrophic.
-
There are several obvious "simple" solutions:
1) After any editing, check everything.
- Catastrophically unprofitable in terms of resources. You can reduce the time of checking by knowing conditionally "global variables" that participate not only in the section being checked, but also in others. And thus check only those places where this global variable is still involved. But the problem is that often there is no data about whether the variable is global or not (if it concerns a website). That is, there is no understanding that this particular menu is displayed not only in this section, but also in another place. In general, the path is unprofitable as I see it. And it is not clear who should be responsible for this check (whose resources will be spent on checking) - a programmer or a specialist who checks the task. Because who checks his task should only check it and check it, and not everything around.
-
2) Give for "carpet check" to all interested participants.
- That is, after laying out the edits - ask all those interested to "poke the project." While this is a fairly logical solution, it is not complete. First, there are no "poking" specifications. Secondly, this is not a "task" as such without specifications - it is a hope that "someone will find something", and if it was found later, then "well, you poked it badly." This is not quite a qualified statement of the problem as I see it.
-
3) A complex mechanism for accounting for all global variables before starting work. Requires a complete understanding of the project by the programmer before starting any work (or a system that will "shine" about changes in specific places in the project for accounting). Too unprofitable - it requires a huge preparatory period to "do something" - and it seems to me that this only happens if the entire development was on one team. If one or another contractor performs some work on the project, then it can be extremely difficult to understand at the stage of the first edits "what is tied to what". If we add here the craftsmen who make mega-crutches, which kill the actual hierarchy of the project, then the path is generally nowhere.
-
In general, the problem bothered me. The programmers I contact - shrug their shoulders - "that's how everyone does it" - and either one edit causes 3 additional jambs - or they spend a ton of resources on double-checking.
There are experts and experienced specialists in combat missions on the forum - I appeal to you, maybe you have found a solution to avoid this problem, when programmers, God forbid, generate 2 jambs for 10 solutions and they need to be fixed. But sometimes programmers on 1 solution generate 3 additional problems. And that's already pretty bad.
-
Question:
How to properly manage this issue?
How to properly prepare for changes and implementations in advance?
What should be provided so that it is not too resource-intensive?

Answer 1

On a large project, we implemented automatic tests (like Selenium), which ran the main user scenarios. Those. edits should not break critical product processes. The rest was caught by testers.
You may need to make some architectural changes if you have such dependencies.

Answer 2

You have raised a difficult question to which there is no single answer. Here it is necessary first of all to look at:
1. The values ​​of the company.
2. Architecture of the project/project.
3. Processes - management, development, testing,
4 . Resources - team, documentation, knowledge, skills, time, etc.
1. There is, roughly speaking, a set of values ​​that bring the company income.
For example, displaying a product catalog. The better the directory is displayed, the more users are stuck on the page, the more they buy/want/connect/ppc - whatever, it makes the company money. Breakdown of the catalog of goods threatens with loss of money/reputation/time/market. A breakdown somewhere in your personal account, mailing list or other place does not carry such threats. Actually, based on the existing values ​​and risk assessment, there should be a list of "important" functionality. The one that shouldn't break.
2. The project architecture can be a monolith in terms of risk assessment. Broke one function - breaks the whole system. Or maybe the system is resistant to problems - they broke one function, the system continues to work as a whole. Architecture should be chosen based on values ​​and risks. The most valuable part should be as isolated as possible from the problems of the rest of the system. The most valuable functionality should continue to work if some elements break down. For example, you changed the database structure of your product catalog - the catalog should continue to work. Let the data display be incomplete, but it will be. Put it in the design phase of the architecture. Refactor existing problem areas. Focus on values.
3. Processes are built on the basis of existing values.
For example, the process of agreeing on requirements for a task and testing how these requirements are satisfied by
the implementation must take into account values ​​- that is, take into account priorities. With a lack of resources, you should focus on the priority parts of the system. Management more carefully prescribes technical specifications for critical functionality, developers pay more attention, TLs conduct code reviews more carefully, testers test first of all what is important for business. Autotests are written first for business-critical functionality.
4. Resource - taking into account the above, requirements are put forward for the resource. If it takes 100 man-hours and senior-level specialists to test critically important parts of the system, these resources need to be allocated. Otherwise, allocate more time, or reallocate more specialists, computing resources to autotests.

Answer 3

This situation is called "regression" to prevent it, there are regression testing and other techniques to prevent errors.
Regression testing can be manual or automated. This is a separate big topic. You can even manually test not the entire application, but those parts that are likely to be affected by the fix.
Other practices include:
Practically, on each subject above there is a separate big book. Read books, learn English, look for information.