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

9

Basandomi su molte fonti, non credo che la semplice definizione che scopo del test sia trovare il maggior numero di bug possibile - testiamo per assicurarci che funzioni o meno. Ad esempio followint sono obiettivi del modulo di prova ISTQB:

Determinare che (prodotti software) soddisfano i requisiti specifici (penso che la sua verifica)
Dimostrare che (prodotti software) sono adatti allo scopo (penso che sia una validazione)
Rileva difetti

Concordo sul fatto che il test è la verifica, la convalida e il rilevamento dei difetti. È corretto?

testing theory verification

— Giovanni V
fonte

1

La prima cosa che dicono i libri sui test è che "il test non è il processo per dimostrare che il software funziona correttamente. È il processo di ricerca dei difetti". E poi i libri portano numerose ragioni per definire test del genere. Quindi è piuttosto che la verifica è il processo per trovare dove il software non soddisfa i requisiti.

— superM

Secondo definiton, la verifica garantisce il rispetto dei requisiti. In realtà, i libri definiscono i test come un processo di misurazione della qualità del software. Quindi se stai controllando che il sistema funzioni (positivo) con l'intenzione di vedere se funziona, non sta testando perché non cerchi bug? :) Su Wikipedia: Le tecniche di test includono, ma non sono limitate a, il processo di esecuzione di un programma o di un'applicazione con l'intento di trovare bug del software

— John V,

Penso che il modo migliore per identificare i limiti della parola testing sia quello di provare un'ipotesi, in quel caso stai cercando di verificare che non ci siano errori o imprecisioni nell'ipotesi, questo non è lo stesso che verificarne l'utilità o convalidare la sua applicabilità, questo è semplicemente un caso di identificazione dell'intero ambito del comportamento, indipendentemente dallo scopo.

— Jimmy Hoffa,

Avere un bonus "bella domanda" :)

— Andrew

1

Penso che tu abbia capito bene.

Verifica e convalida sono cose diverse e sono in effetti abbastanza ben definiti. Sebbene il documento non mi piaccia molto, ISO 9000ff è molto rilevante per il controllo qualità e definisce la verifica come il confronto di un prodotto con i suoi requisiti e la convalida come controllo se si adatta effettivamente alle esigenze del cliente / utente e sappiamo tutti che questo può differire .
Entrambi possono essere eseguiti tramite test. La verifica porterebbe a requisiti di forma generati da test. La convalida porta al test eseguito dai 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 alfa e beta da parte di utenti reali sono opzioni ovvie.
Su una base teorica immagino che si possa sostenere che qualsiasi cosa coperta dai primi due non sia un errore e quindi trovare bug come obiettivo separato non ha senso. Ma penso che ci siano cose che non puoi davvero verificare o validare. Ad esempio sicurezza: come convalidare o verificare che un sistema software sia sicuro dagli attacchi? Invece si tenta di trovare le vulnerabilità. Questa ricerca non verifica o convalida nulla se non riesce a trovare i problemi, ma trova bug se riesce.

— Jens Schauder
fonte

Il problema è che molte fonti menzionano che la verifica è solo statica, mentre la validazione dinamica. È molto confuso. Quale sarebbe il test funzionale allora? Direi la sua verifica dinamica ...

— Giovanni V,

1

Quali fonti utilizzano questa definizione di verifica e convalida? D'altra parte non conosco alcuna definizione chiara e generalmente condivisa di tutto ciò che termina in -test. Quindi non so davvero cosa sia un test funzionale per te.

— Jens Schauder,

Ad esempio, ISO 12207 limita i test solo come processo di convalida.

— Giovanni V,

3

Da Wikipedia: "... In altre parole, la convalida garantisce che il prodotto soddisfi effettivamente le esigenze dell'utente e che le specifiche siano corrette in primo luogo , mentre la verifica garantisce che il prodotto sia stato costruito in base ai requisiti e alle specifiche di progettazione La convalida garantisce che "hai costruito la cosa giusta". La verifica assicura che "hai costruito la cosa giusta". La convalida conferma che il prodotto, come previsto, soddisferà l'uso previsto. "

Non è possibile verificare le esigenze dell'utente e verificare se le specifiche erano corrette per codice. Pertanto, la verifica non viene eseguita mediante test.

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

— Mert Akcakaya
fonte

Non sarei d'accordo - il test non è solo test del codice, c'è anche il test della documentazione ecc. A proposito, wikipedia dice anche: Il test del software può essere dichiarato come il processo di convalida e verifica che un programma software / applicazione / prodotto .. Convalidi il programma dal suo execioan e investagion se questo è ciò che l'utente voleva o meno.

— Giovanni V,

In realtà hai ragione. Il processo di test include anche l'accettazione dei test ma ho parlato di test di unità, integrazione e sistema. Se pensiamo al processo di test nel suo insieme, la verifica e la convalida vengono eseguite mediante test.

— Mert Akcakaya,

1

