Gli sviluppatori dovrebbero essere responsabili di test diversi dai test unitari, in caso affermativo quali sono i più comuni?

Attualmente sto lavorando a un progetto piuttosto ampio e ho usato JUnit ed EasyMock per eseguire in modo abbastanza esteso le funzionalità di test dell'unità. Ora sono interessato a quali altri tipi di test dovrei preoccuparmi. Come sviluppatore è mia responsabilità preoccuparmi di cose come test funzionali o di regressione? C'è un buon modo per integrarli in modo utilizzabile in strumenti come Maven / Ant / Gradle? Sono più adatti per un tester o un BA? Ci sono altri tipi utili di test che mi mancano?

È responsabilità dell'utente fornire un codice privo di difetti. È necessario scrivere, aiutare a scrivere o assicurarsi che i test vengano scritti o eseguiti per garantire la sicurezza del codice che si sta consegnando.

Nota: non sto dicendo che è necessario fornire un codice privo di difetti. Piuttosto, dovresti provare a scrivere il miglior codice possibile per i requisiti che ti sono stati dati. Parte della capacità di fare ciò significa che il codice dovrebbe essere testato.

Se ciò significa che sei personalmente responsabile dei test funzionali e di regressione dipende principalmente dall'organizzazione della tua azienda. Tutti i programmatori più esperti che conosco non si chiedono "è mia responsabilità scrivere test di tipo X?". Invece, si chiedono "cosa devo fare per assicurarmi che il mio codice sia correttamente testato?". La risposta potrebbe essere quella di scrivere test unitari o aggiungere test alla regressione, oppure potrebbe significare parlare con un professionista del controllo qualità e aiutarli a capire quali test devono essere scritti. In tutti i casi, tuttavia, significa che si preoccupano abbastanza del codice che stanno scrivendo per assicurarsi che sia testato correttamente.

In conclusione: dovresti essere responsabile della consegna di un codice di alta qualità. Se ciò significa che devi scrivere alcuni test funzionali o di regressione, fallo.

Questo potrebbe aiutarti:

Q1 sono scritti dagli sviluppatori.

Q2 sono automatizzati dagli sviluppatori e scritti in collaborazione con l'azienda e / o i tester.

Ci sono altri tipi utili di test che mi mancano?

Esistono test di accettazione per i quali consiglierei framework in stile BDD che usano il linguaggio Gherkin : JBehave (Java), Cucumber (Ruby), Behat (PHP), ecc. Questo tipo di test presenta alcuni vantaggi rispetto ai test unitari:

• I test sono facilmente leggibili dai non sviluppatori, quindi puoi mostrarli ai clienti
• I test descrivono chiaramente i processi aziendali senza entrare nei dettagli dell'implementazione (non intendo l'implementazione non è importante - lo è sicuramente - ma è meglio quando separi i requisiti aziendali dal codice stesso)
• I test fanno cose che gli utenti faranno usando la tua applicazione
• Sono più facili da scrivere (IMHO, può dipendere dal linguaggio e dalla struttura): niente beffe, meno dettagli tecnici

I test funzionali possono essere automatizzati proprio come i test unitari e sono molto utili per testare il modo in cui i diversi componenti del progetto lavorano insieme e in che modo il sistema riflette le regole aziendali.

Inoltre, questo test automatizzato funge da suite di test di regressione e accettazione per eventuali modifiche importanti (o minori) che è necessario apportare al software (correzione di errori, refactoring, modifica aziendale, nuove funzionalità, ecc.). Questo dà agli sviluppatori molta più fiducia per farlo.

Esistono diversi framework per questo tipo di test, stiamo usando fitnesse con risultati molto buoni. Ha un'ottima libreria per testare le pagine Web (la usiamo per testare la nostra app Web e i nostri servizi Web) e si integra molto bene con Maven e Jenkins .

Abbiamo anche fatto "test interfunzionali" tra sviluppatori, ma questo tipo di test non è "ripetibile", quindi la sua utilità è limitata ...

Come sviluppatore mi ritengo responsabile del test unitario di tutto il mio codice e garantisco al meglio delle mie possibilità che non presenta alcun difetto. Ecco perché abbiamo così tanti strumenti a nostra disposizione come la beffa. L'obiettivo della creazione di oggetti beffardi nei tuoi test è esattamente quello di cercare di isolare il tuo codice dal mondo "esterno" e garantire che funzioni bene e se c'è qualcosa che non va, "non è colpa tua".

