Uno sviluppatore dovrebbe anche fungere da tester? [chiuso]

Siamo un team di scrum composto da 3 sviluppatori, 1 designer, lo scrum master e il proprietario del prodotto. Tuttavia, non abbiamo tester ufficiali nel nostro team. Un problema che è sempre con noi è che testare l'applicazione e superare quei test e rimuovere i bug è stato definito come uno dei criteri per considerare un PBI (Product Backlog Item) come fatto.

Ma il problema è che, non importa quanto noi (3 sviluppatori e 1 designer) proviamo a testare l'applicazione e implementare casi d'uso, tuttavia alcuni bug non vengono visti e rovinano la nostra presentazione ( legge di Murphy ) agli stakeholder.

Come rimedio, abbiamo raccomandato alla società di assumere un nuovo tester. Qualcuno che il suo lavoro sarebbe testare e testare solo. Un tester professionale ufficiale.

Tuttavia, il problema è che, scrum master e le parti interessate ritengono che anche uno sviluppatore (o un designer) dovrebbe essere un tester.

Hanno ragione? Anche noi sviluppatori (anche designer) dovremmo essere tester?

Ex ante: sembra esserci molta confusione su ciò che viene considerato testare ciò che non lo è. Certo, ogni sviluppatore deve testare il suo codice mentre lo crea, deve verificare che funzioni. Non può consegnarlo a un tester prima che pensi che sia fatto e abbastanza buono. Ma gli sviluppatori non vedono tutto. Potrebbero non riconoscere i bug. Questi bug possono essere trovati più avanti 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 tester, ma non dovrebbero essere tester . Gli sviluppatori tendono a evitare involontariamente / inconsciamente di utilizzare l'applicazione in un modo che potrebbe romperla. Questo perché l'hanno scritto e per lo più testato nel modo in cui dovrebbe essere usato.

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

Inoltre, l'utilizzo di sviluppatori come tester aumenta i costi di sviluppo e non avvantaggia la qualità del prodotto tanto quanto avere un tester dedicato. Non permetterei agli sviluppatori di mettere alla prova i loro lavori quando posso farli fare meglio da un tester a buon mercato. Solo se il ciclo di feedback tra sviluppatori e tester diventasse troppo costoso, gli sviluppatori farebbero il test reciproco del codice, ma nella mia esperienza questo è raramente il caso e dipende fortemente dal processo.

Ciò non significa che uno sviluppatore dovrebbe essere sciatto e lasciare tutto al tester. È necessario eseguire il backup del software mediante test unitari e gli errori tecnici devono essere ridotti al minimo prima di consegnare il software al tester. Tuttavia, a volte hai risolto qui, rompi i problemi o altri 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 alla dimensione dell'applicazione), posso anche vedere il tester in un ruolo ibrido, scrivere test unitari e test UI. Dovresti assolutamente assumerne uno .

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

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

Ma testare il proprio 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 REALMENTE CANT assumi un tester, fai in modo che gli sviluppatori eseguano il test incrociato a vicenda, ovvero se A scrive il codice e fa test unitari, fai in modo che B controlli questi test unitari e vedi se ci sono altre cose che potrebbero essere aggiunte . E ottenere B per 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 frega molto, perché non è il LORO codice.

Il giornalista dovrebbe tendere a scrivere correttamente? Voglio dire, è compito dei correttori e degli editori trovare tutti gli errori grammaticali.

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

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

Se uno, oltre allo sviluppo, svolge costantemente anche quel lavoro, significa semplicemente un fatto: è un tester part-time.

non importa quanto noi (3 sviluppatori e 1 designer) proviamo a testare l'applicazione e implementare casi d'uso, tuttavia alcuni bug non vengono visti e rovinano la nostra presentazione ... agli stakeholder.

Prendi in considerazione l'esecuzione di una "corsa controllata" per uno o due sprint, monitorando gli sviluppi e le attività di test separatamente. Al termine di tale esecuzione, analizza i dati raccolti per scoprire quanto impegno dedichi ai test.

