I test nei software, e in particolare di automazione, sono una parte odiata da tutti.
- Dal cliente, che lo vede come “una perdita di tempo inutile che mi fai pagare” (dì la verità, anche tu , come cliente, quante volte lo hai pensato?)
- Dal commerciale, che lo vede come “un costo che si poteva evitare“
- Dai tecnici programmatori , che vedono la “loro creatura” messa alla prova ( inoltre la creatività che serve per fare un buon test è fuori dalla forma mentis di un programmatore!)
In realtà, la parte di test è fondamentale in tutti i software. Ancor di più quando si parla di “far muovere” impianti o “gestire” la produzione.
Ecco come procediamo – a grandi linee – in Elteco per essere sicuri che ” facciamo il sottovuoto della lampadina” in modo perfetto.
Test sulle singole righe del codice
Come essere certi che il lavoro non sia “difettoso” sin dall’inizio? Occorre effettuare un test sui singoli pezzi di codice.
La domanda a cui rispondere è
” Queste righe di codice fanno davvero quello per cui sono state progettate?”
Questa fase è (se vogliamo) tecnica: è scienza, non creatività. Applichiamo gli standard di progettazione, con check list di controllo, e li verifichiamo .
E già che ci siamo, una prima valutazione va anche ai commenti: “I commenti al codice sono scritti in un italiano comprensibile anche a chi sarà nel suo ufficio tecnico della azienda cliente e dovrà interpretare quello che ho scritto?”
“I commenti al codice sono scritti in un italiano comprensibile anche a chi sarà nel suo ufficio tecnico della azienda cliente e dovrà interpretare quello che ho scritto?”
Test sulle singole fasi di progettazione
Una volta completate le singole righe, il codice viene testato in situazioni teoriche di utilizzo, per mettere sotto esame le singole fasi.
Questo permette di avere via via un quadro più preciso della situazione d’uso e serve anche per dare fluidità al codice: togliendo ridondanze e rendendo performanti le parti di codice poco scorrevoli.
Test completo del software (il cosiddetto test funzionale)
A questo punto, tutte le fasi di progettazione del software sono complete. Tutte le righe di codice hanno già passato due controlli. Adesso c’è il terzo test: quello in cui si definisce se tutti i pezzi, messi assieme, fanno effettivamente quanto richiedono le specifiche concordate con il cliente .
In altre parole, ci domandiamo:”Siamo riusciti a “dare l’altalena che il cliente voleva”?
“Siamo riusciti a “dare l’altalena che il cliente voleva”?
Vignetta tratta da www.pmforum.it
In questa fase, occorre essere creativi. Essere come Sherlock Holmes. Essere inventivi. Occorre creare casi d’uso specifici, fuori standard, improbabili ma possibili. Quando il software ha superato questa fase, siamo a un buon punto.
Attenzione però: arrivati qui, però, fare delle correzioni è sempre difficile : ecco che aver “perso tempo ” nelle prime fasi fa risparmiare complicazioni inutili. In questa fase, testiamo ulteriormente anche la velocità di esecuzione.
Se abbiamo fatto bene “i compiti”, soprattutto durante la fase due, avremo un codice performante.
Il test di compatibilità con altri software/sistemi operativi/versioni di software precedenti.
Non è necessario dirlo (o forse si?) , ma ogni test deve comunque tener conto della compatibilità sia di altre piattaforme, sia di altri software. Questa è una situazione con cui abbiamo a che fare spesso!
Il test di usabilità
A questo punto abbiamo sviluppato tutto un software di automazione; siamo anche ragionevolmente sicuri che funzioni, non abbia bug, sia performante e sia compatibile con eventuali altri software. Abbiamo finito? No , affatto.
Nelle fabbriche di oggi, occorre guardare anche alla usabilità del software. Il codice di una applicazione industriale senza bachi, veloce, performante non è sufficiente. Il fatto che “faccia quello per cui è progettato” non basta. Occorre fare attenzione a come l’operatore in fabbrica, in magazzino, in gestione controlli utilizzerà i dati, come li consulterà, come li imputerà.
Rendere “usabile”, “friendly” una applicazione di software di automazione industriale significa diminuire drasticamente il pericolo di errori da parte di operatori che dovranno magari seguire (proprio grazie alla nostra applicazione) più macchine /più forni/più linee di produzione
Occorre essere un po’ creativi e e mettersi letteralmente nei panni di chi userà quella applicazione, quel device, quell’ HMI.
Questa è una fase molto delicata, perchè, seppur pianificata accuratamente nelle specifiche tecniche iniziali, spesso in questa fase si rilevano miglioramenti da fare.
Ecco perchè l’interazione con il cliente finale è sempre basata sulla massima fiducia reciproca: solo in questo modo i suggerimenti sono valutati come un miglioramento.
“Ma quanto tempo “in più” ci mettete per fare i test?”
La domanda è mal posta, direbbe qualcuno. E in effetti la domanda più giusta è: “Quanto tempo, produzione, fermo macchina eccetera perderemo se i test non venissero fatti bene?”
Conclusione
Il nostro scopo è consegnare un software perfetto come il sottovuoto della lampadina accese da 117 anni.
Ecco perchè i test nel software di automazione sono disciplina, ma sono anche creatività: occorre gestire assieme a rigide check list di controllo e di test anche l’imprevedibile, il caso, l’informazione imperfetta. Per fare questo occorre tempo, passione, attenzione.
E tu, nella tua azienda, il tuo ultimo progetto di automazione industriale quanti bug ha rilevato dopo la consegna?