Testing software: Il test automatico e il test manuale

Testing software: Il test automatico e il test manuale

Il tester, come ben risaputo, ha il compito di verificare l’efficienza di un prodotto attraverso diverse prove pianificate a priori, ricercando un obbiettivo prefissato (analizzare il comportamento, la struttura ecc…). L’attività del tester viene dunque svolta quasi sempre manualmente; ci possono però essere dei casi nei quali sia più conveniente eseguire dei test automatizzati, utilizzando cioè opportuni strumenti software in grado di sostituire il tester nella sua attività.

Testing software - Il test automatico e il test manuale

Le ragioni che dettano questo sono riconducibili principalmente a motivi di tempo e di costo, ma raramente anche alla tipologia dell’applicazione: un esempio ci arriva dagli algoritmi genetici, nei quali la mole di calcoli da effettuare e la ripetitività delle operazioni spingono qualunque tester a desistere da una analisi manuale del prodotto; progetti che richiedano un test intenso svolto manualmente da 300 tester sono irreali e sicuramente anti-economici, quando lo stesso lavoro può essere eseguito in maniera efficiente da un software. In effetti, il test dovrebbe essere eseguito manualmente, in quanto così è possibile definire meglio il lavoro, organizzarlo ed eseguirlo in maniera più accurata. In alcuni casi, l’automazione ed il test manuale sono però spesso intercambiabili, mentre in altri scenari è più opportuno prendere una scelta per l’uno o per l’altro, valutando attentamente i costi ed i benefici di ciascuna tecnica; caratteristiche queste, che possono essere riassunte in un tabella come segue.

Testing software - test automatico vs test manuale
Test automatico vs Test manuale

Un problema che nasce spontaneamente, è quello riguardante la creazione della documentazione per il test e la pianificazione e realizzazione dei test-case. Nel caso di test manuale, il problema è relativo, in quanto il tester può eseguire sequenzialmente le prove e valutarne l’efficacia, eventualmente provvedendo ad una ristrutturazione o ad ulteriori analisi nel caso si accorgesse di anomalie; nel caso di test automatizzato le cose si complicano, in quanto occorre non solo capire il funzionamento del software di test utilizzato, la sua copertura del codice, la sua affidabilità ecc, ma anche distinguere quali parti del prodotto si ritiene opportuno testare automaticamente e quali invece esaminare manualmente.
La migliore soluzione in questo senso è costituita da un buon compromesso tra le due tecniche: una analisi sommaria ma completa da svolgersi sul prodotto e seguita da un affinamento manuale, intensificando le prove in quei moduli del programma che hanno dimostrato minore robustezza o affidabilità. È quindi il caso di dedicare una parte sostanziale del proprio lavoro alla redazione di un buon piano di test, che permetta di unire la velocità dell’automazione all’accuratezza della analisi manuale. Se poi sia conveniente optare per un test automatizzato e quanti bug potenzialmente non scoperti possano esistere è solo questione che varia da progetto a progetto.

Un secondo importante aspetto per l’azienda che esegue i test, è quello di valutare se sia più opportuno creare personalmente un’applicazione di automatizzazione, oppure acquistarla sul mercato. La scelta non è motivata solo da ragioni di costo, ma anche da motivi legati all’efficienza: i software acquistati da terze parti, hanno carattere generale, per via del fatto di poter venire incontro alle molteplici esigenze della potenziale clientela (del resto è impossibile); software personalizzabili sono possibili, ma occorre valutare i tempi, i costi e le modalità di attuazione. Valutiamo però la cosa più accuratamente: creare una applicazione per testare un prodotto può essere spesso eccessivamente dispendioso, con costi varianti in termini di efficienza ed accuratezza: è il caso di script che non necessitano di applicazioni di testing GUI (Graphic User Interface, interfacce grafiche per l’utente). E’ possibile muoversi in direzione di economizzare il prodotto di testing, ma questo non può rendere il prodotto economico in termini di risorse quanto un test manuale. I costi individuabili nella creazione di un proprio prodotto di test sono da ricercarsi ad esempio non solo nella mano d’opera, ma anche nell’istruzione del personale e nell’allontanamento dello stesso dall’attività reale dell’impresa che si concentra per tempi generalmente lunghi in attività differenti dalle richieste dei clienti con perdite di guadagno non indifferenti.

L’automazione del test, che richiede ad ogni modo uno studio preventivo fatto dall’uomo ed un controllo continuo, è utile nel caso dei regression test, ovvero di test da ripetersi identici su più versioni di un prodotto. Tuttavia l’automazione del test è una cosa che richiede una certa quantità di tempo e che spesso fa nascere tutta una serie di problemi al momento della ripetizione del test. Le specifiche, l’interfaccia, il numero dei campi ed altri aspetti possono infatti cambiare da versione a versione (e di fatto succede molto spesso). Gli errori ottenuti con questo metodo, poi, sono spesso assai prevedibili e riproducibili in tempi rapidi da un test manuale. Bisogna quindi valutare attentamente la fattibilità e la convenienza prima di eseguire un test automatizzato, che si rivela efficace solo per degli utilizzi mirati e specifici.

Precedente Testing software: Il test esplorativo di un nuovo software Successivo Testing software: Il Penetration Test di un sistema software

Lascia un commento

*