Detto questo, nonostante il fatto che non sia colpa tua e che il tuo codice funzioni come dovrebbe, ciò non significa che non puoi aiutare nel resto dei test. Credo che sia anche tua responsabilità aiutare e integrare il tuo lavoro con il lavoro svolto da altri. I team di sviluppo IT dovrebbero lavorare ogni volta come una macchina ben oliata, collaborando con altri dipartimenti (come il QA) come team più grande per fornire software affidabile.

Ma questo è il lavoro di una squadra, non solo la tua.

Ovviamente test di integrazione ; sono più importanti e più difficili da scrivere rispetto ai test unitari. È come costruire una casa; con i test unitari assicuri solo che i mattoni sono solidi e resistono alla pressione, alla temperatura, all'umidità e ad altre condizioni. Ma non hai idea di come la casa appaia e si comporti con i mattoni messi insieme.

Il problema con progetti di grandi dimensioni, in particolare quelli Java che risiedono in un contenitore, è che i test di integrazione sono difficili. Quindi, per facilitare i test di integrazione del sistema in grandi progetti, è necessario un framework di test, realizzato appositamente per il progetto, che è compito dello sviluppatore codificarlo. Recentemente sono stati apportati grandi miglioramenti in questo settore e piattaforme come Arquillian semplificano notevolmente la scrittura di un framework di test (o addirittura lo sostituiscono).

Nel mondo reale sei responsabile solo quanto il tuo team / capo ti ritiene responsabile. Se vieni pagato o indentato a lavorare senza sosta per trovare ogni caso di vantaggio e saltare al capriccio dell'interpretazione del tuo capo (o peggio di marketing) degli errori di logica aziendale, allora sei responsabile di tutto.

Quindi, in altre parole, fai ciò che è richiesto dallo scopo che ti è stato dato. È un bel extra da buttare in un senso comune o vedere gli altri usare il prodotto che stai costruendo per avere un senso di casi d'uso e possibili problemi da risolvere, ma portalo al tuo team o capo prima di "aggiustare". Ciò include gli strumenti di tua scelta. Tutti i tuoi sforzi dovrebbero essere qualcosa con cui tutti sono d'accordo.

Se la tua domanda è di utile tracciamento dei bug, mi piacciono bugzilla, google docs, zendesk o basecamp in termini di sistemi di comunicazione.

Non penso che questo sia già stato coperto - scusate se l'ho perso.

Un problema è l'uso efficiente del tempo degli sviluppatori.

Gli sviluppatori spesso non hanno le competenze per essere bravi in ​​determinati tipi di test. In parte, questo è naturale. È lo stesso motivo per cui gli autori hanno redattori. È molto difficile vedere le carenze di qualcosa se ci sei troppo vicino. Ma riguarda anche diversi set di abilità e diverse specialità.

Stando così le cose, uno sviluppatore che spende tempo test è scarso in termini di costi: termini di beneficio. Lo sviluppatore sarebbe più produttivo facendo altre cose e un tester specializzato sarebbe più produttivo facendo i test.

Ovviamente, stanno facendo varie ipotesi che non sono necessariamente valide. In una piccola azienda, ad esempio, potrebbe non avere senso assumere persone specializzate nei test. Sebbene possa avere più senso impiegare personale di supporto aggiuntivo e fargli fare dei test, o almeno per convincere le persone a testare il codice che non hanno scritto da soli.

Credo che sia nostra responsabilità (anche uno sviluppatore) comprendere tutti i possibili scenari di test prima che venga rilasciato per il QA. Lo scopo del QA è convalidare il software. Inoltre, martellare il tuo codice per gli errori ti farà sempre apparire bene nel momento del QA.

Chi meglio di uno sviluppatore può sapere quali casi di test sono i più rilevanti. Lo sviluppatore dovrebbe essere responsabile dell'esecuzione di tutti i test unitari, ove possibile lo sviluppatore dovrebbe aiutare a scrivere ed eseguire gli script di test. Dato che ciò raramente è possibile in progetti di grandi dimensioni, lo sviluppatore dovrebbe dedicare del tempo a rivedere tutti i casi di test. Inoltre, lo sviluppatore dovrebbe avere conoscenze e utilizzare la vasta gamma di strumenti di test automatizzati disponibili.

Nella mia carriera di sviluppo trovo che i progetti finiscano con risultati migliori se c'è una stretta integrazione tra i team di sviluppo e i team di test.

almeno un membro di ciascuna squadra dovrebbe partecipare anche alle altre riunioni di pianificazione e attuazione.