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

È tua responsabilità impegnarti a fornire un codice privo di difetti. Dovresti scrivere, aiutare a scrivere o garantire che i test vengano scritti o eseguiti per darti fiducia nel codice che stai fornendo.

Nota: non sto dicendo che è necessario fornire un codice privo di difetti. Piuttosto, dovresti provare a scrivere il codice migliore che puoi per i requisiti che ti sono stati dati. Parte di essere in grado di farlo significa che il codice dovrebbe essere testato.

Se ciò significa che sei personalmente responsabile per i test funzionali e di regressione è principalmente una funzione di come è organizzata la tua azienda. Tutti i più abili programmatori 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 stato testato correttamente?". La risposta potrebbe essere scrivere test unitari, o aggiungere test alla regressione, o potrebbe voler dire 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 adeguatamente testato.

In conclusione: dovresti essere responsabile della fornitura di 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.

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

Are there other useful types of testing that I am missing?

Esistono test di accettazione per i quali raccomando i framework in stile BDD che utilizzano lingua 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 di business senza entrare nei dettagli dell'implementazione (non intendo dire che l'implementazione non è importante - lo è sicuramente - ma è meglio quando si separano i requisiti di business 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 dal framework): nessun derisione, meno dettagli tecnici

Il test funzionale può essere automatizzato come i test di unità e sono molto utili per testare come i diversi componenti del progetto funzionano insieme e in che misura il tuo sistema rispecchia le regole aziendali.

Inoltre, questo test automatizzato funge da suite di test di regressione e accettazione per eventuali modifiche principali (o minori) che devi eseguire al software (correzione di bug, refactoring, cambio di attività, nuove funzionalità, ecc.). Questo dà agli sviluppatori molta più fiducia nel farlo.

Esistono diversi framework per questo tipo di test, stiamo usando fitnesse con ottimi risultati. 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 di funzionalità incrociata", tra sviluppatori, ma questo tipo di test non è "ripetibile", quindi la sua utilità è limitata ...

Come sviluppatore mi considero responsabile dell'unità per testare tutto il mio codice e garantire al meglio delle mie possibilità che non ha difetti. Ecco perché abbiamo così tanti strumenti a nostra disposizione come il deridere. L'obiettivo di creare oggetti di simulazione nei test è esattamente quello di provare e isolare il codice dal mondo "esterno" e garantire che funzioni correttamente e se c'è qualcosa che non funziona, "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 sul lavoro fatto da altri. I team di sviluppo IT dovrebbero lavorare ogni volta come una macchina ben oliata, lavorando insieme ad altri reparti (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 il collaudo dell'unità si assicura solo che i mattoni sono solidi e resistono a pressione, temperatura, umidità e altre condizioni. Ma non hai idea di come la casa appaia e si comporti con i mattoni messi insieme.

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

Nel mondo reale sei solo responsabile quanto il tuo team / boss ti ritiene responsabile. Se sei pagato o indentificato per lavorare senza sosta per trovare ogni angolo e ogni brutta situazione e saltare al capriccio dell'interpretazione dei bug della logica del tuo capo (o del suo marketing peggiore), allora con tutti i mezzi sei responsabile di tutto.

Quindi, in altre parole, fai ciò che è richiesto dallo scope dato a te. È un bel extra da buttare nel buon senso o vedere gli altri usare il prodotto che stai costruendo per avere un'idea dei casi d'uso e dei possibili problemi da risolvere, ma portalo alla tua squadra o al tuo capo prima di "aggiustare". Questo include gli strumenti di tua scelta. Tutti i tuoi sforzi dovrebbero essere qualcosa con cui tutti sono a bordo.

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

Non penso questo è già stato trattato - scusa se mi sono perso.

Un problema è l'uso efficiente del tempo di un programmatore.

Gli sviluppatori spesso non hanno le capacità per essere bravi in determinati tipi di test. In parte, questo è naturale. È lo stesso motivo per cui gli autori hanno editori. È molto difficile vedere le carenze in qualcosa se sei troppo vicino ad esso. Ma si tratta anche di diverse abilità e diverse specialità.

Stando così le cose, un test di spesa per gli sviluppatori è carente in termini di costi: i termini del sussidio. Quello sviluppatore sarebbe più produttivo a fare altre cose, e un tester specializzato sarebbe più produttivo nel fare i test.

Ovviamente questo sta facendo varie ipotesi che non sono necessariamente valide. In una piccola azienda, ad esempio, potrebbe non avere senso impiegare persone specializzate nei test. Anche se potrebbe essere più sensato impiegare personale addetto all'assistenza e fare test, o almeno per convincere le persone a testare il codice che non hanno scritto da soli.

Credo che sia responsabilità del nostro (uno sviluppatore) includere tutti i possibili scenari di test prima che venga rilasciato per il controllo qualità. Lo scopo del controllo qualità è di validare il software. Inoltre, battere il tuo codice per gli errori ti farà apparire sempre al meglio con il QA.

Chi meglio di uno sviluppatore sa quali sono i casi di test più rilevanti. Lo sviluppatore dovrebbe essere responsabile di eseguire tutti i test delle unità, laddove possibile lo sviluppatore dovrebbe aiutare a scrivere ed eseguire gli script di test. Poiché ciò è raramente possibile in progetti di grandi dimensioni, è necessario dare allo sviluppatore il tempo di rivedere tutti i casi di test. Inoltre lo sviluppatore dovrebbe avere conoscenze e utilizzare l'ampia varietà di strumenti di test automatici disponibili.

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

almeno un membro di ogni squadra dovrebbe sedere anche nelle altre riunioni di pianificazione e implementazione.