Importanza test

Importanza test

Vi sottopongo un caso reale in cui si potrebbe creare un bug.

Carlo

• Modifica la lettura dei messagi di SALKI inserendo un semplice if-then-else del tipo: se il messaggio inizia con 'B' leggi in un modo altrimenti leggi nel modo consueto.
• In fretta si implementa la modifica per fare delle prove e dopo un po di tentativi funziona.
• Risolto il problema urgente Carlo dovrebbe chedere a Fabio di inserire nei dati di test un caso che faccia scattare la nuova lettura per metterla sotto test. Alla fine per non perdere tempo, tanto la modifica e' banale ed e' stata provata a mano, decide di soprassedere. Una riga di programma rimane non testata.
• Lancia i test e passano.....
  

Passano i giorni, la modifica e' finita nella versione ufficilale del sw usato da tutti.

Qualcuno DBL

• Per qualche motivo cambia la codifica del messaggio (invece di B, C) per fare magari una prova al volo e la modifica finisce nella versione "ufficiale" del sw DBL.

Qualcuno JAVA

• Riprende il sw ufficiale con la nuova lettura, non sapendo magari che e' stata fatta, perche riprende tutto il sw senza guardare le modifche per mancanza di tempo (cosa che avviene sempre da parte di tutti)
  
• Lancia i test e passano... tutto OK pensa!
  
• Fa delle modifche urgenti alla UI, magari toccando la visualizzazione proprio dei campioni.
  
• Lancia AlcXXX in ditta e tutto funziona perfettamente perche' casualmente riprende dei dati che non fanno scattare il nuovo tipo di lettura.
• Installa la procedura dal cliente con rete lenta etc, perdendo diverse ore...
• Cliente inizia ad usarla e funziona...

Passa qualche giorno....

• Cliente la usa pesantemente e chiama un campione con molte prove che fa scattare il nuovo tipo di lettura.
• Applicazione si pianta perche la lettura nuova non coincide piu' con la gestione DBL
• Qualcuno JAVA va in panico!?!?!  Dov'e il problema? UI crashia perche' la modifica che ho fatto di recente ha un bug? Problema della persistenza? Versione del seerviizo non corrispondente? BOH!!!!
• Intanto il programma magari e' stato scaricato nel frattempo su molte postazioni e web start ancora non aggiorna bene in automatico come dovrebbe...
• Qualcuno JAVA deve capire il problema, una volta individuato risolvero da solo o con altri, rifare il deploy del programma, ritrasferirlo, aggiornare le postazioni che hanno preso la versione non funzionante (alcune postazioni magari se ne accorgono giorni dopo...)

In conclusione: per non aver perso 15min? 30min? !1h? per creare il caso, si perdono diverse ore, con in piu' stati d'animo alterati, figura non molto bella presso il cliente (che essendo pubblico si arrabbia poco, ma se fosse un privato...)

XP programming

XP e' un metodologia  "leggera" per teams di dimensioni medio-piccole che sviluppano software avendo requisiti vaghi o che cambiano rapidamente.

A molti XP puo' sembrare una metodologia basata sul buon senso. Allora perche il termine X = estremo P = programmazione?
La risposta e' che XP porta questi principi di buon senso ad estremi livelli.

Cioe':

• Se la revisione del codice e' una buona cosa, revisioneremo il codice di continuo (pair programming = programmazione tra pari = io rivedo il tuo codice, tu rivedi il mio)
• Se testare e' una buona cosa, tutti testeranno sempre (unit testing), anche con i clienti (test funzionale).
• Se la progettazione e' una buona cosa, essa fara' parte dell'attivita' giornaliera di ciascuno (refactoring)
• Se la semplicita' e' una buona cosa, faremo in modo di lasciare il sistema con il piu' semplice progetto che implementa la funzionalita' correntemente richiesta (la cosa piu' semplice che possa funzionare).
• Se l'architettura e' importante, ogniuno lavorera' definendo e affinando l'architettura di continuo (metaphor = metafora)
• Se i test di integrazione (test i vari pezzi del programma insieme: es. WS + FileExServer + DBL) sono importanti allora integreremo e testeremo diverse volte al giorno (CI = continuos integration)
• Se iterazioni di rilascio del sf brevi sono una buona cosa, faremo le iterazioni molto, molto corte - secondi, minuti e ore, non settimane, mesi e anni (Planning game = gioco della pianificazione)
  

Adozione di XP dovrebbe portare i seguenti benefici:

Ai programmatori:

• Saranno in grado di lavorare sempre su cose veramente importanti, ogni giorno.
• Non dovranno affrontare situazioni pericolose da soli.
• Saranno in grado di fare ogni cosa in loro potere per portare il sistema al successo
• Prenderranno le migliori decisioni che possono prendere
• Non prenderanno decisioni che non sono i piu' qualificati a prendere
  

Ai clienti e manager:

• Avranno il massimo risultato possibile da ogni settimana di lavoro.
• Ogni settimana vedranno concreti progressi sugli obbiettivi a loro cari
• Potranno cambiare direzione al progetto nel mezzo dello sviluppo senza incorrere in costi esorbitanti
  

In sinstesi XP promette di:

1. ridurre il rischio del progetto: non portarlo a termine affatto o di non soddisfare le richieste del cliente
2. migliorare la produttivita' per tutto il ciclo di vita del sistema
3. sviluppare divertendosi in gruppo
   

Ancora su cosa e' XP:

• E' avere un feedback anticipato, concreto e continuo dall'adozione di cicli brevi
• E' una pianificazione incrementale la quale fornisce in poco tempo un piano generale che evolvera' durante il ciclo di vita del progetto
• Ha la possibilita' di schedulare in modo flessibile nuove funzionalita' per rispondere ai cambiamenti delle richieste del cliente
• Si basa su test automatizzati scritti dai programmatori e dai clienti per controllare il generale avanzamento dello sviluppo, per consentire al sistema di evolversi e scovare in anticipo i difetti.
• Si basa sulla comunicazione orale, tests, e sorgenti per comunicare la struttura del sistema e intenti.
• Si basa su una progettazione continuativa che dura fintanto che dura il sistema che si sta' sviluppando.
• Si basa sulla collaborazione degli sviluppatori che hanno capacita' simili
• Si basa su pratiche che funzionano sia con l'istinto a breve termine del programmatore e con gil interessi a lungo termine del sistema che si sta sviluppando.
  

XP e' una disciplina di sviluppo del software. E' una disciplina perche' ci sono alcune cose che debbono essere fatte per poter dire di stare sviluppando in XP. Non si puo' scegliere se si scriveranno i test o no: se non lo fai non sei estremo: fine della discussione.

TDD

In una frase possiamo dare il significato di TDD:"Scrivere soltanto il minimo codice necessario per far funzionare un test che fallisce".

• Prima scriviamo un test
• Poi scriviamo il codice per farlo passare
• Poi affiniamo il codice riprogettandolo (refactor), basandoci sul test appena scritto in modo da non rompere la funzionalita' appena creata nel tentativo di migliorarla.
  

Vantaggi per il programmatore:

• Raramente dovremmo avere chiamate di asistenza o finire in lunghe sessioni di debug
• Siamo confidenti sul lavoro da noi svolto (NON E' COLPA MIA SE NON FUNZIONA)
• Abbiamo piu' tempo per altre attivita' per migliorare come professionisti (STUDIO) e/o migliorare il sistema

Vantaggi per azienda (qualita'):