Abbiamo bisogno di dati di test o possiamo fare affidamento su test unitari e test manuali?

Attualmente stiamo lavorando a un progetto PHP / MySQL medio / grande. Stiamo effettuando test di unità con PHPUnit e QUnit e abbiamo due tester a tempo pieno che stanno testando manualmente l'applicazione. I nostri dati di test (finti) sono attualmente creati con script SQL.

Abbiamo problemi con la gestione degli script per i dati di test. La logica di business è piuttosto complessa e una modifica "semplice" nei dati di test spesso produce diversi bug nell'applicazione (che non sono veri e propri bug, ma solo il prodotto di dati non validi). Questo è diventato un grosso fardello per tutto il team perché creiamo e cambiamo costantemente tavoli.

Non vedo davvero il punto di mantenere i dati dei test negli script perché tutto può essere aggiunto manualmente nell'applicazione in circa 5 minuti con l'interfaccia utente. Il nostro PM non è d'accordo e afferma che avere un progetto che non possiamo distribuire con i dati di test è una cattiva pratica.

Dovremmo abbandonare la manutenzione degli script con i dati di test e lasciare che i tester testino l'applicazione senza dati? Qual è la migliore pratica?

— Christian P
fonte

Risposte:

Stai mescolando due concetti diversi. Uno è la verifica , che si basa su Test unitari e Revisioni tra pari. Questo può essere fatto dagli stessi sviluppatori, senza dati di test e il suo intento è verificare che una serie di requisiti sia soddisfatta.

Il secondo è la validazione , e questo viene fatto dal QA (i tuoi tester). Per questo passaggio sono necessari i dati di test poiché il tester non deve avere alcuna conoscenza della programmazione nell'applicazione, ma solo i casi d'uso previsti. Il suo obiettivo è convalidare che l'applicazione si comporti come previsto in un ambiente di produzione.

Entrambi i processi sono importanti e necessari per fornire un prodotto di qualità al cliente. Non puoi fare affidamento solo sui test unitari. Quello che devi capire è un modo affidabile per gestire i tuoi dati di test per garantirne la validità.

EDIT: OK, ho quello che mi stai chiedendo. La risposta è sì, perché il compito del Tester non è generare i dati di test, ma solo testare l'applicazione. È necessario creare gli script in modo da facilitare la manutenzione e garantire l'inserimento di dati validi. Senza i dati del test, il tester non avrà nulla da testare. Detto questo, tuttavia, se si ha accesso all'ambiente di test , non vedo perché non è possibile inserire manualmente i dati del test anziché utilizzare gli script.

— AJC
fonte

Forse ho sbagliato la mia domanda citando i test di unità e i dati di test. Comprendo che la validazione non è la stessa del test unitario. Il mio problema qui è che i dati di test che stiamo creando con gli script possono essere creati tramite l'interfaccia utente in 5 minuti. Per inserire questi dati nell'applicazione non è necessario conoscere la programmazione, è sufficiente seguire i casi di test.

— Christian P,

@ christian.p controlla il mio aggiornamento per quanto riguarda il chiarimento della domanda.

— AJC,

Quindi la tua soluzione è abbandonare gli script e solo aggiungere manualmente i dati dei test tramite l'interfaccia utente? Che dire della risposta fornita da P.Brian.Mackey e delle sue risposte all'accoppiamento dei dati con l'interfaccia utente?

— Christian P,

@ christian.p Bene, sono d'accordo che dovresti usare gli script. MA non c'è formalità o regola che dice che DEVI. Il motivo principale per utilizzare gli script per generare dati fittizi è la velocità (automazione) e l'accesso (all'ambiente di test). Se hai accesso ed è più veloce e più semplice farlo manualmente, non c'è motivo per cui non puoi farlo. (MA tenere un registro dei dati con cui si è testato).

— AJC,

ogni tester ha il proprio ambiente di test e i tester fanno cadere completamente il db più volte al giorno, quindi non è pratico aggiungere manualmente i dati di test, ma possiamo chiedere loro educatamente di aggiungere alcuni dati per i test.

— Christian P,

Sì, avere test unitari e modelli di dati è una buona pratica. Il project manager è corretto. Poiché l'esecuzione di una "semplice" modifica dei dati del test produce spesso bug, questo è il nocciolo del problema.

