Riesame agile

In generale, il codice non "va male" da solo. non arrugginisce, non richiede carburante o lubrificazione, non si indebolisce con l'uso. Se l'unica variabile nel tuo sistema è il tempo, non è necessario ripetere il test, a meno che tu non abbia motivo di ritenere che non sia stato testato in modo appropriato in primo luogo.

Ora, se il sistema è cambiato, è necessario testare tali modifiche. Se non sono stati testati, dovrebbero esserlo.

Quindi, penso che la risposta alla tua domanda risieda nella risposta a quest'altra domanda: quando il sistema è stato modificato, è stato testato correttamente (cioè: è stato testato anche tutto il codice dipendente?)

L'unico modo in cui agile risolve questo problema è che specifica che il software deve essere testato correttamente prima di essere considerato "fatto". Se lo facessi, non dovresti avere nulla di cui preoccuparti.

Detto questo, dovresti anche chiederti quale sia il costo per testare o meno. Se non si esegue il test e il sistema non funziona, quanto è grave? Sarà catastrofico o solo scomodo? Se stai parlando di mandare un probe su Marte, la risposta sarà diversa da quella del caso in cui non riesci ad aggiornare un dashboard basato sul web nelle statistiche settimanali del gioco.

Non credo che questo scenario abbia qualcosa a che fare con un processo agile o meno. Lo sviluppo del software dovrebbe avere un tempo predefinito per la regressione. In un modello Scrum, probabilmente stai eseguendo ogni sprint.

Dovresti anche esaminare i test unitari automatizzati e altri modi per incorporare la tua regressione nei tuoi build. Ciò ti consente di avere un feedback continuo sul fatto che la tua logica aziendale funzioni ancora in caso di cambiamenti.