Lo sviluppo o il collaudo dei test unitari?

La scrittura di test automatici è compito di uno sviluppatore; i test fanno parte della base di codice e dovrebbero essere trattati come tali; dovrebbero essere soggetti alle stesse revisioni di codice, standard di codifica, disciplina del controllo della fonte, ecc., come il resto del progetto.

L'esecuzione di detti test viene eseguita per due motivi: in primo luogo, come strumento per guidare gli sviluppatori. Esegui test per verificare che il codice appena scritto esegua ciò che è previsto, che li utilizzi come documentazione aggiuntiva e per verificare che le modifiche non interrompano alcuna funzionalità esistente. Se fai un vero TDD, i test sono anche fonte autorevole di specifiche tecniche. Il secondo motivo per utilizzare i test è durante il controllo qualità e l'implementazione. Eseguire tutti i test automatici dovrebbe essere uno dei primi passi in ogni round di test; eseguire test automatizzati è economico (praticamente non è necessaria alcuna forza di lavoro) e non ha molto senso entrare nei test manuali se falliscono quelli automatici.

Questo significa che le responsabilità dovrebbero essere così:

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

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

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

Ci possono essere diverse spiegazioni (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 elaborare una soluzione che sia adatta a entrambi. Puoi discutere con lei la natura dei test unitari e la differenza fondamentale tra i test unitari vs funzionali / di sistema / di accettazione. Spero che tu possa farle capire che funzionano su livelli molto diversi e che nessuno dei due può sostituire l'altro.
• se è una maniaca del controllo o un burocrate, richiede un rapporto solo per il gusto di farlo, puoi generare qualcosa per soddisfare i suoi capricci con il minimo sforzo (ad esempio ciò che @Doc ha suggerito: -).
• se è coinvolta in un gioco di potere, potresti chiedertene se ha il diritto di richiedere rapporti dagli sviluppatori. Nella mia esperienza, gli sviluppatori di solito non dovrebbero riferire al dipartimento QA.

Penso che il ruolo di QA e Sviluppo, e l'interazione, possano variare molto tra le organizzazioni. Ma in generale, nel mio team, dico ai membri del gruppo di far finta che non ci sia un team di QA, nel senso che sono responsabili dei cambiamenti che stanno spingendo verso la produzione. A sua volta, il nostro team di QA non si occupa molto dei test degli sviluppatori, e fa una discreta quantità di test del sistema come un tutto funzionale.

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

Penso che sia utile per il team di controllo qualità capire che cosa fanno i test unitari e non coprono, ad alto livello, in modo che possiamo lavorare collettivamente per identificare le lacune e le aree che potrebbero richiedere più rigore. Quindi, forse il tuo collega è dopo un sommario di alto livello, al contrario dei dettagli cruenti.

She insisted that devs report what they have unit and integration tested and how.

Sta davvero cercando di discutere se questo tipo di test sia effettivamente nel campo 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 lei voglia solo sapere quali parti del codice sono coperte e dove dovrebbe concentrare gli sforzi della sua squadra.

Ho lavorato a un gruppo di test appena uscito da scuola prima di passare a un ruolo di sviluppo, e posso vedere come questo potrebbe essere utile a lei e al suo team.

Non vedo che importi troppo.

Se non li consegni al QA / Test, e non eseguono test appropriati, e fallisce nella produzione, è colpa loro lasciarlo passare attraverso il QA in produzione senza verificare che funzioni come specificato.

Se li fornisci a QA / Test, e non eseguono test appropriati ... stesso risultato come se non li avessi forniti.

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

In realtà, non vedo molti svantaggi nel fornirli. È ancora su QA / testing per convalidare contro le specifiche. Se prendono il modo pigro e fanno solo affidamento sul fatto che i test sono sufficienti perché sono passati tutti, sono loro che hanno fallito nel loro lavoro. Finché hanno ancora le specifiche, i risultati dei test di unità / integrazione sono semplicemente fluff e non dovrebbero essere in grado di farti male in un modo o nell'altro. Questa è la ragione per cui abbiamo dev e QA. Controlli multipli eseguiti dall'app come specificato.

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

Il test delle unità è 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 potrebbe esserci un sovraccarico se i test delle unità 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.

Esiste anche un test di accettazione degli utenti separato da tutto ciò in quanto l'utente finale può avere una propria comprensione di come un sistema deve funzionare.

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

Spesso, il processo definito include test di unità (che è una buona cosa). Sfortunatamente, questo significa anche che devi documentare i tuoi test unitari e dimostrare che sono stati eseguiti per stare in piedi a fare audit. Ciò significa che hai bisogno di un modo per segnalare i tuoi test unitari.

Guarda uno strumento come Sonar per aiutarti - segnalerà il livello di copertura del codice e i risultati delle tue esecuzioni di test.

Dipende molto dalla società, ma dalla mia esperienza avendo lavorato sia come tester di sistema in un approccio tradizionale, ma anche come tester lavorando in un team agile in un modello di CD, è estremamente utile sapere quale unità è stata testata e integrazione testata .

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

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

Penserei che sarebbe utile fornire questo tipo di cose. La copertura del test unitario dovrebbe essere qualcosa che è noto allo sviluppo e al testing, in modo che possano tenerne conto.

Ovviamente, devi testare le cose business-critical, non importa cosa. È necessario testare la funzionalità comunemente utilizzata a prescindere dal fatto che abbia una copertura di prova unitaria ottimale. Non potrebbe ferire far sapere loro quali altri posti sono coperti dai test unitari. Il codice controlla già casi limite in questo piccolo controllo? Questo tipo di materiale è utile sapere su tutti i lati dell'azienda.

Vale la pena citare l'approccio discusso nel libro "Come Google prova il software": test e controllo di qualità è responsabilità di tutti, e gli standard sono rigorosi.

Il ruolo reale di ciò che viene tradizionalmente definito il dipartimento "Testing" è in realtà la produttività degli sviluppatori; cioè automazione per consentire all'organizzazione di raggiungere economicamente il livello di rigore richiesto.