Tag: software

È inutile dire, spiegare, ribattere sul perché fare i test del software è utile ed importante: e se ne possono fare di molti tipi. Il semplice test su un caso d’uso, il test di integrazione (per le nuove funzionalità), il test di usabilità, molti altri poi, ma non ultimo test di regressione. Cioè quel test che serve a controllare che la nuova versione del programma faccia ancora le cose che faceva prima.
Sembra una scemenza, ma a volte le nuove funzioni possono interferire con le vecchie. E ovviamente non deve accadere.
Ora vediamo un caso di test egregiamente svolto.
Il server SQL che ospita i database di tutti i nostri programmi aveva bisogno di una bella rinfrescata al sistema operativo. Visto che aggiornare il S.O. (nel caso windows server 2003) è un’operazione di qualche ora, si è stabilito di fermare un pomeriggio tutte le attività e di lasciare agli amministratori il tempo di lavorarci su. Ieri era il giorno fatidico e le 12.00 l’ora X.

• Ore 11 il capufficio ufficio CU ri-segnala ai nostri utenti che un’ora dopo il database sarebbe stato spento.
• Ore 11.20 il dirigente dei nostri utenti (che chiameremo DU) ci scrive una email: “il programma DB_Uploader ha qualcosa a che fare con il database?” – quest’applicazione prende effettivamente dei dati e li carica sul database, e il suo gruppo lo usa quotidianamente
• Ore 11.25 leggiamo l’email e decidiamo di rispondere: “Sì, come già scritto nelle email di lunedì e giovedì scorso”
• Ore 11.35 DU risponde scrivendo a noi e ai suoi sottoposti: “Bene. Visto il fermo macchina del server sarebbe il caso di fare un test dell’applicazione DB_Uploader.” e conclude dicendo ad un utente (che chiamerò UT) “UT pensaci tu.”
• Ore 11.36 io e CU ci guardiamo sbalorditi e diciamo: “Cosa vuole fare?”
• Ore 11.37 io e CU rileggiamo l’email di DU
• Ore 11.37 e 30 secondi io e CU, ancora più sbalorditi, ci chiediamo: “Cosa si aspetta da questo test? Il database è spento quindi l’applicazione non funzionerà!”. Ridiamo e decidiamo di non rispondere
• Ore 12 come preventivato gli amministratori spengono il database e cominciano a lavorare
• Ore 12.20 UT risponde: “Adesso non riesco a provare, perché sono molto occupato. Appena torno da pranzo lo farò subito”. Io e CU pensiamo “UT, mangia pure tranquillo…”
• Ore 13.30 UT ritorna dal pranzo, e anche noi.
• Ore 13.37 UT scrive un’email a tutti: “Ho provato più volte il DB_Uploader e non vuole saperne di partire. Vi allego una schermata… Dice che non riesce a collegarsi al database… “
• Ore 13.37 e 1 secondo io e CU leggiamo l’email e in coro diciamo “MA VA’?”. Anche stavolta decidiamo di non rispondere…

Morale della storia

Quando prevedi di fare un test, devi più o meno immaginarti quale può essere il risultato.

Morale della storia 2

Se il capo ti chiede di fare un test scemo, devi più o meno immaginarti quale può essere il risultato. Il risultato può essere che passa per scemo solo il capo, solo tu, o tutti e due insieme…
PS: l’aggiornamento del server è andato a buon fine