Lo sviluppo o il collaudo dell'unità è in corso?

Ho avuto una discussione con un responsabile dei test sul ruolo dell'unità e dei test di integrazione. Ha richiesto agli sviluppatori di segnalare ciò che hanno testato unità e integrazione e come. La mia prospettiva è che i test unitari e di integrazione facciano parte del processo di sviluppo, non del processo di test. Al di là della semantica, ciò che intendo è che i test unitari e di integrazione non dovrebbero essere inclusi nei report dei test e che i tester dei sistemi non dovrebbero preoccuparsene. Il mio ragionamento si basa su due cose.

1. I test unitari e di integrazione sono pianificati ed eseguiti sempre contro un'interfaccia e un contratto. Indipendentemente dal fatto che si utilizzino contratti formalizzati, si verifica comunque cosa, ad esempio, si suppone debba fare un metodo, ovvero un contratto.

   Nel test di integrazione si verifica l'interfaccia tra due moduli distinti. L'interfaccia e il contratto determinano il superamento del test. Ma testerai sempre una parte limitata dell'intero sistema. D'altra parte, i test dei sistemi sono pianificati ed eseguiti in base alle specifiche del sistema. Le specifiche determinano il superamento del test.

2. Non vedo alcun valore nel comunicare l'ampiezza e la profondità dell'unità e i test di integrazione al tester (sistemi). Supponiamo che io scriva un rapporto che elenca il tipo di test unitari eseguiti su una particolare classe di livello aziendale. Cosa dovrebbe toglierlo?

   Giudicare ciò che dovrebbe e non dovrebbe essere testato da ciò è una falsa conclusione perché il sistema potrebbe non funzionare nel modo richiesto dalle specifiche anche se tutti i test di unità e integrazione vengono superati.

Potrebbe sembrare una discussione accademica inutile, ma se lavori in un ambiente strettamente formale come me, in realtà è importante per determinare come facciamo le cose. Ad ogni modo, sbaglio totalmente?

Scrivere test automatizzati è compito dello sviluppatore; i test fanno parte della base di codice e dovrebbero essere trattati come tali - dovrebbero essere soggetti alle stesse revisioni del codice, standard di codifica, disciplina di controllo del codice sorgente, ecc., come il resto del progetto.

L'esecuzione di tali test viene eseguita per due motivi: primo, come strumento per guidare gli sviluppatori. Esegui test per verificare che il codice che hai appena scritto faccia come dovrebbe, li usi come documentazione aggiuntiva e per verificare che le modifiche non compromettano alcuna funzionalità esistente. Se fai TDD reale, i test sono anche fonte autorevole di specifiche tecniche. Il secondo motivo per utilizzare i test è durante il QA e la distribuzione. L'esecuzione di tutti i test automatici dovrebbe essere uno dei primi passi in ogni ciclo di test; l'esecuzione di test automatizzati è economica (praticamente nessuna manodopera richiesta) e non ha molto senso sottoporsi a test manuali se quelli automatizzati falliscono.

Ciò significa che le responsabilità dovrebbero essere così:

• Gli sviluppatori scrivono test automatizzati
• Gli sviluppatori eseguono test automatici individuali secondo necessità, come parte del loro flusso di lavoro di sviluppo
• Il QA esegue tutti i test automatizzati come una delle prime fasi del test

Se si dispone di un server di compilazione, l'attività di controllo qualità (relativa ai test automatici) si riduce a "aprire il report del server di build e verificare che tutto sia verde".

Penso che la cosa più importante per te sarebbe chiarire perché ha bisogno di quel rapporto.

Possono esserci spiegazioni diverse (come suggerito da diverse risposte), che richiedono strategie molto diverse.

• se è una persona ragionevole, vuole semplicemente ottenere informazioni per aiutare il lavoro del suo team di test, ha senso arrivare a una comprensione comune e trovare una soluzione che sia adatta a entrambi. Puoi discutere con lei della natura dei test unitari e della differenza fondamentale tra test unitari / funzionali / di sistema / di collaudo. Spero che tu possa farle capire che funzionano a livelli molto diversi e nessuno dei due può sostituire l'altro.
• se è una maniaca del controllo o un burocrate, che richiede un rapporto solo per il gusto di farlo, puoi generare qualcosa per soddisfare i suoi capricci con il minimo sforzo (ad es. cosa suggerito da @Doc :-).
• se è in qualche gioco di potere, potresti chiederti se ha il diritto di richiedere report dagli sviluppatori. Nella mia esperienza, gli sviluppatori di solito non dovrebbero riferire al dipartimento di controllo qualità.

Penso che il ruolo del QA e dello sviluppo e l'interazione possano variare molto tra le organizzazioni. Ma in generale, nel mio team, dico ai membri che si uniscono di far finta che non ci sia un team di controllo qualità, nel senso che sono responsabili dei cambiamenti che stanno spingendo nella produzione. A sua volta, il nostro team addetto al controllo qualità non si assume molto dai test degli sviluppatori e svolge una buona dose di test del sistema nel suo insieme funzionale.

Per questo motivo, il nostro team addetto al controllo qualità non si preoccupa molto di ciò che è e non è testato prima di iniziare i test.

Penso che sia utile per il team QA capire cosa fanno i test unitari e non li coprono, ad alto livello, in modo che possiamo lavorare collettivamente per identificare lacune e aree che potrebbero aver bisogno di più rigore. Quindi, forse il tuo collega sta cercando un riepilogo di alto livello, al contrario dei dettagli cruenti.

