Quali sono i principi e fondamenti del testing software

Quali sono i principi e fondamenti del testing software

I principi basilari dell’attività di test possono essere così riassunti:

  1. Un’organizzazione di test non dovrebbe testare le proprie applicazioni. Il responsabile del progetto (Project Manager) ed il gruppo di sviluppo non dovrebbero essere direttamente responsabili del test poiché il loro approccio psicologico è quello di garantire il rispetto dei tempi e dei costi del progetto, anche a discapito dell’affidabilità e della correttezza delle applicazioni sviluppate (cioè a discapito dei test).
  2. Un programmatore dovrebbe evitare di effettuare il test delle applicazioni che ha sviluppato. Il programmatore non accetta di esporre i propri errori di programmazione poiché la sua attitudine mentale è di tipo costruttivo (sviluppo) e non distruttivo (processo di test). Il termine “processo costruttivo” è utilizzato per indicare le attività di sviluppo del software (il processo, cioè, con il quale si “costruisce” il software); il termine “processo distruttivo” per l’attività di testing è utilizzato anch’esso in senso positivo per indicare che il processo tende a trovare il maggior numero possibile di errori nel software.
  3. Per ogni caso di test (test case) è necessario specificare il risultato atteso. Rispetto al componente testato, è necessario indicare precisamente i dati di input ed i relativi dati di output. Questo principio che può sembrare ovvio a prima vista è di primaria importanza poiché se il risultato di un caso di test non è predefinito, anche un risultato errato potrebbe essere interpretato come corretto.
  4. 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 psicologico di molti tecnici del test è quello di ignorare le condizioni di input dei test non valide ed inattese.
  5. Ispezionare minuziosamente i risultati di ogni test eseguito. E’ bene verificare con cura il risultato del test eseguito e registrare, analizzare e correggere ogni errore rilevato.
  6. L’analisi di un componente dovrebbe essere condotta per identificare anche gli effetti non desiderati. Un software dovrà produrre un output sempre coerente con i valori di input immessi.
  7. I casi di test rappresentano un investimento che dovrà essere preservato e riutilizzato in caso di riesecuzione dei test. L’attività di test di regressione di un programma dovrà essere rigorosa come il test originario; per questo motivo è bene conservare i casi di test realizzati; se registrati in forma elettronica e rieseguiti in maniera automatica, ancora meglio.
  8. La pianificazione dell’impegno per il test dovrà tenere conto anche degli errori rilevati nel corso del test.
    Il responsabile di 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.
  9. In un software, la probabilità di trovare errori è proporzionale al numero di errori già trovati. Nelle prime fasi di test il numero di 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.
  10. L’attività di test è estremamente creativa. Lo sviluppo del software è un’attività tecnica ed intellettuale ad alto contenuto umano. La creatività e la tecnica sono costantemente integrate per trovare soluzioni efficaci ed innovative. L’integrazione è spesso anche molto spinta. La creatività è perciò fortemente richiesta anche nella progettazione dei casi di test per assicurare che il software sia validato in tutte le sue componenti, caratteristiche e peculiarità, modalità e condizioni di utilizzo.

Quali sono i principi e fondamenti del testing software

Riassumendo, possiamo concludere che esistono tre principi importanti nel test:

  1. Il test è un processo di esecuzione (vera o simulata) di un programma con l’obiettivo di scoprire gli errori presenti.
  2. Un buon caso di test è progettato per avere la più alta probabilità di scoprire gli errori presenti, anche quelli che risultano particolarmente nascosti finché il software non è eseguito.
  3. Un caso di test ha successo quando rileva almeno gli errori che ci si aspetta di trovare.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *