Uno sviluppatore dovrebbe anche fungere da tester? [chiuso]

Ex ante: sembra esserci molta confusione su ciò che è considerato come testare ciò che non lo è. Certo, ogni sviluppatore ha bisogno di testare il suo codice mentre lo crea, lui / lei ha bisogno di verificare che funzioni. Lui / lei non può consegnarlo a un tester prima che lui / lei pensi che sia fatto e abbastanza buono. Ma gli sviluppatori non vedono tutto. Potrebbero non riconoscere gli errori. Questi bug possono essere trovati solo più tardi nel ciclo di sviluppo quando vengono condotti test approfonditi. La domanda è se gli sviluppatori debbano condurre questo tipo di test o meno, e a mio modesto parere questo deve essere considerato dal punto di vista del project manager:

Gli sviluppatori possono essere dei tester, ma non dovrebbero essere dei tester . Gli sviluppatori tendono a evitare involontariamente / inconsciamente di usare l'applicazione in un modo che potrebbe romperla. Questo perché l'hanno scritto e per lo più lo testano nel modo in cui dovrebbe essere usato.

Un buon tester d'altra parte, cerca di torturare l'applicazione. La sua intenzione principale è quella di romperlo. Spesso usano l'applicazione in modi che gli sviluppatori non avrebbero immaginato. Sono più vicini agli utenti che agli sviluppatori e spesso hanno un approccio diverso per testare un flusso di lavoro.

Inoltre, l'uso di sviluppatori come tester aumenta i costi di sviluppo e non giova alla qualità del prodotto tanto quanto a un tester dedicato. Non permetterei agli sviluppatori di testare i loro lavori quando posso farlo funzionare meglio da un tester economico. Solo se il ciclo di feedback tra sviluppatori e tester è diventato troppo costoso, vorrei che gli sviluppatori si incrociassero reciprocamente il codice, ma nella mia esperienza è raro che avvenga e dipende molto dal processo.

Ciò non significa che uno sviluppatore debba essere sciatto e lasciare tutto al tester. Il software dovrebbe essere supportato da test unitari e gli errori tecnici dovrebbero essere ridotti al minimo prima di consegnare il software al tester. Tuttavia, a volte hai risolvi qui, rompi i problemi o altro bug che nessuno sviluppatore potrebbe prevedere, va bene. Inoltre, i test di integrazione dovrebbero essere eseguiti principalmente dagli sviluppatori. L'obiettivo principale del tester è verificare che i requisiti siano soddisfatti.

In un team così piccolo (e anche in base alle dimensioni dell'applicazione), posso anche vedere il tester in un ruolo ibrido, scrivendo unit test e test dell'interfaccia utente. Dovresti assumerne uno .

Ma più importanti del tester sono i freeze / rami regolari. Non presentare nulla che non sia stato testato correttamente. Quando hai aggiunto una funzione o cambiato qualcosa, tutto ciò che lo circonda deve essere nuovamente verificato. Riceverai solo una brutta reputazione se la tua azienda non lo fa. Non rilasciare qualcosa di instabile. Quando il cliente desidera avere il software entro una certa data, quindi smettere di sviluppare abbastanza presto e testarlo correttamente, in modo da avere abbastanza tempo per le correzioni di bug. Spesso è meglio rifiutare le richieste di funzionalità dell'ultimo minuto piuttosto che implementarle male o rilasciare senza test adeguati.

Gli sviluppatori possono essere tester - del codice di altri sviluppatori.

Ma testare il tuo codice non è una buona mossa - gli sviluppatori tendono ad avere blocchi mentali sul proprio codice, e quindi hanno difficoltà a progettare test completi o appropriati.

Ci saranno sempre sviluppatori che pensano di farlo bene, ma di solito non lo fanno (e sono sicuro di avere molti punti ciechi).

Se VERAMENTE CANTATE assumi un tester, quindi fai in modo che gli sviluppatori si confrontino tra loro sul lavoro degli altri - cioè, se A scrive il codice e fa test unitari, quindi ottieni B per esaminare quei test unitari e vedere se ci sono altre cose potrebbe essere aggiunto. E chiedi a B di provare e testare il codice (come utente) e segnalare i difetti.

Questo non è perfetto ma è meglio di un singolo sviluppatore che cerca di fare tutto.

A volte i tuoi colleghi possono essere davvero bravi a rompere il tuo software, perché ne traggono piacere e non gliene importa molto - perché non è il loro codice.

Il giornalista dovrebbe scrivere correttamente? Voglio dire, è compito di correttori e redattori trovare tutti gli errori grammaticali.

Tuttavia, i giornalisti forniscono da soli un controllo ortografico. Tuttavia, il correttore è una professione separata e importante.

Lo stesso su sviluppatori e tester, eccetto il fatto che il controllo qualità è una parte ancora più importante dello sviluppo. Anche se sei un buon sviluppatore, semplicemente non avere il tempo di testare accuratamente tutti i casi di test, per coprire tutti gli ambienti, i browser, i sistemi operativi supportati dal tuo prodotto.

Se uno, oltre a sviluppare, anche a fare costantemente quel lavoro, significa solo un semplice fatto: è un tester part-time.

Bene, due sviluppatori si sono sottoposti a un test incrociato dopo che il primo ha apportato alcune modifiche a una schermata di immissione. Questo è stato quando il nostro tester regolare era in congedo di maternità.

Fondamentalmente ha cambiato una schermata di elenco delle fatture che gli utenti usavano per selezionare le fatture prima di eseguire lo zoom per eseguire alcune modifiche tramite un pulsante "Modifica". L'elenco originale è stato buttato fuori e una nuova gridview è stata inserita, con filtri, raggruppamenti, ordinamento e tutti i tipi di funzionalità interessanti.

I test sono andati alla grande e hanno caricato le modifiche al cliente il giorno successivo. Due settimane più tardi, il cliente chiama e dice "Ci piace molto il nuovo oggetto che hai inserito, ora possiamo vedere tutti i tipi di informazioni. Ma ... ehm ... dove andiamo a modificare le fatture ora? ?? "

Lo sviluppatore ha estratto la casella di controllo (per la selezione) e il pulsante di modifica e poiché gli sviluppatori hanno sempre fatto doppio clic per selezionare un elemento in ogni caso, nessuno di essi ha trovato nulla di sbagliato ......

Gli sviluppatori e gli utenti vivono in mondi diversi, con test incrociati è meglio che avere lo sviluppatore testare il proprio lavoro ma non è ancora la stessa cosa.

no matter how much we (3 developers and 1 designer) try to test the application and implemented use cases, still some bugs are not seen and ruin our presentation... to stakeholders.

Considera di eseguire una "corsa controllata" per uno sprint o due, eseguendo il monitoraggio e gli sforzi di test separatamente. Al termine di tale analisi, analizza i dati raccolti per scoprire quanto impegno spendi per i test.

Se scopri che il testing richiede molto impegno, passa i dati alla gestione: sarà una prova convincente che supporta la tua richiesta (molto più convincente di quanto non hai ora).

Altrimenti (se ritieni che il tuo test richieda poco tempo), considera di investire ulteriori sforzi per farlo meglio (o apprendi come farlo). Negozia lo sforzo aggiuntivo che pianifichi con il tuo management, perché preferiscono assumere un tester. :)

