Test funzionale di funzionalità incomplete

3

Ho avuto diverse attività in cui devo eseguire test funzionali (e scrivere script di test automatici) su funzioni che non sono effettivamente complete.

Ad esempio, test CRUD su un progetto per assicurarsi che l'utente possa creare, leggere, aggiornare ed eliminare elementi. All'inizio del processo di creazione, digito tutti i campi e premo un pulsante che dice "Avanti". Sul mock-up e sul wireframe, c'è una pagina specifica che dovrebbe seguire come risultato del clic sul pulsante 'Avanti'. Aspettando che questa pagina appaia, la pagina che ho usato per la creazione di tale elemento viene invece aggiornata, ma l'elemento non viene aggiunto all'elenco come previsto (anche se i dati sono incompleti perché è dovrebbe essere più informazioni da aggiungere dopo aver fatto clic su 'Avanti').

Ho avuto diverse attività come questa, dove sto testando e tentando di scrivere script automatici per funzionalità su progetti che non sono completi. Per me, test dell'unità (testare il codice stesso) durante questa fase di sviluppo ha senso; il test funzionale no. Sono nuovo di SQA e un nuovo professionista nel mondo del software, quindi non so se la mia inesperienza sta intralciando. Poi mi confondo perché mi viene detto di testare una funzionalità che mi aspetto venga "completata" ma, facendo riferimento alla documentazione, non è davvero completa. Allora mi gratto la testa pensando che ho qualcosa di sbagliato, che è seguito a breve da me che interrompi uno sviluppatore per chiedergli se mi manca qualcosa; questo sembra essere un uso inefficiente del tempo.

È questo il modo corretto di fare test? Le caratteristiche di un progetto devono essere prima complete?

    
posta 8protons 02.09.2016 - 19:49
fonte

1 risposta

2

Sfortunatamente, se aspetti che tutto sia finito per i test, potresti scoprire troppe cose sbagliate contemporaneamente, e sarà un incubo stressante pulire il casino. Forse solo allora - troppo tardi - scoprirai che le assunzioni fondamentali erano viziate ( a volte con conseguenze catastrofiche ) .

La qualità del software è qualcosa che devi garantire dall'inizio alla fine del processo di sviluppo. E un aspetto della qualità è garantire che le parti sviluppate funzionino come previsto, il prima possibile e, se possibile, prima di assemblarle in parti più complesse.

Più il tuo test è unitario, più facile sarà trovare i bug: se aspetti che due parti interelate siano terminate prima di testare una funzione, e il test fallisce, devi prima scoprire in quale parte il problema è .

Esiste anche un approccio Test Driven Development , che richiede di scrivere prima il test e poi il codice al fine di ottenere una maggiore affidabilità.

Quindi sì, è normale testare prima che tutto sia finito!

Ora le tecniche: potresti essere interessato all'utilizzo di raddoppio dei test . Senza entrare in tutti i dettagli , potresti utilizzare stub di test, mock e oggetti falsi, in modo che il test dell'unità possa concentrarsi su cosa c'è già e simula ipotesi sulla chat ancora nella pipe.

    
risposta data 03.09.2016 - 16:21
fonte