Di qualcosa e di qualcuno bisogna fidarsi. Non si tratta di una scorciatoia, è il modo per non lavorare come dei buoi.
Se facciamo, per esempio, una funzione che somma due numeri, fare un unit test che provi le somme o farne cinque, sei oppure mille è la stessa identica cosa, infatti non potremo mai provare tutte le combinazioni di numeri possibili: dobbiamo solo verificare che il nostro programma sommi e che non faccia sottrazioni o altre operazioni. Fare tanti test significa provare "l'operatore somma" dello strumento e non ha senso: se non va, si cambia strumento immediatamente.
Allo stesso modo chi fa test di un' applicazione di database non deve provare il funzionamento del database stesso, perché se si scoprisse un bug sul database, bisognerebbe intervenire subito a sostituirlo o ad applicare una correzione. E' necessario avere dei punti certi, fissi.
Credo che troppo spesso nelle software house italiane si premi la velocità di sviluppo, perché la velocità determina il costo di produzione. Credo che questo dipenda in larga parte dal fatto che esse producono soluzioni con basso valore aggiunto, quindi il fattore determinante è il costo. E' chiaro infatti che produrre un sistema per una banca online senza il quale la banca non esisterebbe, ha un gran valore e il cliente è ben disposto a pagare la novità e la qualità. Fare lavoretti, che al massimo danno prestigio all'azienda di lustrini italiana, non porta valore e bisogna fare presto. Allora via libera a modi di lavorare alienanti e tempi asfissianti, che portano per assurdo a lavorare di più e a metterci di più.
Oltre alla frustrazione per il lavoratore, il costo è più alto! Vaglielo a spiegare.
I test vanno fatti con intelligenza, non con fretta.
