[Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

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.


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20160318/e927bf1e/attachment.html>