[Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Giovanni Porcari]

> Il giorno 18 mar 2016, alle ore 11:02, enrico franchi <enrico.franchi a gmail.com> ha scritto:
> 
> 
> 2016-03-15 18:22 GMT+00:00 Carlos Catucci <carlos.catucci a gmail.com>:
> Questione di scala Enrico.
> 
> A me verrebbe dire anche questione di business, piuttosto. O se vuoi, del tipo di business e del modello di deploy che hai.
> 
> Per esempio se fai sw "boxed" i rilasci sono costosissimi e vuoi certamente dell'infrastruttura massiccia di QA. D'altra parte per la maggior parte dei sw l'utente si aspetta che ci siano dei bachi. Insomma, Word (o chi per lui) ogni tanto crasha. Lo sappiamo tutti e continuiamo ad usarlo (magari usiamo il "chi per lui", che a sua volta ogni tanto va giu'). Pero' grosso modo e' su... il motivo e' che di fatto l'infrastruttura e' interamente in mano all'utente. Che d'altra parte vuole dire che determinati tipi di testing diventano molto piu' complicati. Il caso "pessimo" e' quello dei giochi che magari hanno bachi nei motori grafici che sono triggerati solo da certe combinazioni di un certo modello di scheda video con una certa versione dei driver su una certa versione di un certo sistema operativo.
> 
> Se c'e' un baco, si considera ok aspettare qualche mese per avere una minor version che lo aggiusta. Inoltre, se si introduce un baco, basta dare un buon modo all'utente di usare la vecchia versione e probabilmente gli si da solo un fastidio marginale. Non solo... certi utenti si aspettano che la nuova versione abbia bachi e prima di "adottarla" la testano. Pochi, eh... ma spesso quelli per cui e' veramente critico lo fanno.
> 
> Il modello dei servizi web e' opposto. Ci si aspettano rilasci brevi. Ci si aspetta che il software sia sempre su. I bachi sono una cosa statistica: ovvero sappiamo che per qualche utente ci saranno dei problemi, ma fintanto che il singolo utente non ha problemi troppo spesso si puo' tollerare. Poi ci sono un mucchio di cose che sappiamo che andranno storte... quindi via di retry. Che so... se faccio una chiamata ad un servizio, puo' andare male anche solo per questioni di rete o del momento in cui succede. Ma magari il servizio di per se e' su e non c'e' davvero un "baco" nel codice. Riprovo tutto e vado. Magari l'utente stesso e' disposto di tanto in tanto a ricaricare la pagina per aggiustare una situazione.
> 
> E anche qui... e' diverso fare un servizio che "vendi" ad un'azienda il cui business ne dipende. Se "vendo" un servizio di billing per ecommerce e io sono giu', i miei clienti non possono fatturare. Non saranno tolleranti. Se fallisco una transazione su 100, non saranno contenti. Se a mia volta il mio servizio e' un ecommerce, gli stessi problemi sopra descritti possono volere dire meno vendite e meno soldi. Downtime vuole dire perdite monetarie quantificabili immediatamente. Non solo... non posso nemmeno facilmente testare il mio codice in produzione (ovvero, iniziare a deployare timidamente e sperare che funzioni tutto). Viceversa se sto facendo un servizio per condividere una bacheca di puttanate con i miei amici, posso: 1) fallire di tanto in tanto, inoltre, siccome molti fanno sta roba dal cellulare, potrebbero addirittura pensare che non sono io a fallire, ma che e' la connessione che e' singhiozzante; 2) testare feature su pochi clienti alla volta... posso anche convincerli di essere fortunati a starmi facendo da beta tester a gratis. Un celebre servizio di microblogging aveva problemi immensi di availability eppure si e' comunque espanso.
> 
> Comunque a prescindere da quale situazione sia, in generale "non so chi sono i miei clienti". Ovvero sono tanti, continuano ad entrare e, potenzialmente, ad uscire. Mi possono abbandonare probabilmente con un costo limitato. La mia reputazione e' una cosa globale, invece: qualche post su twitter di persone chiave puo' crearmi grossissimi problemi. Tutti sanno chi sono (o per lo meno, tutti quelli che sono interessati al tipo di servizio che sto vendendo/proponendo).
> 
> Se quello che fai e' invece offrire soluzioni "individuali" per clienti, e' un mercato ancora diverso. C'e' un rapporto piu' stretto. I tempi in qualche modo li da il cliente (mentre se faccio servizi web i tempi li da "il mercato" -- se siamo i secondi a rilasciare questa feature abbiamo perso la battaglia -- oppure essere quasi interno -- rilascio questa feature quando e' pronta, o ancora, rilascio tutte le settimane, ma includo nel rilascio solo quello che e' pronto). E poi dipendera' di volta in volta come vengono fatti deployment, aggiornamenti, new release; se le macchine sono mie o del cliente, quanta gestione ho sulle macchine, etc etc etc.
> 
> 
> Questo solo per dire che siccome i modelli di business sono davvero diversi, non e' affatto detto che una strategia completamente accettabile in una situazione sia completamente suicida in un'altra.
> 


Trovo tutto questo estremamente logico e ottimamente descritto.

Il modello che prevede decine di migliaia di utenti casuali presenti contemporaneamente
probabilmente farà cose 'relativamente' semplici e con una GUI adatta ad utenti casuali.

Se invece scrivo un'applicazione per la gestione dei trasporti dove nella stessa  pagina
ci parecchie viste, bottoni a iosa, drag&drop di elementi da una vista all'altra,
dialog che spuntano a richiesta di azioni dell'utente, è ovvio che non è per utenti
casuali.

Altrettanto ovvio (almeno per me) che ogni volta che si fanno delle modifiche o delle
aggiunte di un certo peso (non quindi il css che colora in rosso una riga se il camion
non è arrivato) l'utente dispone anche di un'istanza (sempre in claud) di test
con i dati prelevati ogni notte dal db primario.

Su quella istanza pasticcia un paio di giorni controllando tutto quello
che è vitale che funzioni in tempo reale (e nei trasporti se tieni fermo
un camion perchè non puoi stampare la lista di carico la gente si incazza).

Se nel server di test tutto è ok si aggiorna alla stessa release il server di produzione
con la ragionevole certezza che le procedure critiche sono state testate dagli utenti.

Mi piacerebbe avere un sistema di test che mi segnali che se l'utente dragga
una riga di trasporto da eseguire nel viaggio previsto per domani
e se poi cambia idea e la toglie e la mette nel viaggio della settimana
seguente per un altro trasportatore c'è un baco per cui a video la prima riga
risulta ancora visibile.

E via dicendo per qualsiasi tipo di evento sia generato da n utenti che lavorano su
un sistema di questo tipo allocando e deallocando risorse di trasporto.

Se esiste un sistema di test di questo genere e se posso implementarlo ai prezzi da
fame che i clienti sono disposti a pagare vi prego di dirmelo :).

Per me è poi un fattore estremamente importante che la quasi totalità di un applicativo
stia nel framework perchè posso testare su applicazioni non mission critical le versioni nuove
e poi passare in produzione quella  versione del framework dopo dei test sul campo
piuttosto esaustivi.

Se viceversa avessi moltissimo codice replicato nel layer applicativo mi sentirei 
molto più a rischio.


Ciao :)


G