La verifica e la convalida fanno parte del processo di test?

Penso che tu abbia capito esattamente.

1. La verifica e la convalida sono cose diverse e sono in effetti piuttosto ben definite. Anche se il documento non mi piace molto, la ISO 9000ff è molto importante per il controllo qualità e definisce la verifica come confrontare un prodotto con i suoi requisiti e la convalida come verifica se risponde effettivamente alle esigenze del cliente / utente e sappiamo tutti che può essere diverso .

2. Entrambi possono essere eseguiti tramite test. La verifica porterebbe a test generati dai requisiti di forma. La convalida porta a test eseguiti da test senza riferimento diretto ai requisiti. Penso che questo sia spesso chiamato test esplorativo. Ovviamente deve essere fatto da persone con una reale comprensione delle reali esigenze degli utenti, quindi i test alpha e beta degli utenti reali sono opzioni ovvie.

3. Su base teorica immagino che si possa obiettare che qualsiasi cosa coperta dai primi due non è un bug e quindi trovare un bug come obiettivo separato non ha senso. Ma penso che ci siano cose che non puoi realmente verificare o validare. Ad esempio sicurezza: come convalidare o verificare che un sistema software sia sicuro contro gli attacchi? Invece si tenta di trovare vulnerabilità. Questa ricerca non verifica o convalida nulla se non riesce a trovare problemi, ma trova bug se riesce.

Da Wikipedia: "... In altre parole, la convalida garantisce che il prodotto soddisfi effettivamente le esigenze degli utenti e che le specifiche fossero corrette in primo luogo , mentre la verifica sta verificando che il prodotto sia stato costruito in base ai requisiti e alle specifiche di progettazione.La convalida assicura che "hai costruito la cosa giusta" La verifica assicura che "hai costruito bene". La convalida conferma che il prodotto, come previsto, soddisferà la sua destinazione d'uso. "

Non è possibile testare le esigenze dell'utente e verificare se le specifiche fossero corrette in base al codice. Quindi la convalida non viene eseguita testando

La verifica presuppone che i tuoi requisiti e il design siano corretti, quindi puoi testarlo scrivendo codice (test).

Per il mondo reale, il test è la verifica e la convalida del software che soddisfa i requisiti del software (aziendale / funzionale / non funzionale). Lo scopo di questi è determinare se il software è adatto allo scopo. Qualsiasi comportamento che non soddisfa i requisiti dell'applicazione è un difetto - la cui gravità dovrà essere ponderata prima di determinare se il software è adatto allo scopo.

I difetti di bassa gravità non sono probabilmente ostacoli per passare il software a un tipo di produzione, l'alta severità potrebbe richiedere una correzione. Nel mondo reale tutto il software ha dei difetti, alcuni sono problemi di codifica e altri sono da requisiti mancanti - che potrebbero non essere testati perché non è possibile testare requisiti sconosciuti.

Esistono molte definizioni di verifica e convalida. Molte persone usano persino il tag V & V per raggruppare entrambi in una singola attività. Lo scopo è quello di assicurarsi che il software renda le cose giuste e renda le cose giuste. A prescindere dal fatto che sia necessario verificare la conformità ai requisiti o cercare di trovare i bug non è essenziale a questo livello.

Il test è una delle molte tecniche di verifica e convalida, non il contrario. La revisione del codice è un'altra e la verifica formale, con prove matematiche ancora un'altra.

Tuttavia, i test dovrebbero essere eseguiti con l'obiettivo di trovare bug, non con l'obiettivo di verificare la conformità con i requisiti.

La principale differenza è nella mente del tester. È molto più facile costruire un caso di test che dimostri che il software funziona come previsto (verifica della conformità), piuttosto che costruire un caso di test che mostri che il software non riesce (trovare i bug).

Un grande tester è appassionato di rompere il software, non di esercitarlo in modo sicuro.

Vediamo questo da un punto di vista pratico. Per i test, è necessario definire i casi di test. In genere, si definiscono i casi di test secondo i requisiti specificati e devono riguardare i casi "happy day" e quelli "edge case", in particolare i secondi vengono spesso definiti con l'intenzione di rompere il software. Quando alcuni dei test falliscono, mostrano bug / difetti. Quando hai un numero ragionevole di casi di test per ogni requisito e tutti i test superano, non puoi avere pienamente provato che tutti i requisiti siano soddisfatti, ma hai migliorato la probabilità per questo, così facendo alcuni verifica.

Quindi per quella parte della domanda, trovare bug e verifiche potrebbe essere solo due lati dello stesso processo:

I test

• falliscono: trovati difetti

• passaggi di test: verifica eseguita (almeno, in una certa misura, se fornisci test sufficienti e sufficienti)

Per quanto riguarda la convalida: come sottolineato da @Mert, la convalida può essere eseguita mediante test di accettazione, ma non da altre forme di test. Pertanto, i test in generale non causano alcuna convalida, solo se eseguiti come test di accettazione da parte di alcuni potenziali utenti.

Dipende tutto dalla tua definizione di "verifica". Ad esempio, la verifica formale di solito non è una cosa fatta da un team di QA, ma è invece una responsabilità degli sviluppatori. Quasi nessuno fa una verifica formale a causa dell'elevato costo ad esso associato (divario di conoscenze e risorse necessarie).

Il test del software non è lo stesso del QA. Hai ragione. I test del software in generale comprendono molte fasi (fumo, unità, regressione, integrazione, accettazione degli utenti, ecc.) di per sé.

Pertanto, assicurare che il software funzioni in base ai requisiti è l'obiettivo principale del QA (specialista dell'assicurazione della qualità - noto anche come semplice tester anni fa). Tuttavia, non è solo un test . Il QA garantisce che sia in atto una serie adeguata di procedure per l'esecuzione del controllo di qualità del prodotto in questione, o almeno in fase di progettazione del progetto.

Quindi, idealmente ti aspetteresti che il tuo QA verifichi l'applicazione rispetto all'insieme di requisiti e non provi semplicemente a testarlo interrompendo il software e individuando i difetti.