HAI MAI CONSEGNATO UN TEMA, UN ARTICOLO, UN LIBRO SENZA RILEGGERLO?
OPPURE LO HAI MAI MANDATO IN STAMPA COSI’ COM’ERA, SPERANDO CHE IL LETTORE O IL PROFESSORE TROVASSERO LORO I TUOI ERRORI ?
SE LO RILEGGI: OGNI QUANTO LO FAI?
Tu normalmente quando scrivi cosa fai, aspetti di avere scritto 300 pagine per dare una rilettura? O 50? Ovviamente la risposta è uguale per tutti: NO.
Questo è un esempio che faccio spesso ai miei clienti più digiuni dell’importanza teorica e pratica dell’attività di test del software.
Scrivere un software è come scrivere un libro: soprattutto quando si tratta di rileggerlo
Prendiamo uno studente, un professionista di un altro settore, un giornalista, uno scrittore. Possiamo prendere noi stessi come esempio, perché nella vita a partire dai banchi di scuola in poi, qualcosa l’abbiamo scritta: quando rileggiamo quello che abbiamo scritto?
Bene, a seconda di quello che facciamo di abitudine quando scriviamo, senza saperlo e anche senza mai avere scritto una linea di codice in vita nostra, abbiamo fatto un’attività di test:
- CORRETTORE GRAMMATICALE: ovviamente, usando un qualunque Word Processor avrai attivato la correzione grammaticale automatica che ti individua una buona serie di errori banali di ortografia e ti togli alcuni problemi. Questa è l’ANALISI STATICA (STATIC ANALYSIS). Ma è sufficiente? Ovviamente no: una MONTAGNA di errori di sintassi, congiuntivi, consecutio temporum, logica, coerenza, leggibilità ecc. non possono essere individuati da un correttore automatico.
Tu usi solo l’analisi statica e poi rilasci il tuo software o vendi il tuo prodotto direttamente senza ulteriori test?
- FRASE: rileggi, come fanno quasi tutti penso, una singola frase dopo averla scritta? O almeno ogni 2-3 frasi? Bene: questo è TEST DI FUNZIONE (FUNCTION TEST). Infatti tu vuoi essere sicuro che ogni singola frase che hai scritto stia in piedi, giusto? Che non abbia grossolani errori di sintassi, di punteggiatura, di ortografia? Fantastico: succede, o dovrebbe succedere anche nel software.
Testi ogni singola funzione del tuo codice in modo da costruire mattoncini sicuri e stabili, o speri che gli errori si sistemino più avanti grazie a qualcun altro che li trova al posto tuo?
- PARAGRAFO: tu scrivi, scrivi, metti insieme un po’ di frasi logiche tra loro e alla fine ti viene fuori un paragrafo. Stai cambiando leggermente discorso, vuoi chiudere un concetto o passare ad un altro avvenimento. Cosa fai? Rileggi le frasi, controlli che siano coerenti e lineari tra di loro, che il discorso sia coerente concluso? Stai facendo TEST DI UNITA’/MODULO (UNIT/MODULE TEST) perché controlli che tutti i tuoi paragrafi formino un insieme coerente tra loro.
Nella tua vita di sviluppatore o manager di un team, dopo aver messo insieme un po’ di funzioni, fai un test di ogni singolo modulo o speri che assemblando i moduli non testati tra loro prima o poi stiano in piedi da soli per miracolo?
- CAPITOLO: una volta scritto più paragrafi, vorrai controllare se stanno bene insieme? Se hai ancora una volta rispettato la Consecutio Temporum? Se il discorso fila, le frasi e i paragrafi scorrono bene, non ci sono lacune, contraddizioni, passaggi poco chiari? Se hai esaurito l’argomento, l’avvenimento in maniera completa ed esaustiva? Ottimo: non lo sapevi, ma questo è TEST DI INTEGRAZIONE SOFTWARE (SOFTWARE INTEGRATION TEST).
Il tuo codice è testato in maniera Big-Bang incrociando le dita solo quando è tutto pronto, oppure previeni i problemi provando prima il comportamento di pochi moduli elementari che interagiscono fra loro?
- LIBRO: perfetto, sei arrivato quasi alla fine. Hai Hai completato il tuo articolo, libro, documento, quello che sia. Che fai, lo rileggi da capo a fondo? Quante volte? Cerchi di capire se hai completato tutto quello da dire? Ricostruisci il filo logico di ogni singolo personaggio, avvenimento, argomento che hai trattato? Andando a cercare una visione d’insieme che è impossibile da trovare leggendo solo un singolo capitolo? Sei arrivato a fare TEST FUNZIONALE/TEST DI SISTEMA (FUNCTIONAL/SYSTEM TEST). E spesso, questa è l’unica attività che viene fatta dal 90% delle aziende non soggette a certificazione o “costretta” dal cliente.
Il tuo prodotto finale viene almeno testato prima di essere consegnato con delle prove funzionali di insieme? Verificando che ai morsetti esterni faccia quello che ci si aspetta che faccia? O speri che il tuo cliente sollevi furente il telefono per aver trovato gli errori lui per te? E come ben sai, i clienti sono MOLTO bravi a trovare gli errori più impensabili…
- CORRETTORE DI BOZZE: lo avrai sicuramente sentito nominare, è un concetto abbastanza chiaro anche a chi non si occupa professionalmente di scrittura. Uno scrittore fatica a vedere errori, problemi, lacune, mancanza di coerenza, contraddizioni nel proprio libro, perché è stato scritto in maniera talmente intensa e coinvolgente che lui stesso non riesce ad astrarsi e a vederlo dall’esterno, con occhi e animo diversi. Per quello che chiedi a qualcun altro di rileggerlo: il correttore di bozze, che è una professione vera e propria oppure può essere un amico, un collega, un parente che ti fanno un favore. Che stanno facendo per te l’equivalente del TEST INDIPENDENTE (INDIPENDENT TESTING), ovvero differenziando nettamente il ruolo di chi scrive e di chi testa il software.
Riesci a differenziare il ruolo di chi scrive e di chi testa il software, oppure speri di riuscire a sollevarti completamente dal tuo ruolo e a essere un giudice imparziale ed efficiente del tuo stesso lavoro?
- RILETTURA: ok, abbiamo capito che bisogna rileggere sempre, frase per frase, paragrafo per paragrafo e via discorrendo. Ma tu cosa fai quando rileggi un testo molto importante per te da pubblicare? Leggi una parola sì e una no? Salti qualche pezzo di frase? Leggi un paragrafo ogni tanto? Salti dei capitoli? Ovviamente no: tu rileggi TUTTO. Per concludere: la percentuale di quanto effettivamente rileggi o meglio testi nel campo software si chiama COPERTURA (COVERAGE).
Tu verifichi TUTTO il software che hai scritto, o ne lasci una parte mai testata in modo da far arrabbiare il cliente? Soprattutto, hai idea di quanto codice hai realmente coperto e quanto invece NO? E come lo misuri?
Ora ti faccio delle domande finali che ora ti saranno sicuramente più chiare:
- Perché dovresti vendere un software mai testato o testato male?
- Come pensi di proporre al cliente un software dove le singole funzioni, unità, moduli non sono mai stati verificati individualmente?
- E magari vorresti mandare sul mercato un prodotto che hai verificato solo alla fine mettendo tutto insieme all’ultimo minuto?
Sai qual è la differenza FONDAMENTALE tra un libro e il software?
Che un errore nel libro è noioso, tanti errori sono fastidiosi. Nel software invece, un errore grave:
PUÒ’ AMMAZZARE QUALCUNO (SAFETY CRITICAL)
PUÒ’ ROVINARE L’IMMAGINE DEL TUO PRODOTTO (QUALITY CRITICAL)
PUÒ’ MANDARE ALL’ARIA LA TUA AZIENDA (BUSINESS CRITICAL)
Sicuro che non valga la pena di investire in qualità e test?
Scrivi a blog@softwaresicuro.it per ricevere informazioni e whitepaper gratuiti sulle migliori tecniche di testing e la strategia di verifica ottimale per la tua azienda