Sono uno studente che lavora al mio B.E (CS) e la mia domanda è la seguente:
La mia domanda: Il test del software è necessario ?
Sì. Perché non importa quanto sei bravo, non puoi pensare a tutto.
Per lo stesso motivo per cui uno chef assaggia il suo cibo mentre lo cucina.
Lavoro con qualcuno che pensa in questo modo, pensa che poiché è un programmatore esperto non ha più bisogno di testare il suo codice. La compagnia non capisce quanto sia pericoloso questo atteggiamento e invece di licenziarlo a priori ha assunto più programmatori per affrontare il bug backlog. Non sapendo da dove viene questo arretrato, pensano che sia parte di ciò che riguarda la programmazione. Fondamentalmente abbiamo 3 programmatori che lavorano in questa modalità e un team di 20 che non fa altro che testare e correggere i bug che questi tre creano.
ASSENZA OF PROPER TEST KILLS .
Quindi, a meno che tu non sia DIO o qualsiasi altra versione di un essere perfettamente sapiente (ora questo mi piacerebbe vederlo) oa meno che tu non voglia attivamente essere licenziato molto velocemente, ti consiglio vivamente di iniziare a testare.
Il software è scritto da persone.
Le persone sono imperfette e sbagliano.
Con l'aumento della complessità di un'impresa, il numero potenziale (e l'impatto) di errori, sviste o cose dimenticate aumenta - in genere in modo esponenziale.
Quindi sì, è necessario un test. Porta equilibrio e prospettiva.
Salirai su un volo che esegue un sistema operativo che conosci che hai usato sul tuo laptop e ti ha regalato una schermata di morte con il tuo colore preferito? Pensaci.
Nessun coder è perfetto. Lontano, molto, molto lontano da ciò. Hai bisogno di test, e spesso i tester portano in prospettiva (noti anche come casi d'uso) che mancavano agli sviluppatori.
Fai una ricerca sui più famosi bug del software su Google per sapere cosa intendo.
E a livello di college, leggi alcuni sviluppi basati su test, unit test e pratiche agili per sapere dove sono le cose adesso.
Il test è un must assoluto per qualsiasi applicazione non banale (in termini di dimensioni o funzioni) che deve essere effettivamente utilizzata. Non troverai un singolo sviluppatore che si preoccupi della sua attività (come dimostra la visita di questo sito) che risponderà e affermerà che il test non è necessario.
Oltre a ciò che è già stato pubblicato, disporre di una suite completa di test di unità automatizzate su qualsiasi applicazione ti renderà più sicuro nelle future modifiche al codice. Questa maggiore sicurezza (dato che i test unitari forniscono una grande rete di sicurezza) comporterà modifiche più rapide del codice alle applicazioni esistenti (a causa di un minor backtracking / doppio controllo)
Errare humanum est
Non esiste un software privo di bug.
Lo sviluppatore più abile scrive codice con bug. Anche se esistesse uno sviluppatore perfetto, ci sarebbero comunque dei bug dovuti a discrepanze tra:
Lo sviluppatore perfetto è solo una parte dell'intera cosa. E gli sviluppatori perfetti non esistono.
La maggior parte dei programmi in tempo reale:
a) contengono centinaia di righe di codice o più, suddivise su numerosi file;
b) sono sviluppati da più di un programmatore;
c) utilizzato in ambienti diversi dall'ambiente dello sviluppatore
Quindi, se non verifichi come funziona il programma nella situazione reale, le probabilità che non funzioni affatto sarebbero vicine al 100%.
Oltre a tutte le altre grandi risposte, anche se sai che è perfetto e privo di bug, pensa agli altri programmatori che devono gestire il tuo codice in futuro. Non lo sapranno come te e vorranno fare affidamento sui tuoi test per assicurarti che non abbiano rotto nulla dopo aver apportato una modifica. Questo ovviamente vale anche per te stesso dopo che non hai visto il tuo codice tra un anno!
Sì.
Ecco un'altra prospettiva leggermente più sottile che non è stata ancora completamente trattata:
Non sottovalutare mai la necessità di "verifica indipendente" . È lo stesso motivo per cui è bello avere pochi editori indipendenti che si occupano del tuo lavoro prima di inviare un grosso scritto per la pubblicazione. A prescindere da quanto sei bravo come scrittore, a volte ti capita di chattare e scrivere qualcosa come "in" al posto di "it", o qualcosa del genere. Se lo rileggi da solo, anche con molta attenzione, di solito mancherai ancora, perché il tuo cervello accetterà automaticamente il flusso del tuo pensiero come corretto e sorveglierà l'errore. Per un nuovo paio di occhi, questo tipo di errore di solito è abbastanza lampante.
Hai la stessa cosa nella programmazione: è abbastanza facile entrare in un flusso in cui il tuo codice, o il tuo "test di sviluppo" di base del tuo codice - sembra corretto perché lo stai testando e usandolo in un certo modo . Ma poi quando arriva un altro paio di mani e scatta le cose in un modo o in un ordine leggermente diverso, tutto si abbatte.
Ora, naturalmente, potresti in teoria fare il percorso di verifica formale di ogni singola possibilità e ramo logico nel tuo codice, ma per un software non banale questo sarà molto più costoso e richiede molto tempo che avere qualcun altro abbia il codice giusto per te. E ti mancheranno comunque cose che non avresti mai pensato.
Ciò che non è stato ancora toccato: anche se il tuo codice è perfetto, non sei ancora sicuro. I compilatori hanno bug che possono causare il comportamento di codice persino perfetto dopo la compilazione. I sistemi operativi hanno bug che possono causare il corretto funzionamento di un binario perfetto durante l'esecuzione. L'hardware ha bug che possono causare problemi.
Questo è anche il motivo per cui i test su una macchina non sono sufficienti per i prodotti commerciali. Devono essere testati sotto il maggior numero possibile di combinazioni di hardware e software che possono incontrare in natura come è fattibile.
Il capo della squadra che ha scritto il software per lo space shuttle è volato via prima di ogni lancio per firmare che il software non avrebbe danneggiato lo shuttle.
Che cosa penseresti gli avrebbe dato la sicurezza per farlo?
Stai costantemente testando il codice semplicemente compilandolo e usandolo. In alcuni IDE ricevi controlli di integrità mentre digiti. A meno che tu non esegua mai effettivamente il tuo codice, stai facendo dei test.
Quanto riesci a testare è davvero la radice di questo tipo di domande e la risposta a questo si riduce al rischio. Testate quanto ha senso testare da un punto di vista della gestione del rischio. Testare tutto o niente è solitamente impossibile. Testare quasi nulla è di solito una brutta mossa. Tutto nel fratempo è un gioco equo a seconda del livello di rischio e dell'esposizione del tuo deliverable.
Sente l'odore di una domanda a casa.
Is testing in the software field needed?
Sì. Assolutamente. A tutti i livelli. Al di fuori di alcuni domini specializzati, non siamo ancora in una fase in cui possiamo dimostrare matematicamente che il nostro codice è corretto rispetto a bug specifici (almeno non in un ragionevole lasso di tempo), quindi dobbiamo rocce su di esso per vedere se e dove si rompe.
If we create a software with great care, then why should we test?
I test non riguardano solo la ricerca di errori di codifica. Si tratta anche di assicurarsi di aver soddisfatto tutti i requisiti e che il sistema complessivo funzioni come previsto. Se ho il requisito che una transazione fallita debba restituire un codice di errore specifico, allora ho bisogno di scrivere un test per verificare che la funzionalità esista e che funzioni correttamente.
E tutto ciò presuppone che le specifiche e il design siano completi, corretti e coerenti internamente, cosa che spesso non accade. Anche se si soddisfano le specifiche per la lettera e si segue il disegno fino all'ultimo punto e punto e virgola, se la specifica o il design è negativo, allora ci saranno problemi al momento dell'integrazione. Spesso, i test di sistema o di integrazione si verificano quando si scopre che le specifiche stesse sono buggate e devono essere riviste (vedi la storia di guerra di seguito).
After testing can we be sure that we have achieved this goal (the product/software works as intended) because we have done the testing for it? Is it possible?
No, non al 100%. Non possiamo testare ogni combinazione immaginabile di input o percorsi di esecuzione in nessun codice tranne il più semplice. Non possiamo tenere conto di tutti i fattori ambientali. Non possiamo immaginare tutte le possibili modalità di errore.
Possiamo testare fino a un punto in cui siamo ragionevolmente sicuri che non ci siano grossi problemi. Di nuovo, questo è il motivo per cui dobbiamo testare a tutti i livelli. Scrivi una serie di test per assicurarti che il tuo codice gestisca correttamente le condizioni del bordo (input errati, risultati imprevisti, eccezioni, ecc.). Test unitario per verificare che il tuo codice soddisfi i suoi requisiti. Test di sistema per verificare l'elaborazione end-to-end. Test di integrazione per verificare che tutti i componenti si parlino correttamente. Fai test di usabilità per assicurarti che tutto funzioni in modo tale che i clienti non vogliano spararti.
Scenario del mondo reale - Stavo lavorando a un sistema di back-end che occasionalmente inviava aggiornamenti a un servizio della GUI per la visualizzazione in una tabella sullo schermo. Durante il progetto, è stato aggiunto un requisito per aggiungere il filtro al display (ad esempio, l'operatore potrebbe scegliere di visualizzare un sottoinsieme delle voci nella tabella). Errore di progettazione n. 1 - il filtro dovrebbe essere stato eseguito dal servizio GUI (ho questa caratteristica antiquaria che le funzioni di gestione del display dovrebbero essere responsabilità del software di gestione display), ma a causa della politica e della mia incapacità di riconoscere i problemi prima che diventino problemi , tale requisito è stato inserito nel servizio back-end. Bene, ok, nessun problema, posso farlo. Modifica lo stato dei filtri, ricevo un messaggio e poi invio un messaggio di creazione o eliminazione per ogni riga nella tabella , perché è così che funziona l'interfaccia (errore di progettazione n. 2 - non c'è modo di inviare aggiornamenti su più righe in un singolo messaggio, non potremmo nemmeno inviare un singolo messaggio "cancella" o "cancella" per cancellare l'intera tabella).
Bene, tutto funziona bene durante lo sviluppo; i test di unità, sistema e integrazione mostrano che invio le informazioni corrette e gestisco correttamente le modifiche del filtro. Poi arriviamo ai test di usabilità, e tutto si riduce difficile , perché il volume dei dati era schiacciante. La latenza di rete tra il mio servizio di back-end e la GUI era dell'ordine di 15-15 secondi. Non male se devi solo inviare aggiornamenti per una decina di righe o giù di lì. Deadly quando devi inviare aggiornamenti per diverse centinaia. Abbiamo iniziato a ricevere segnalazioni di bug che la GUI si stava bloccando dopo aver cambiato lo stato del filtro; beh, no, quello che stava succedendo era che stava assumendo l'ordine di diversi minuti per aggiornare il display perché il protocollo del messaggio di aggiornamento con una sola fila alla volta non poteva gestire uno scenario reale.
Si noti che tutto ciò che avrebbe potuto e dovrebbe essere stato anticipato da tutti, dall'imprenditore principale fino a poco meno di me, se ci fossimo presi la briga di fare anche l'analisi più elementare in anticipo. L'unica difesa che offrirò è che stavamo chiudendo il secondo anno di un progetto di sei mesi che sarebbe stato cancellato quasi immediatamente dopo il parto, e noi eravamo tutti disperati a vedere il retro di esso.
Il che ci porta all'ultima ragione per testare - CYA. I progetti del mondo reale falliscono per una serie di motivi, molti dei quali politici, e non tutti agiscono in buona fede quando le cose vanno male. Le dita vengono puntate, le accuse vengono fatte e alla fine della giornata devi essere in grado di puntare a un record che mostri che almeno i tuoi elementi hanno funzionato come previsto.
I test verranno sempre eseguiti e i bug verranno sempre trovati. È solo che il test verrà eseguito internamente dal team o l'utente finale sarà il tester. Il costo di un bug riscontrato dall'utente finale è tremendamente superiore a quello che sarebbe stato riscontrato durante i test.
Suggerirei di prendere un buon corso di Fault-Tolerant Computing. L'attenta progettazione del software è solo uno dei pilastri per raggiungere la robustezza del tuo software. Gli altri due pilastri sono test sufficienti e design ridondante. L'intento di base è quello di ospitare un numero esponenziale di condizioni di errore sconosciute e di dare la priorità ad alcune di quelle conosciute:
1.) eliminare il maggior numero possibile di guasti attraverso la progettazione e la corretta implementazione 2.) eliminare fallimenti imprevedibili dalla fase di progettazione e implementazione scorretta attraverso varie forme di test (unità, integrazione, random) 3.) gestisci eventuali errori rimanenti tramite ridondanza (temporale = > ricalcola, riprova o spacial = > mantieni copie, parità)
Se elimini la fase di test, ti lasci solo con le fasi di progettazione e ridondanza per affrontare i problemi.
Inoltre, dal punto di vista del prodotto, i tuoi stakeholder (ad es. management, utenti, investitori) vorranno una sorta di rassicurazione sul fatto che il tuo prodotto soddisfi determinate specifiche e criteri di qualità e sicurezza, ecc. A parte questo, non hai provato il software che hai costruito solo per avere un 'controllo di sanità'? Tutti questi motivi rendono i test del software più interessanti.
Tutti i programmi hanno bug, almeno per cominciare.
Ci sono stati alcuni studi che convergono su circa 1 bug per ogni cinque righe di codice non testato.
Una lezione di storia:
Negli anni '60 IBM aveva bisogno di un programma "NOP" in modo da poter eseguire alcune funzionalità in JCL senza eseguire effettivamente un programma. Gli sviluppatori hanno creato un programma di assemblaggio di una riga in cui l'intero codice era contenuto nel suo nome "IEFBR14" essendo il codice reale:
BR 14 * brach to return address in register 14
Durante il suo lungo periodo di tempo questo programma a una riga è stato soggetto a 2 segnalazioni di bug e cinque emendamenti.
Il refactoring del codice è molto più veloce quando si eseguono i test unitari. Un test unitario mostra anche un semplice uso della funzione concreta, quindi hai un piccolo "howto" che può essere davvero utile in grandi progetti in cui i programmatori non conoscono esattamente l'intero codice.
Quando sviluppi con TDD (sviluppo basato su test) non hai getter / setter non necessari ecc. Crea solo ciò di cui hai bisogno.
Per rispondere # 3 della tua domanda:
Essendo stato un programmatore e un tester software, sì, puoi essere certo di soddisfare i requisiti del software durante i test.
{mettere il cappello QA su}
Come? È possibile farlo tracciando i test dal codice di prova ai criteri di accettazione, dai criteri di accettazione alle funzionalità e dalle caratteristiche ai requisiti. Se si traccia ogni singolo test fino alla catena di progettazione e si mappano a uno o più requisiti, si può essere certi che i test vengano utilizzati per garantire che il codice soddisfi i requisiti (sebbene ciò faccia apparire l'idea di una copertura di prova adeguata, che è un un altro argomento). Se non riesci a rintracciare un test nella catena di progettazione, probabilmente stai testando per cose che non sono richieste, e questa è una perdita di tempo. I criteri di accettazione possono includere anche il controllo di comportamenti indesiderati: puoi testare anche quelli, il che ti avvicina di un passo a una versione di qualità.
{QA hat off}
Nessun codice è mai privo di bug, ma meno costoso nel tempo quando si impiegano maggiori sforzi per valutarne la qualità durante lo sviluppo.
Sono stato un tester del software per 3 anni. Inizialmente, io stesso ero scettico sulla necessità di testare, dal momento che pensavo che se il dipartimento di sviluppo e la direzione del progetto svolgevano il loro lavoro, non dovevano presentarsi errori nel software.
MA questo non è il caso. ++++++++
Gli errori capitano spesso, alcuni dei quali sono fondamentali per il funzionamento di un progetto. Esiste anche un test cross-browser (che significa test su diversi browser esistenti come SAFARI, FIREFOX, CHROME e Internet Explorer) e ho lavorato al progetto dove semplici pulsanti dell'interfaccia come YES e NO su una finestra di sondaggio in cui non funziona solo in tutti i browser alcuni di loro.
Ho lavorato ai test delle pagine Internet e stavo testando semplici CAMBIAMENTI DI TESTO e ho pensato a me stesso che in nessun modo sulla terra ci potrebbero essere difetti in questo semplice lavoro, ma non succede.
Ho anche visto quando nuovi sviluppatori si uniscono al team e ricevono un pezzo di lavoro aggiornato su un complesso modulo di domanda Internet esistente con una serie di collegamenti / chiamate a pagine esterne, errore dovuto alla mancanza di comunicazione tra vecchio e nuovi sviluppatori, per vari motivi (non c'è tempo per educare, nessuna voglia di educare e così via).
YES
Immagina che il tuo software sia solo una funzione logica AND (b1, b2) in cui b1 e b2 sono solo bit. Con questo hai bisogno di 4 test case per essere sicuro che il tuo software sia privo di errori, se l'ambiente circostante offre esattamente ciò per cui sono stati specificati.
Ora il tuo sistema è costituito da molte funzioni la cui più semplice è molto più complicata di quella logica. Come faresti a garantire che sia privo di errori?
(continua)
Leggi altre domande sui tag testing validation quality qa verification