Test del software - Miti

Di seguito sono riportati alcuni dei miti più comuni sui test del software.

Mito 1: i test sono troppo costosi

Reality- C'è un detto: pagare di meno per i test durante lo sviluppo del software o pagare di più per la manutenzione o la correzione in seguito. I primi test consentono di risparmiare tempo e costi in molti aspetti, tuttavia la riduzione dei costi senza test può comportare una progettazione errata di un'applicazione software che rende il prodotto inutilizzabile.

Mito 2: i test richiedono tempo

Reality- Durante le fasi SDLC, il test non è mai un processo che richiede tempo. Tuttavia, la diagnosi e la correzione degli errori identificati durante i test adeguati è un'attività che richiede tempo ma produttiva.

Mito 3: vengono testati solo prodotti completamente sviluppati

Reality- Senza dubbio, il test dipende dal codice sorgente, ma la revisione dei requisiti e lo sviluppo di casi di test è indipendente dal codice sviluppato. Tuttavia, l'approccio iterativo o incrementale come modello del ciclo di vita di sviluppo può ridurre la dipendenza dei test dal software completamente sviluppato.

Mito 4: è possibile eseguire un test completo

Reality- Diventa un problema quando un cliente o un tester pensa che sia possibile un test completo. È possibile che tutti i percorsi siano stati testati dal team, ma non è mai possibile eseguire un test completo. Potrebbero esserci alcuni scenari che non vengono mai eseguiti dal team di test o dal client durante il ciclo di vita dello sviluppo del software e possono essere eseguiti una volta che il progetto è stato distribuito.

Mito 5: un software testato è privo di bug

Reality - Questo è un mito molto comune in cui credono i clienti, i project manager e il team di gestione. Nessuno può affermare con assoluta certezza che un'applicazione software sia priva di bug al 100% anche se un tester con eccellenti capacità di test ha testato l'applicazione .

Mito 6: i difetti mancati sono dovuti ai tester

Reality- Non è un approccio corretto incolpare i tester per i bug che rimangono nell'applicazione anche dopo che il test è stato eseguito. Questo mito si riferisce a tempo, costo e requisiti che cambiano i vincoli. Tuttavia, la strategia di test può anche far sì che i bug vengano ignorati dal team di test.

Mito 7: i tester sono responsabili della qualità del prodotto

Reality- È un'errata interpretazione molto comune che solo i tester o il team di test dovrebbero essere responsabili della qualità del prodotto. Le responsabilità dei tester includono l'identificazione dei bug per gli stakeholder e poi spetta a loro decidere se correggere il bug o rilasciare il software. Il rilascio del software in quel momento mette più pressione sui tester, poiché saranno accusati di qualsiasi errore.

Mito 8: l'automazione del test dovrebbe essere utilizzata ove possibile per ridurre i tempi

Reality- Sì, è vero che Test Automation riduce i tempi di test, ma non è possibile avviare l'automazione di test in qualsiasi momento durante lo sviluppo del software. L'automa di prova dovrebbe essere avviato quando il software è stato testato manualmente ed è stabile in una certa misura. Inoltre, l'automazione dei test non può mai essere utilizzata se i requisiti continuano a cambiare.

Mito 9: chiunque può testare un'applicazione software

Reality- Le persone al di fuori del settore IT pensano e addirittura credono che chiunque possa testare un software e il test non è un lavoro creativo. Tuttavia i tester sanno molto bene che questo è un mito. Pensando a scenari alternativi, provare a mandare in crash un software con l'intento di esplorare potenziali bug non è possibile per la persona che lo ha sviluppato.

Mito 10: l'unico compito di un tester è trovare i bug

Reality- Trovare bug in un software è compito dei tester, ma allo stesso tempo sono esperti di dominio del software particolare. Gli sviluppatori sono responsabili solo del componente specifico o dell'area assegnata loro, ma i tester comprendono il funzionamento complessivo del software, quali sono le dipendenze e gli impatti di un modulo su un altro modulo.