Collaudo del software: differenze tra le versioni

Versione delle 08:49, 5 ago 2021

Versione delle 12:41, 6 ago 2021

Riga 39:

=== Sviluppo a cascata ===

Il procedimento tradizionale di [[Sviluppo software|sviluppo del software]], detto "[[Modello a cascata|a cascata]]" (in inglese "waterfall"), prescrive di iniziare il collaudo appena è completata la prima versione del prodotto. I risultati del collaudo vengono utilizzati per rivedere i requisiti, o il progetto, o il codice, e produrre così la versione successiva.

Questo procedimento è stato sottoposto a una severa critica in quanto ha i seguenti svantaggi:

Riga 45:

* Probabilmente, tra i requisiti non è stata inclusa la "collaudabilità" (in inglese, "testability"), cioè il progetto e il codice non contengono accorgimenti che agevolino il collaudo. In tal caso, il collaudo risulterà molto più costoso e meno efficace.

* Più tempo passa tra l'introduzione di un errore in un sistema e la segnalazione di un malfunzionamento dovuto a tale errore, più risulta difficile e costoso rimediarvi.

*Dato che il software in tale modello è previsto che venga sottoposto a test solo dopo aver completato la fase di sviluppo, l'eventuale feedback raccolto in fase di prova non può essere usato per alimentare tempestivamente l'apprendimento del team di sviluppo in modo tale che la qualità del codice possa essere migliorata come nei metodi iterativi ed incrementali (come può avvenire ad es. nei metodi "[[Metodologia agile|agili]]"). Pertanto nel modello di sviluppo in cascata le "lezioni apprese" possono essere utilizzate solo in eventuali successivi progetti di sviluppo, il che spesso ne limita l'effettivo valore aggiunto, in quanto la distanza nel tempo dalla fase di raccolta non agevola la applicazione.

=== Sviluppo guidato dal collaudo ===

{{Vedi anche|Test Driven Development}}

Un procedimento più recente, detto "guidato dal collaudo" (in inglese, "[[test driven development]]"), proposto a partire dall'inizio degli anni 1990, consiste nel considerare il collaudo una parte integrante del prodotto:

* Quando si analizzano i requisiti del software da produrre, si analizzano i requisiti del collaudo.

* Quando si progetta l'architettura del software da produrre, si progetta l'architettura del collaudo.

Riga 57 ⟶ 58:

== Fasi di distribuzione ==

=== Il collaudo di tipo Alpha ===

{{Vedi anche|Versione alpha}}

Appena un software è stato costruito, prima di distribuirlo fuori dall'azienda, viene normalmente sottoposto a un collaudo interno all'azienda stessa.

Il collaudo di tipo Alpha può essere eseguito dagli stessi programmatori o da altro personale dell'azienda.

Spesso, il software prodotto per il collaudo Alpha viene arricchito di istruzioni di controllo a [[run-time]] che facilitano il rilevamento degli errori. Esempi di tali istruzioni sono:

* il controllo che non si acceda a indici non validi di array;

* il controllo che tutta la [[Allocazione dinamica della memoria|memoria allocata]] venga disallocata prima della terminazione;

* asserzioni dichiarative scritte dal programmatore.

In alcuni casi, in particolare per lo sviluppo di [[Sistema operativo|software di sistema]] o di [[software embedded]], si utilizza un ambiente hardware di esecuzione che supporta specificamente il debugging e il testing.

=== Il collaudo di tipo Beta ===

{{Vedi anche|Versione beta}}

Spesso, quando un prodotto ha superato il collaudo di tipo Alpha, viene distribuito all'esterno dell'azienda ad alcuni clienti selezionati o anche a tutti i clienti, avvertendo gli utenti che il prodotto distribuito potrebbe non essere di qualità elevata e probabilmente richiedepotrebbe richiedere ulteriori correzioni.

Gli utenti della versione Beta possono simulare l'utilizzo del software in casi realistici, e inviare al produttore resoconti dei malfunzionamenti riscontrati. Tale tipo di collaudo eseguito gratuitamente dagli utenti viene detto "collaudo Beta" (in inglese "Beta testing").

Riga 87 ⟶ 88:

== Granularità ==

=== Il collaudo di modulo (Unit Testing) ===

{{Vedi anche|Unit testing}}

Quando si costruisce un prodotto complesso come un'automobile, non ci si limita a costruire e ad assemblare i pezzi e alla fine girare la chiave per vedere se tutto funziona. Questo per tre motivi:

* Alcuni difetti producono malfunzionamenti solo dopo un utilizzo prolungato, ma sono facilmente identificabili esaminando i singoli pezzi prima dell'assemblaggio.

* Se dopo aver girato la chiave la macchina non si accende, risulta molto difficile capire qual è il difetto.

* Se dopo aver girato la chiave la macchina non si accende, risulta molto costoso smontare la macchina, sostituire il pezzo difettoso e rimontarla.

*In alcuni casi potrebbero derivare dei rischi di arrecare danni a persone o cose dal funzionamento difettoso di un componente critico.

Ragionamenti analoghi valgono per il software. Pertanto, come i singoli pezzi di un macchina vengono sottoposti al controllo di qualità prima dell'assemblaggio, così è opportuno collaudare separatamente le singole componenti di un sistema software.