Per il mondo reale, i test sono la verifica e la convalida del software che soddisfa i requisiti del software (business / 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.

Difetti a bassa gravità probabilmente non impediscono il passaggio del software a un uso di tipo produttivo, potrebbe essere necessaria una correzione per produrre severità elevata. Nel mondo reale tutti i software presentano difetti, alcuni sono problemi di codifica e altri provengono da requisiti mancanti, che potrebbero non essere verificati perché non è possibile verificare requisiti sconosciuti.

— Adamo f
fonte

1

Esistono molte definizioni di verifica e convalida. Molte persone usano persino il tag V&V per raggruppare entrambi in un'unica attività. L'obiettivo è assicurarsi che il software faccia le cose giuste e le cose giuste. A questo livello non è essenziale verificare la conformità ai requisiti o cercare di individuare bug.

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

Tuttavia, i test dovrebbero essere eseguiti allo scopo di trovare bug, non allo scopo di verificare la conformità ai requisiti.

La differenza principale sta nella mente del tester. È molto più semplice creare un caso di prova che mostri che il software funziona come previsto (verifica della conformità), piuttosto che creare un caso di prova che mostri che il software ha esito negativo (ricerca di bug).

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

— mouviciel
fonte

grazie, ma non testiamo anche per dimostrare che i requisiti sono soddisfatti? Ci assicuriamo che il software funzioni (soddisfino le specifiche) e quindi proviamo a trovare i difetti. Quindi non si tratta solo di trovare bug. Ricordo un libro in cui si diceva che l'obiettivo principale dei test era misurare la qualità, non cercare bug. Per quanto riguarda il tuo primo punto, anche la revisione del codice, la prova matematica ecc. Sono test e si chiama statica.

— Giovanni V,

Difetti o bug esistono in contrasto con i requisiti. La natura del lavoro è identica. È solo una differenza nel modo di pensare al tester per migliorarne l'efficienza. Per quanto riguarda il mio primo punto, ci sono molte definizioni di tutti i termini utilizzati nella convalida del software (e un primo passo quando si unisce a un team è ottenere il dialetto locale in quel team), ma la maggior parte delle persone concorda sul fatto che il test è solo dinamico tecnica. il test statico è un ossimoro, o fa riferimento a una tecnica diversa, non lontano dalla revisione, in cui il codice viene eseguito nella mente del "tester" e non da un computer.

— mouviciel,

mouviciel: oxymoron? Non credo, test statici significa verificare possibili difetti senza esecuzione, il che è del tutto possibile (problemi di requisiti, difetti di progettazione ...). Non è lo stesso per verificare i requisiti e verificare la presenza di bug: è necessario verificare che un campo possa contenere il valore int32. Questo è il test che funziona. Quindi puoi provare a inserire valori più alti, ovvero test per bug ..

— Giovanni V,

1

Vediamolo da un punto di vista pratico. Per i test, è necessario definire casi di test. In genere, si definiscono casi di test in base ai requisiti specificati e dovrebbero coprire casi "happy day" e "casi limite", in particolare questi ultimi vengono spesso definiti con l'intenzione di violare il software. Quando alcuni dei tuoi test falliscono, mostrano bug / difetti. Quando si dispone di una quantità ragionevole di casi di test per ciascun requisito e tutti i test superati, è possibile che non si sia completamente dimostrato che tutti i requisiti sono soddisfatti, ma è stata migliorata la probabilità per questo, quindi è stata effettuata una verifica.

Quindi, per quella parte della domanda, la ricerca di bug e la verifica possono essere solo due lati dello stesso processo:

i test falliscono: difetti rilevati
test superati: verifica eseguita (almeno, in una certa misura, se fornisci abbastanza e i test giusti)

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

— Doc Brown
fonte

0

Tutto dipende dalla tua definizione di "verifica". Ad esempio, la verifica formale di solito non è qualcosa che viene fatto da un team di controllo qualità, ma è invece una responsabilità degli sviluppatori. Quasi nessuno effettua una verifica formale a causa dell'elevato costo ad esso associato (gap di conoscenza e risorse necessarie).

— Joeri Sebrechts
fonte

0

Il test del software non è uguale al QA. Hai ragione. I test software comprendono in generale molte fasi (fumo, unità, regressione, integrazione, accettazione dell'utente, ecc.).

Pertanto, garantire che il software funzioni in conformità con i requisiti è l'obiettivo principale del controllo qualità (lo specialista di garanzia della qualità - alias un tempo veniva chiamato semplicemente tester anni fa). Tuttavia, non si tratta solo di test . Il controllo qualità garantisce che siano predisposti adeguati processi per eseguire il controllo di qualità del prodotto in questione, o almeno presi in fase di progettazione del progetto.

Quindi, idealmente, ti aspetteresti che il tuo QA verifichi l'applicazione rispetto a una serie di requisiti e non provi semplicemente a testarlo rompendo il software e trovando difetti.

— Yusubov
fonte

Il QA NON sta solo testando. Il controllo qualità riguarda la qualità dei processi di sviluppo.

— John V,

Il QA verifica l'applicazione rispetto a una serie di requisiti.

— Yusubov,