Il codice deve essere migliorato. Non farlo (dicendo che non abbiamo bisogno di test) non è una soluzione, è semplicemente aggiungere un debito tecnico . Suddividere il codice in unità più piccole più testabili perché non è possibile identificare le unità senza rotture.

Inizia a fare un refattore. Mantenere i miglioramenti piccoli in modo che siano gestibili. Cerca anti-pattern come le classi / i metodi di Dio, non seguendo il DRY, la singola responsabilità, ecc ...

Infine, guarda TDD per vedere se funziona per il team. TDD funziona bene per garantire che tutto il codice sia in grado di eseguire test ( perché si scrivono prima i test) e anche per assicurarsi di rimanere snelli scrivendo il codice sufficiente per superare i test (minimizzare oltre l'ingegneria).

In generale, se una serie di complessi processi logici aziendali produce un insieme di dati, lo considero un report. Incapsulare il rapporto. Eseguire il report e utilizzare l'oggetto risultante come input per il test successivo.

— P.Brian.Mackey
fonte

Devo chiarire un po 'le cose: "La semplice modifica dei dati di test produce bug" - il problema qui non è nell'applicazione - l'app funziona bene quando i dati sono validi (e non è possibile aggiungere manualmente dati non validi) . Il problema qui è che dati di test non validi possono produrre errori quando si tenta di lavorare su tali dati. Quindi dobbiamo testare anche i dati del test?

— Christian P,

Non farti inciampare in un errore di aringhe rosse. Il fatto che i dati del test introducano un bug è un problema diverso tutti insieme. Rimuovere i test non è una soluzione, "governare il governo" è anche qualcos'altro. Il problema è il codice. Non è verificabile perché ci stai dicendo che non sei in grado di scrivere test che non rompono le cose. Ecco perché è necessario migliorare il codice.

— P.Brian.Mackey,

Forse hai frainteso la mia domanda. Abbiamo test di unità di lavoro e ogni nuova funzionalità che scriviamo ha test di unità. Non sto suggerendo di rimuovere i test che non vengono superati o di non scriverli affatto. Sto solo suggerendo che non usiamo gli script per creare dati fittizi nel database perché i tester manuali stanno facendo la stessa cosa.

— Christian P,

"Non vedo davvero il punto di mantenere i dati dei test negli script" <- Il supporto per i test di caduta è quello che sto dicendo. Non cancellazione di vecchi test. È una cattiva idea. Stai diminuendo la riproducibilità e ti stai accoppiando a un'interfaccia utente che fa parte di ciò che stai cercando di testare e di essere in grado di adattarti ai cambiamenti. Separati dall'interfaccia utente. Mantieni l'automazione dei dati.

— P.Brian.Mackey,

Ma come possiamo affrontare il problema dei dati fittizi non validi? Se continuiamo a creare dati fittizi per il database, come possiamo verificare se i dati fittizi sono ok o no? Se la regola aziendale richiede quel valore X = 2 e il database accetta X = 100 - come possiamo verificare l'integrità dei dati di test quando la regola aziendale è complessa?

— Christian P,

Questo è un problema molto comune e anche molto difficile. I test automatici eseguiti su un databse (anche un database in memoria, come HSQLDB ) sono generalmente lenti, non deterministici e, poiché un fallimento del test indica solo che c'è un problema da qualche parte nel tuo codice o nei tuoi dati, sono non molto informativo.

Nella mia esperienza, la migliore strategia è quella di concentrarsi sui test unitari per la logica aziendale. Prova a coprire il più possibile il tuo codice di dominio principale. Se ottieni questa parte nel modo giusto, che è di per sé una vera sfida, otterrai i migliori rapporti costi-benefici per i test automatizzati. Per quanto riguarda il livello di persistenza, normalmente investo molto meno sforzo nei test automatici e lo lascio ai tester manuali dedicati.

Ma se vuoi davvero (o hai bisogno) di automatizzare i test di persistenza, ti consiglio di leggere un software in crescita orientato agli oggetti, guidato da test . Questo libro ha un intero capitolo dedicato ai test di persistenza.

— Otavio Macedo
fonte