Test di sistema vs Test di accettazione - Differenza nei test

Question

Sono un po 'confuso circa la reale differenza tra test di sistema e test di accettazione. Quando cerco questo argomento le risposte sono diverse e non riesco a vedere come i testicoli possono essere molto diversi.

I fatti ho scoperto:

test Sistema è condotta su tutto il sistema ed è fatto dal fornitore. I test di sistema sono test end-to-end in cui si verificano i flussi completi nel sistema (dal login al logout) in base alle specifiche dei requisiti (sia funzionali che non).

Il test di accettazione viene eseguito dal cliente per verificare che soddisfi la richiesta dei clienti. Questo è anche flusso completo e si basa sulle specifiche del requisito. TUTTAVIA il sistema che è stato costruito è stato progettato in base alle specifiche dei requisiti e l'aspetto/usabilità di solito è già accettato nelle prime fasi del ciclo di sviluppo. Se il sistema copre le specifiche del requisito, non dovrebbe essere possibile per il cliente dire "questo non è quello che volevamo, ripetere questo e quello", a meno che il contratto non lo consenta e il cliente paghi l'ora.

Quindi, la mia domanda è fondamentalmente, come sarebbero diversi i casi di test per queste due fasi di test? Entrambi sono test end-to-end e si focalizzano sul fatto che si tratta di un sistema funzionale e soddisfa le specifiche, che nella misura sono anche le esigenze aziendali (poiché è ciò che hanno ordinato). Sembra che i test case dal test del sistema possano essere riutilizzati nei test di accettazione in quanto entrambi coprono i flussi completi?

Answer 1

I test di accettazione da parte del cliente non devono avere veri casi di test formali. Si tratta del client che utilizza il sistema come previsto e vede dove la loro comprensione di come funzionerebbe corrisponde a ciò che effettivamente fa. I test test vincolano il test di accettazione perché in genere le cose sollevate da esso sono come "X è grande, ma puoi anche aggiungere Y" e "Abbiamo detto che il campo Z dovrebbe essere un numero intero ma in realtà potremmo aver bisogno di inserire del testo anche lì".

Answer 2

La risposta breve è questa:

test del sistema Cantata da sviluppatori e/o QA per garantire che il sistema fa quello che è stato progettato per fare. Questo può essere fatto automaticamente usando, per esempio, qualcosa come il selenio (per un'applicazione web). Lo scopo è quello di garantire la qualità e molte organizzazioni non si preoccupano di questo.

Test di accettazione Eseguiti da clienti e/o gestori per garantire che il sistema faccia ciò che pensano che dovrebbe. Generalmente viene considerata la fine dell'obbligo contrattuale degli sviluppatori di correggere il software.

La differenza è che un test di sistema di solito verifica le cose a cui il cliente non interessa molto, ad esempio "Le connessioni al database vengono eseguite nell'ordine corretto". I test di accettazione di solito si concentrano su cose come "Come è l'esperienza dell'utente soggettivo".

Answer 3

Entrambi i tipi di test vengono eseguiti sull'intero sistema/applicazione. È molto probabile che molti test si sovrappongano.

Un test di sistema viene spesso eseguito da un team di controllo qualità indipendente in un ambiente simile alla produzione. Questa potrebbe essere la prima volta che tutti i componenti vengono testati insieme.

Il test di accettazione viene spesso eseguito nello stesso ambiente o in un ambiente simile (anche simile alla produzione), ma il make-up del team spesso è costituito da un sottoinsieme degli utenti effettivi del sistema. Una credenza è che gli utenti identificheranno scenari, difetti e osserveranno comportamenti che un tester regolare trascurerebbe. Inoltre, questo può fornire un livello di comfort agli utenti prima che vengano distribuiti nella produzione.

Se si utilizza un V-Model, il test di sistema si allinea con la progettazione a livello di sistema e il test di accettazione è conforme ai requisiti aziendali.