No, TU lo provi!
Testare! Che passione, oppure no. Da quello che si vede negli ultimi tempi, il consenso generale e' che testare le cose e' una perdita di tempo. Non e' la prima volta che lamento del fatto che il software che si vorrebbe mandare in produzione non viene testato o viene testato in maniera a dir poco scadente, con i risultati che tutti si immaginano.
Ma se guardiamo al di fuori dell'industria (e con questo intendo IT), possiamo vedere che il concetto sta perdendo terreno in generale.
Alcuni anni fa' vi fu' un grosso scandalo perche' una arcinota casa automobilistica tedesca (cough!Cough!VolkswageCOUGH!), aveva "aggiustato" l'elettronica dei motori in modo da passare tutti i test di "economia" ed "ecologia" con il massimo dei voti per poi ritornare a valori piu'... "normali" durante l'uso normale del veicolo. In sostanza avevano prodotto un sistema che passava i test, ma poi non funzionava nello stesso modo. Ultimamente un fabbricante di aereoplani di linea, si e' ritrovato con diverse CENTINAIA di aerei immobilizzati al suolo perche' il loro software non era stata testato in modo proprio soddisfacente, ma aveva passato tutti i controlli automatizzati.
Chi legge delle pubblicazioni tecniche, siano esse on-line o cartacee (esistono ancora?), e' abituato a trovare bugs, anche parecchio pesanti, riportati in prodotti distribuiti a cani e porci che avrebbero dovuto essere trovati ad un controllo approssimato, ma sono passati inosservati per anni, in alcuni casi decenni, e sono identificati solo adesso. Ed in molti casi sono talmente solidificati che non c'e' veramente modo di risolverli senza rendere un sacco di cose ben poco funzionanti (o completamente NON funzionanti).
Da ogni parte si alzano grida, strilli ed imprecazioni. Perche' questa cosa (qualunque cosa sia) non e' stata PROVATA?
E la risposta e', in molti casi, perche' PROVARE LE COSE COSTA TEMPO E SOLDI. E, come dimostrato in molteplici casi, non e' che "provare" vuol dire trovare tutti i problemi che ci sono. Alcuni sono cosi' ben nascosti che passano inosservati lo stesso.
Quello che vediamo, sempre di piu', e' che i produttori di software spingono per avere delle "pre-release", chiamiamole "alpha" o "early access" o quello che volete. Il punto e', il prodotto non e' pronto per il rilascio, ma chi vuole (o non vuole aspettare), puo' usarlo subito, per una modica somma, e mandare al produttore i bug che trova.
Questo, che e' sostanzialmente "usare i tuoi clienti come tester", che e' denunciato da parecchia gente come pratica abbastanza "sporca", e' piu' o meno una normalita'. E, almeno per quanto mi riguarda.... E' un'ottima cosa.
Ok, mettete via i forconi e le torce, che l'assicurazione non paga gli incendi dolosi provocati da folle inferocite.
Quello che intendo dire e' che, in moltissimi casi, l'unico modo di trovare dei problemi in certe cose e' avere qualcuno che NON HA LA PIU' PALLIDA IDEA DI COSA STA FACENDO, provare il vostro prodotto e vedere che cosa combina. Si, esistono individui specializzati nel fare esattamente questo, ma in genere queste persone vogliono essere PAGATE, e piu' sono esperti piu' soldi vorrebbero. Il che va benissimo, ma in molti casi la societa' che produce il "prodotto", non ha piu' soldi da spendere al di fuori di quelli che ha gia' pagato per gli sviluppatori. In molti casi manco quelli. Quindi la via del "early access", e' l'unica possibile. No, in molti casi non e' la migliore, in molti casi la societa' in questione non ha alcun interesse nel correggere gli errori che sono trovati dai malcapitati "testers", ed in alcuni casi, la societa' in questione potrebbe tranquillamente permettersi di pagare orde di tester professionisti (Microsoft), ed in alcuni casi lo fanno pure, ma poi usano la via del "pre-release" lo stesso.
Ed in alcuni casi, il "prodotto"... Non e' proprio il caso di "provarlo" sulla pelle di malcapitati utenti... come certe linee aeree hanno scoperto sulla loro pelle, o sulla pelle dei loro "clienti" ultimamente. Voglio dire, se $casaautomobilistica decidesse di "provare" un nuovo sistema di freni "attivi", gradirei essere informato sulla possibilita' che premere il freno della macchina risulti in un incremento della velocita' invece che la reazione che mi aspetto normalmente...
E dopo questa provata introduzione, passiamo ai fatti e misfatti.
Esisteva tempo fa', e purtroppo esiste tutt'ora. Una societa' che forniva diversi servizi. Uno di questi servizi era, in effetti un sistema di "scambio messaggi", aka POSTA, che veniva usato per lo piu' come sistema di comunicazione B2B. E se non avete idea di che cazzo vuole dire, immaginatevi due computer che "parlano" tra di loro scambiandosi dei messaggi di posta elettronica. Quindi uno dei due computer manda un messaggio all'altro, quest'altro lo legge ed, eventualmente, manda indietro una risposta che ha ricevuto oppure no.
Se avete mai usato una mailing list, avete una mezza idea di che si tratta. Quello che oggi viene "venduto" come "AI" o "ChatBot", che regolarmente non funzionano o fanno semplicemente schifo, e che funzionavano perfettamente bene 20 o 30 anni fa insomma.
Allo scopo di ottenere un sistema molto flessibile, questa gente aveva selezionato come "backend" dell'intero arnese un software prodotto da una certa societa' tedesca, software che consentiva di fare tante cose, ad un prezzo parecchio alto pero'.
Tuttavia, venne il giorno in cui la societa' in questione, decise che era il momento di cambiare tutto perche' comincia ad essere piuttosto vecchiotto. E comincia anche a non essere piu' mantenuto. In effetti certe cose, come l'antispam, erano rimaste abbastanza indietro. A ragione anche, dato che era pensato per B2B e non per "usi generici". Pertanto i nostri marpioni decidono di abbandonare il prodotto precedente e di usare una combinazione di postfix ed altra roba.
Tutto bello, se non che, essendo questo coso usato per B2B, cambiare il "mezzo" significa anche, potenzialmente, "rompere" tutto quello che ci e' attaccato.
In effetti, l'aggiornamento di un sistema, chiamiamolo "fratello", fatto precedentemente si era tradotto in una catastrofe che aveva prodotto un paio di centinaia di "tickets" nel giro di un paio d'ore ed un roll-back frettoloso nelle ore piccole della notte.
Chiaramente, l'UL della famossa ditta non aveva molta voglia di vedere una ripetizione della cosa con questa parte del progetto e premeva per una migliore gestione della transizione.
Ed e' qui' che io mi sono scontrato con il "project manager" della cosa. O meglio, con il project UNmanager.
Permettetemi di spiegare.
Esistevano due individui. Uno dei due aveva una buona conoscenza della parte tecnica del prodotto ma, tecnicamente, non era un "manager", l'altro non sapeva UN EMERITO CAZZO della parte tecnica o della parte operativa o della parte amministrativa... in effetti non sapeva un cazzo, ma ufficialmente era il project manager della cosa.
La cosa piu' logica sarebbe stata, secondo me, mandare il secondo a scopare il mare e "promuovere" il primo a "project manager". Il problema e' che quest'ultimo non aveva NESSUNISSIMA intenzione di assumere il ruolo di "manager". Perche' diciamo la verita', essere "manager" dovrebbe anche significare essere RESPONSABILE, e questo era anche il tizio che aveva deciso di mandare in produzione quel coso di cui ho detto prima, ben sapendo che non era mai stato testato e senza nessuna informazione inviata ai clienti prima della cosa. Sostanzialmente aveva deciso unilateralmente di girare il tasto e quando aveva visto i casini cominciare a rotolare dentro, aveva fatto marcia indietro alla velocita' della luce.
Siamo pertanto in discussione per mettere in produzione questo nuovo 'coso'. Io, questo UL che non e' un 'UL' ed il project manager che lo sarebbe (UL2).
IO - ...quindi gli utenti sono tutti creati, pero' i messaggi vecchi sono ancora in fase di copia, ed i messaggi che sono sul sistema nuovo sono tutti marcati come "non letti", questo e' purtroppo un effetto non eliminabile.
UL - Perche' non e' eliminabile?
IO - Perche' non ho idea di quali messaggi sono stati effettivamente letti o no nel prodotto precedente, non c'e' modo di estrarre l'informazione se non leggendosi l'intera mailbox via IMAP e ci si mette una eternita'.
UL2 - E questo che significa?
IO - Che dobbiamo informare gli utenti della cosa e lasciare che facciano quello che meglio credono con la cosa. Se e' un problema avere i messaggi non letti basta che li muovano in una diversa mailbox prima della migrazione e sono a posto, se non e' un problema se ne possono fregare.
UL - Ma in questo caso dobbiamo comunicare la cosa ai clienti...
IO - Ovvio che dobbiamo farlo. Sarebbe molto, ma molto meglio, comunicarlo prima ed avere i clienti provare la cosa prima di andare in produzione.
UL2 - Perche'?
IO - Perche' qui non stiamo parlando di leggere la tua posta, stiamo parlando di un sistema di B2B, sono computers che leggono i messaggi, se qualche cosa cambia e' possibilissimo che la loro parte non funzioni piu'. E dato che il prodotto precedente non e' molto chiaro cosa faccia con questa roba, la cosa migliore da fare e' avere chi lo usa effettivamente fare i test funzionali.
UL - Ma noi dovremmo fare tutti i test prima.
IO - Sono d'accordissimo, ma non possiamo farli. Non possiamo perche' non sappiamo NIENTE di come i vari clienti usano questa roba. Noi possiamo solo prendere i messaggi e buttarli in una casella di posta. Ma cosa succede dopo non lo sappiamo. Inoltre... Tu volevi andare in produzione sabato, quando volevi farli questi test esattamente?
UL - No io volevo andare in produzione ma poi c'e' il billing...
IO - Si', io ti ho fatto notare che andare in produzione a cavallo del billing non era proprio una bella idea, ma il punto rimane. Se vuoi andare in produzione il giorno X e vuoi "fare dei test" sul sistema prima di quel giorno, dovrai avere un piano di cosa testare no? Quando vuoi farlo quel piano? X-5 minuti?
UL - E' che sono molto occupato...
IO - Questo non mi riguarda. Sei tu che hai mandato in giro quel "piano" in cui specifichi che prima del "go" vuoi fare dei test. Quindi?
UL - Tu hai dei suggerimenti al riguardo dei test?
IO - Sicuro. Contattiamo due o tre dei clienti attuali e facciamo testare a loro il sistema.
UL ed UL2 in coro - CHE??
IO - E' il sistema migliore. Loro sanno cosa succede prima, durante e dopo. Se lo provano e dicono che funziona vuol dire che funziona. Se no, vuol dire che abbiamo del lavoro da fare.
UL - Ma che succede se questo cominciano ad usare il sistema senza billing??
IO - Questo e' un problema diverso e completamente sconnesso dal "testing". E comunque sia, se volevi andare in produzione sabato, avrai anche avuto un'idea al riguardo. O volevi pensarci dopo il "test" (che non c'e' mai stato)?
UL2 - Ma che cosa dovremmo comunicare ai clienti? E chi dovrebbe farlo? E come? E quando?
IO - E perche'?
UL2 - Come perche'?
IO - No dicevo... hai fatto tutte le domande...
UL2 - Eh?
IO - (massaggiandomi il naso)... Dobbiamo comunicare che stiamo facendo una migrazione ad una nuova piattaforma che e' anche l'ora dato che siamo nel 20XX e che pertanto ci saranno dei cambiamenti nell'infrastruttura, nuova interfaccia di gestine, nuovo questo, nuovo quello eccetera eccetera, pertanto prima di andare e' meglio se questa gente verifica che il sistema nuovo continua a funzionare come dovrebbe. Noi diamo i nuovi IP e loro fanno le prove. Dovrebbero metterci un paio d'ora a verificare se le cose funzionano.
UL - Ma... E se troviamo dei problemi?
IO - Ed e' per questo che facciamo i test. A quel punto dovremo vedere che problemi e come o se risolverli.
UL2 - Che problemi potrebbero esserci?
IO - Non ne ho la piu' pallida idea, e' per questo che dico che i clienti sono gli unici che possono fare dei test funzionali che siano.. hemm... funzionali.
Si perche' in molti casi, o te lo provi da solo o lo fai provare da chi deve usarlo. E quando non hai idea di COME viene usato, hai una sola soluzione.
Davide
02/02/2020 11:52