Se scopri che il test richiede molto sforzo, passa i dati al management: sarà una prova convincente a supporto della tua richiesta (molto più convincente di quello che hai ora).

Altrimenti (se ritieni che il test richieda poco tempo), considera di investire ulteriori sforzi per farlo meglio (o imparare come farlo). Negoziare lo sforzo aggiuntivo che si pianifica con il proprio management, perché potrebbero preferire assumere un tester. :)

... abbiamo raccomandato alla compagnia di assumere un nuovo tester. Qualcuno che il suo lavoro sarebbe testare e testare solo. Un tester professionale ufficiale.

Tuttavia, il problema è che, scrum master e le parti interessate ritengono che anche uno sviluppatore (o un designer) dovrebbe essere un tester.

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

Ma avere almeno un tester è solo una scommessa sicura - davvero divertente che esitino a provarlo, mentre si dichiarano mischia / agile .

Bene, abbiamo avuto due sviluppatori cross test dopo che il primo ha apportato alcune modifiche alla schermata di inserimento. Questo era quando il nostro tester regolare era spento in congedo di maternità.

Ha sostanzialmente cambiato una schermata di elenco delle fatture utilizzata dagli utenti per selezionare le fatture prima di eseguire lo zoom per eseguire alcune modifiche tramite un pulsante "Modifica". L'elenco originale è stato eliminato e è stata inserita una nuova visualizzazione griglia, con filtri, raggruppamenti, ordinamenti e ogni sorta di funzionalità interessante.

Il test è andato benissimo e hanno caricato le modifiche al cliente il giorno successivo. Due settimane dopo, il cliente chiama e dice "Ci piace molto la nuova cosa che hai inserito, ora possiamo vedere ogni sorta di informazione. Ma ... ehm ... dove andiamo a modificare le fatture ora? ??"

Si scopre che lo sviluppatore ha rimosso 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, nessuno di loro ha trovato nulla di sbagliato in esso ......

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

Come altri hanno già detto, gli sviluppatori possono testare a vicenda il codice degli altri (test unitari o funzionali) e forse il tuo mischia e il proprietario del prodotto possono aiutare con i test di integrazione, ma per i test di accettazione degli utenti dovresti assicurarti di ottenere un sacco di feedback dai test dei clienti, il che significa distribuzioni frequenti con cui possono lavorare come fanno gli utenti reali e un canale di comunicazione davvero aperto .

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

Il test del software è un lavoro professionale a tempo pieno. Ha bisogno di un buon cervello, talento e molta esperienza per diventare un buon tester. È ridicolo supporre che uno sviluppatore di software, per quanto intelligente, possa avvicinarsi a un tester professionista quando il test è solo un piccolo componente del suo lavoro quotidiano.

A ciò si aggiunge il problema che inconsciamente lo sviluppatore del software non vuole trovare bug.

Concordo con il loro punto sul fatto che gli sviluppatori / designer dovrebbero testare il loro codice, con il cavaet che il designer / sviluppatore che ha fatto una sezione di codice non sia l'unico set di "occhi" su quel codice prima di impegnarsi a vivere. Anche se questo non afferrerà tutto, almeno aiuterà ad evitare la cecità che si insinua nel testare e ripetere il test del proprio codice durante lo sviluppo.

Dalla menzione del caso d'uso supporrò che stai usando anche strumenti di copertura del codice? Altrimenti potrebbe aiutare a vedere quale codice potrebbe non essere testato e potrebbe apparire in bug imprevisti in determinate condizioni.

Detto questo, se c'è abbastanza lavoro o la tua organizzazione è di dimensioni decenti, sono d'accordo che è necessaria una persona di QA professionale, aiuterei a focalizzare un po 'di più i ruoli di tutti e potrebbero anche vedere se ci sono modelli su cosa manca, e soprattutto, come risolverlo.