Ha insistito sul fatto che gli sviluppatori segnalino cosa hanno testato l'unità e l'integrazione e come.

Sta davvero cercando di discutere se questo tipo di test è effettivamente nel regno dello "sviluppo", o sta solo cercando di capire quanto bene il tuo codice è coperto dai test unitari? Solo guardando le informazioni che hai dato, sembra che voglia solo sapere quali parti del codice sono coperte e dove dovrebbe concentrare gli sforzi della sua squadra.

Ho lavorato in un team di test appena fuori dalla scuola prima di passare a un ruolo di sviluppo e posso vedere come questo potrebbe essere prezioso per lei e il suo team.

Non vedo che importa troppo.

Se non li fornisci a QA / Testing e non eseguono test adeguati e non riescono in produzione, è colpa loro se lasciano passare il QA in produzione senza verificare che funzioni come specificato.

Se li fornisci al QA / Test e non eseguono test adeguati ... stesso risultato come se non li avessi forniti.

Tuttavia, se li fornisci, potrebbero confrontarli anche con le specifiche e / o suggerire quali test potrebbero essere imperfetti o che devono essere modificati perché hanno trovato un bug.

Davvero, non vedo molti svantaggi nel fornire loro. È ancora in fase di controllo qualità / test per convalidare rispetto alle specifiche. Se prendono la strada pigra e fanno semplicemente affidamento sul fatto che i test sono abbastanza buoni perché tutti hanno superato, sono loro che hanno fallito nel loro lavoro. Fintanto che hanno ancora le specifiche, i risultati dei test unitari / di integrazione sono solo fluff e non dovrebbero essere in grado di ferirti in un modo o nell'altro. Questo è il motivo per cui abbiamo dev e QA. Più controlli che l'app esegue come specificato.

Gli sviluppatori commettono errori, il QA commette errori, idealmente entrambi non commettono errori sullo stesso oggetto ... e se lo fanno ... è potenzialmente un analista che ha lasciato cadere la palla scrivendo una specifica poco chiara.

Il test unitario è responsabilità degli sviluppatori che i test possono essere utili per capire come funzionano i pezzi di codice da soli. Alcuni potrebbero vedere questo come una forma di documentazione e quindi ha un certo valore, anche se potrebbero esserci costi generali se i test unitari vengono cambiati regolarmente.

L'altro valore nel superare i test è che questo può evitare di raddoppiare i test che potrebbero essere ridondanti in termini di garanzia della funzionalità di base.

Esistono anche test di accettazione dell'utente separati da tutto ciò in quanto l'utente finale può avere una propria comprensione di come deve funzionare un sistema.

Se la tua azienda ha una metodologia definita per garantire la qualità dei suoi prodotti (se sono conformi a SOX o stanno cercando di migliorare il loro livello CMMI, probabilmente lo fanno), i prodotti devono essere in grado di resistere alla verifica per dimostrare che il processo era seguito.

Spesso, il processo definito include test unitari (che è una buona cosa). Sfortunatamente, ciò significa anche che è necessario documentare i test unitari e dimostrare che sono stati eseguiti al fine di resistere all'audit. Ciò significa che è necessario un modo per riferire sui test unitari.

Guarda uno strumento come Sonar per aiutarti: segnalerà il livello di copertura del codice e i risultati delle tue prove di unità.

Questo dipende molto dall'azienda, ma dalla mia esperienza avendo lavorato sia come tester di sistema in un approccio tradizionale, sia come tester che lavora in un team agile in un modello di CD, sapere cosa è stato testato sull'unità e l'integrazione è estremamente utile.

La qualità è la responsabilità del team: sia gli sviluppatori, i tester che la gestione dei prodotti e lavorare insieme è il modo migliore per garantirlo.

Quindi il responsabile del test vuole sapere cosa è stato testato in unità e integrazione ed è un po 'più lavoro extra per gli sviluppatori, ma risparmia il lavoro complessivo per il progetto! Fornendo le informazioni al responsabile del test, possono concentrare i loro sforzi del team di test su ciò che è critico e importante. Come accennato in precedenza, se un'area di codice non è unitamente testata, il team può concentrare i propri sforzi lì rispetto a un'area fortemente testata: perché duplicare lo sforzo? State tutti lavorando per raggiungere lo stesso obiettivo finale di software di qualità superiore rilasciato in tempo.

Penserei che sarebbe utile fornire questo tipo di cose. La copertura dei test unitari dovrebbe essere qualcosa che è noto per lo sviluppo e i test in modo che possano spiegarlo.

Ovviamente, devi testare le cose fondamentali per il business, qualunque cosa accada. Devi testare duramente la funzionalità di uso comune indipendentemente dal fatto che abbia un'ottima copertura di test unitari. Non ha fatto male far loro sapere quali altri posti sono coperti dai test unitari. Il codice controlla già i casi limite in questo piccolo controllo? Questo tipo di cose è utile da sapere su tutti i lati del business.

Vale la pena menzionare l'approccio discusso nel libro "How Google Tests Software": i test e il controllo di qualità sono responsabilità di tutti e gli standard sono rigorosi.

Il vero ruolo di quello che viene tradizionalmente chiamato dipartimento "Testing" è in realtà la produttività degli sviluppatori; vale a dire automazione per consentire all'organizzazione di raggiungere economicamente il livello di rigore richiesto.