...we recommended that the company hire a new tester. Someone who's job would be testing, and testing only. An official professional tester.

However, the problem is that, scrum master and stakeholders believe that a developer (or a designer) should also be a tester.

Devo ammettere che la gestione della tua azienda mi sembra piuttosto noiosa. Voglio dire - ok, potrebbe essere davvero difficile scoprire quanti tester sarebbero i migliori per il progetto, bene.

Ma avere almeno un tester è solo una scommessa sicura - davvero divertente che loro esitano a fare un tentativo, mentre si rivendicano scrum / < a href="http://www.halfarsedagilemanifesto.org/"> agile .

Come altri qui hanno detto che gli sviluppatori possono testare reciprocamente il codice (test di unità o funzionale) e forse il tuo supervisore e proprietario del prodotto possono aiutarti con i test di integrazione, ma per i test di accettazione degli utenti dovresti assicurarti ottenere molti feedback dai test del cliente - che significa frequenti implementazioni con cui possono lavorare nel modo in cui gli utenti reali fanno e un canale di comunicazione davvero aperto .

Dovresti progettare pensando alla testabilità, ma se non hai un tester dedicato, alcune cose semplicemente scivoleranno attraverso le crepe perché non ci sono abbastanza ore al giorno per progettare, implementare e testare il software.

Sono d'accordo con il loro punto che gli sviluppatori / designer dovrebbero testare il loro codice, con il cavaet che il designer / sviluppatore che ha fatto una sezione di codice non è l'unico insieme di "occhi" su quel codice prima di impegnarsi a vivere . Anche se questo non accetterà tutto, aiuterà almeno ad evitare la cecità che si insinua a testare e ritestare il proprio codice durante lo sviluppo.

Dalla menzione del caso d'uso presumo che usi anche strumenti di copertura del codice? In caso contrario, potrebbe aiutare a vedere quale codice potrebbe non essere testato e potrebbe verificarsi un errore inaspettato in determinate condizioni.

Detto questo, se c'è abbastanza lavoro o la tua organizzazione è di dimensioni decenti, sono d'accordo che una persona di qualità professionale è necessaria, aiuterebbe a concentrare un po 'di più i ruoli di tutti, e potrebbe anche vedere se ci sono dei modelli per quanto riguarda ciò che è mancato e, ancora più importante, come risolverlo.

Il software di test è un lavoro professionale a tempo pieno. Ha bisogno di un buon cervello, talento e tanta esperienza per diventare un buon tester. È ridicolo supporre che uno sviluppatore di software, non importa quanto intelligente, può avvicinarsi a un tester professionista quando il test è solo una piccola parte del suo lavoro quotidiano.

Inoltre, il problema è che inconsciamente lo sviluppatore non vuole trovare i bug.