Il Testing in Informatica rappresenta il processo con il quale si esegue e si valuta, automaticamente o manualmente, un programma, un prodotto o un sistema per verificare se soddisfa i requisiti specificati e per identificare le differenze tra i risultati attesi e quelli ottenuti.
In questa fase, in un’ideale staffetta di progetto, in caso di collaudo positivo, si ha il passaggio di ownership dell’output dal gruppo di sviluppo agli utenti finali.
Di seguito si fornisce un pratico decalogo da applicare durante lo svolgimento delle attività di Test:
- Il gruppo di implementazione non dovrebbe mai testare le proprie applicazioni.
Il responsabile del Progetto (Project Manager) ed il gruppo di sviluppo non dovrebbero essere direttamente responsabili del test perché il loro approccio psicologico è quello di garantire il rispetto dei tempi e dei costi del progetto, anche a discapito della correttezza e dell’affidabilità delle applicazioni sviluppate (cioè a discapito dei test).
- Più in particolare, un programmatore dovrebbe evitare di effettuare il test delle applicazioni che ha sviluppato.
Un programmatore non accetta di mettere in evidenza i propri errori di programmazione, perché la sua attitudine mentale è di tipo costruttivo (sviluppo) e non distruttivo (processo di test).
- Per ogni caso di test è necessario specificare il risultato atteso.
Rispetto al componente testato, è necessario indicare precisamente i dati di input e i relativi dati di output. Questo principio – che può a prima vista sembrare ovvio – è di primaria importanza in quanto, se il risultato di un test non è predefinito, anche un risultato errato potrebbe essere interpretato come corretto.
- I casi di test dovrebbero essere eseguiti anche per condizioni di input non valide ed inattese, oltre che per quelle valide e previste.
L’approccio di molti tecnici del test è quello di ignorare le condizioni di input dei test non valide e inattese.
- E’ necessario ispezionare minuziosamente i risultati di ogni test eseguito.
E’ bene verificare con cura il risultato del test eseguito e registrare, analizzare e correggere ogni malfunzionamento.
- Deve essere condotta l’analisi di un componente per identificare anche gli effetti non desiderati.
Un software deve produrre un output sempre coerente con i valori di input immessi.
- I casi di test rappresentano un investimento che deve essere preservato e riutilizzato in caso di riesecuzione dei test.
L’attività di test di regressione di un programma deve essere rigorosa quanto il test originario; per questo motivo è bene conservare i casi di test realizzati; ancora meglio se registrati in forma elettronica e rieseguiti in forma automatica.
- La pianificazione dell’impegno per il test dovrà tenere conto anche degli errori rilevati durante il test.
Il responsabile del progetto deve sempre assumere che il test abbia come obiettivo quello di dimostrare la correttezza dei programmi sviluppati; quindi occorre prevedere l’impegno necessario per la rimozione degli errori trovati.
- In un software la probabilità di trovare errori è proporzionale agli errori già trovati.
Nelle prime fasi di test il numero degli errori trovati tende a crescere per poi diminuire sempre più man mano che il “residuo” di errori diminuisce. Il valore limite (asintoto) verso cui tende la curva di rimozione degli errori è determinato statisticamente in base all’esperienza su progetti simili.
- L’attività di test è estremamente creativa.
Lo sviluppo del software è un’attività tecnica e intellettuale ad alto contenuto umano. La creatività e la tecnica sono costantemente integrate per trovare soluzioni efficaci e innovative. L’integrazione è spesso molto spinta. La creatività è perciò molto richiesta anche nella progettazione dei casi di test per assicurare che il test sia validato in tutte le sue componenti, caratteristiche e peculiarità, modalità e condizioni di utilizzo.
Riassumendo, possiamo concludere che una sessione di test risulta efficace quando rispetta tre fondamentali principi:
- E’ un processo di esecuzione di un protocollo con l’obiettivo di far emergere eventuali difformità rispetto al risultato atteso;
- E’ progettata per avere la più alta probabilità di scoprire gli errori esistenti, anche quelli che risultano nascosti finché il software non è eseguito;
- Ha successo quando rileva almeno gli errori che ci si aspetta di trovare.
Lo staff di PME
Il Testing in Informatica rappresenta il processo con il quale si esegue e si valuta, automaticamente o manualmente, un programma, un prodotto o un sistema per verificare se soddisfa i requisiti specificati e per identificare le differenze tra i risultati attesi e quelli ottenuti.
In questa fase, in un’ideale staffetta di progetto, in caso di collaudo positivo, si ha il passaggio di ownership dell’output dal gruppo di sviluppo agli utenti finali.
Di seguito si fornisce un pratico decalogo da applicare durante lo svolgimento delle attività di Test:
- Il gruppo di implementazione non dovrebbe mai testare le proprie applicazioni.
Il responsabile del Progetto (Project Manager) ed il gruppo di sviluppo non dovrebbero essere direttamente responsabili del test perché il loro approccio psicologico è quello di garantire il rispetto dei tempi e dei costi del progetto, anche a discapito della correttezza e dell’affidabilità delle applicazioni sviluppate (cioè a discapito dei test).
- Più in particolare, un programmatore dovrebbe evitare di effettuare il test delle applicazioni che ha sviluppato.
Un programmatore non accetta di mettere in evidenza i propri errori di programmazione, perché la sua attitudine mentale è di tipo costruttivo (sviluppo) e non distruttivo (processo di test).
- Per ogni caso di test è necessario specificare il risultato atteso.
Rispetto al componente testato, è necessario indicare precisamente i dati di input e i relativi dati di output. Questo principio – che può a prima vista sembrare ovvio – è di primaria importanza in quanto, se il risultato di un test non è predefinito, anche un risultato errato potrebbe essere interpretato come corretto.
- I casi di test dovrebbero essere eseguiti anche per condizioni di input non valide ed inattese, oltre che per quelle valide e previste.
L’approccio di molti tecnici del test è quello di ignorare le condizioni di input dei test non valide e inattese.
- E’ necessario ispezionare minuziosamente i risultati di ogni test eseguito.
E’ bene verificare con cura il risultato del test eseguito e registrare, analizzare e correggere ogni malfunzionamento.
- Deve essere condotta l’analisi di un componente per identificare anche gli effetti non desiderati.
Un software deve produrre un output sempre coerente con i valori di input immessi.
- I casi di test rappresentano un investimento che deve essere preservato e riutilizzato in caso di riesecuzione dei test.
L’attività di test di regressione di un programma deve essere rigorosa quanto il test originario; per questo motivo è bene conservare i casi di test realizzati; ancora meglio se registrati in forma elettronica e rieseguiti in forma automatica.
- La pianificazione dell’impegno per il test dovrà tenere conto anche degli errori rilevati durante il test.
Il responsabile del progetto deve sempre assumere che il test abbia come obiettivo quello di dimostrare la correttezza dei programmi sviluppati; quindi occorre prevedere l’impegno necessario per la rimozione degli errori trovati.
- In un software la probabilità di trovare errori è proporzionale agli errori già trovati.
Nelle prime fasi di test il numero degli errori trovati tende a crescere per poi diminuire sempre più man mano che il “residuo” di errori diminuisce. Il valore limite (asintoto) verso cui tende la curva di rimozione degli errori è determinato statisticamente in base all’esperienza su progetti simili.
- L’attività di test è estremamente creativa.
Lo sviluppo del software è un’attività tecnica e intellettuale ad alto contenuto umano. La creatività e la tecnica sono costantemente integrate per trovare soluzioni efficaci e innovative. L’integrazione è spesso molto spinta. La creatività è perciò molto richiesta anche nella progettazione dei casi di test per assicurare che il test sia validato in tutte le sue componenti, caratteristiche e peculiarità, modalità e condizioni di utilizzo.
Riassumendo, possiamo concludere che una sessione di test risulta efficace quando rispetta tre fondamentali principi:
- E’ un processo di esecuzione di un protocollo con l’obiettivo di far emergere eventuali difformità rispetto al risultato atteso;
- E’ progettata per avere la più alta probabilità di scoprire gli errori esistenti, anche quelli che risultano nascosti finché il software non è eseguito;
- Ha successo quando rileva almeno gli errori che ci si aspetta di trovare.
Lo staff di PME
