fbpx

I test di software in automazione

 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”?

Altalena e progettazione

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?

2019-03-20T18:00:48+01:00