ramcrack ha scritto:
Io non ho mai lavorato in una software house grande, e non sò neanche cosa sia un flaky...
Solo per curiosità di cosa si tratta ?
Grazie
Azzz... qui si apre un mondo (... ma cribbio... tutti 'sti studi universitari... e poi non si sa nulla? n.b. non è riferito a te, ma in generale)
Allora nel "mondo normale" gli sviluppatori sono pochi e si conoscono.
Nel mondo "grande" gli sviluppatori sono magari 100 e stanno in luoghi fisici diversi.
Come li si fa collaborare?
Non è per nulla facile, e non c'è un modo "migliore", anzi si va avanti per tentativi ed errori.
Tra i vari approcci (li insegnano all'università?) uno - molto diffuso - è quello per il quale agli sviluppatori viene data "mano libera" di postare modifiche nel branch dei sorgenti (delle build di sviluppo ovviamente).
Ma, ad ogni sviluppatore, viene dato una serie di test (anche molto stringenti) cui il programma che sviluppa deve soddisfare.
Questi test vengono svolti in maniera automatica (... li insegnano all'università?...), per banalizzare diciamo che c'è qualcosa di "magico" (in realtà qui si apre un pippone gigantesco ) che sottopone i programmi a un tot di test di funzionalità.
Se i test passano significa che le modifiche non hanno "rotto" nulla.
E' infatti elemento comune cambiare che so il sorgente pippo.cpp che come effetto collaterale "rompe" pluto.cpp.
Penso sia una cosa che chiunque conosce bene.
OK, dando per scontato che esistano questi test (di cui non sappiamo nulla) e una qualche procedura automatica che li applica ai programmi, usualmente si lavora con "livelli" diversi di test
- test sulla macchina del programmatore. se passano => posti in un livello superiore
- test sul livello superiore. se passa => aumenti di livello
...
- test sull'intera applicazione (e possono essere anche un migliaio di test complessivamente)
- li passi tutti ? => ok pronto per andare in produzione (una volta si diceva bruciare il CD)
---
Ovviamente la questione è ben più complessa, qui ho fatto la versione breve di UN approccio (non di tutti).
Bene, c'è un problemino.
Mentre i test di qualcosa di "statico" sono facili (tipo che so conferma che la somma delle righe della fattura corrisponda col totale), c'è il "piccolo" dramma dei test delle applicazioni web.
Quelle in cui, per capirci, è l'UTENTE che spippola col mouse.
Si pensi, ad esempio, a GMAIL ed a voler introdurre una qualche nuova funzione.
Come faccio a testarla? Non solo ho 1000 browser, 1000 sistemi operativi, 1000 antivirus eccetera.
Ma avrò anche qualche MILIONE di utenti che seguiranno strade diverse.
Clicca qui, clicca là, clicca su, clicca giù.
---
Quindi da una decina di anni (ma non lo insegnano, all'università?) al classico problema dei test si è aggiunto quello dei test... delle web application.
Come si fa? Ci sono vari metodi, uno è quello di "automatare" il browser, ad esempio con il mitico selenio-nella-tazza-del-wc (o metodi simili, suppongo google abbia il suo)
Vabbè in sostanza si cerca di fare, con opportuno linguaggio, il test ANCHE dei sistemi che usano interfacce grafiche (il che significa tipicamente web, ma non solo)
---
Bon, arriviamo ai flaky. Che sono i test che falliscono. Talvolta. E talvolta no.
Il mondo in cui, dato un set di test A applicato a un programma X, desse come risultato 0/1 in maniera deterministica renderebbe felice ogni responsabile di prodotto.
Purtroppo no, non accade così. Capita che il test Y fallisca, per un motivo non ben chiaro, e che magari rieseguito domani vada a buon fine.
Questa "meraviglia" capita spesso, anche nell'ordine di un 10% del totale (dipende da vari fattori) e, spesso e purtroppo, PROPRIO nei test più rognosi (quelli col selenio, o simili).
---
Quindi parte tutto un Beautiful micidiale su come ridurre i flaky, come gestirli, se usare una sorta di approccio a "sezioni critiche" (cioè partizionare i test fra indispensabili ed opzionali), gestire l'ambiente (nel 90% dei casi è quello che rompe le @@)...
... insomma... un disastro.
Ovviamente dire "che problema c'è, basta che uno studi bene il sorgente e il test" non prende in considerazione che parliamo di sistemi grandi(osi), non del programmello access per fare i DDT.
Possono volerci giorni, o anche settimane, o anche mai, per capire esattamente cosa accade.
---
Perchè la situazione è grosso modo come quella di fare l'elettro cardiogramma a qualcuno.
Ma prima dovrai (sto inventando)
- stenderlo
- aprirgli la camicia
- tagliargli il pelo sul petto (se c'è)
- applicare gli elettrodi
- collegare i cavetti
- accendere l'apparecchio
- misurare
- decidere se il cardiogramma va bene.
Ma se, nell'esempio, mentre accendi l'apparecchio, per sfiga, c'è una TAC che opera da qualche altra parte, e che ti fa un minisbalzo nella tensione, leggerai qualcosa di diverso.
Poi la TAC la spengono, ma quando rifarai il cardiogramma ti trovi un risultato diverso.
E, come qualsiasi sviluppatore sa, problema che si ripresenta semplice è banale (da individuare e correggere), quello che appare e scompare, e magari appare una volta ogni 100, è un vero e proprio incubo.
---
Non apro pippone-spiegone sui vari approcci per MITIGARE (non eliminare) il problema.
Cribbio... ma cosa insegnano all'università...
In estremissima sintesi: l'ingegneria del software, tipicamente insegnata nelle università italiane, va bene per i programmini per il salumiere. Non c'è nulla di male in questo, anzi magari ci sarà pure qualche polo di eccellenza dove invece formano benissimo, ma quello che cerco di spiegare è che
"soccmèl ho dato ingegneria del tortellino volevo dire del software all'università di Montesgrippone so tutto quello che c'è da sapere sulla creazione dei programmi" è, come dire, un pochino eccessivo.
Anche perchè, per inciso, è tutto in divenire. Non ci sono studi accademici su argomenti che l'accademia non conosce, nè può conoscere.
I problemi di google, o di facebook, o di instagram, non sono sui libri di testo.
"Saltano fuori" mano a mano, e i libri di testo li scrivono google, facebook, instagram eccetera.
Poi - ed è molto interessante la proposta sui flaky degli svizzeri - l'accademia cerca di "trarne insegnamento", magari per formare (tra un venti anni) gli studenti sulle necessità di oggi (2018), invece che di quelle del 2038.