Un programmatore dovrebbe essere autosufficiente?

Nel mio attuale posto di lavoro, non disponiamo di tester, la cui logica è la gestione: "se avessimo tester, non testereste affatto il vostro codice". Questo tipo di pensiero sembra essere dannoso per la qualità del prodotto, poiché mentre collaudo il mio codice, ci sono molte cose che mi mancheranno solo per il fatto che conosco il sistema e non so come usare sbagliato". Il test della scatola nera non funziona davvero perché inconsciamente evito le insidie ​​in cui cadrebbe un tester dedicato. Gran parte del mio tempo va nella correzione di bug che sono stati inseriti nel codice di produzione e trovati dall'utente finale.

Il sistema in questione è grande ma è sviluppato esclusivamente da me. Ciò ha anche causato il cadere in grembo di alcuni compiti gestionali, come la definizione di programmi e l'elaborazione delle specifiche.

Questo tipo di compiti dovrebbe essere la mia responsabilità? Mi vedo rigorosamente come programmatore e nient'altro. E se queste sono le mie responsabilità, fino a che punto? Quando un progetto è così grande da richiedere tester? Un programmatore dovrebbe perfezionare le specifiche, preoccuparsi della gestione del progetto o persino fornire assistenza ai clienti?

Nota

Alcuni potrebbero avere l'impressione che io sia contrario ad ampliare le mie responsabilità - non è questo il caso, sono ansioso di ottenere un ruolo che coinvolge più funzioni di gestione, ma attualmente non è nella mia descrizione del lavoro. Fino a quando non sarò ufficialmente assunto come tale o i compiti aggiuntivi inizieranno a mostrare nella mia busta paga, penserò a me stesso come "solo" un programmatore. Sfortunatamente, come sviluppatore junior, il passaggio alle funzioni manageriali non accadrà molto presto.

Finora risposte eccellenti, continua a venire se hai qualcosa da aggiungere o esperienze personali da condividere!

È fare avere tester. Solo, li chiami "utenti finali". Questo è dannoso per tutti i motivi che descrivi; non importa quanto coscienzioso sia un programmatore, semplicemente non sarai mai in grado di fare un lavoro abbastanza buono superando i tuoi preconcetti su come il codice dovrebbe essere usato per trovare tutti i modi in cui può rovinare .

Devi riaprire questo problema con la direzione. A questo punto, sembra che tu abbia alcuni dati concreti a sostegno del tuo caso; l'attuale approccio pratico all'assicurazione della qualità fa sprecare tempo e compromette l'esperienza degli utenti. Devi stare attento a come lo presenti in modo che sia chiaro che questo è un problema strutturale e non un caso di "Fai schifo ai test", ma suona come una discussione che deve avvenire.

Sembra che tu stia arrivando a un bivio con questo datore di lavoro. Se sei intenzionato a rimanere un programmatore e nient'altro, potrebbe essere necessario iniziare a respingere e richiedere che inizino a procurarti l'aiuto di cui hai bisogno per rimuovere alcune delle attività manageriali dal piatto, portando qualcuno nuovo o espandere le responsabilità di un collaboratore esistente. ("Questo non è quello per cui mi hai assunto, e questi compiti non vanno via. Il tempo che dedico a fare queste cose male è il tempo che non spendo per quello in cui sono bravo.") non essere realistico. Pensi di riuscire a passare a un ruolo più manageriale se ti fornissero le risorse e l'autorità di cui avresti bisogno per fare il lavoro giusto?

Quanto deve essere grande un progetto prima che abbia bisogno di tester, non sono sicuro di come definire con precisione quella linea, ma penso sicuramente che tu l'abbia superato. Stai spendendo più tempo di quanto desideri correggere segnalazioni di bug provenienti da utenti reali; per me che dice che è tempo di dedicare più sforzi a impedire agli utenti di arrivare agli utenti.

Sì. Se è necessario , dovresti essere in grado di testare il tuo codice. (Non sto parlando di unit test, ma di test di accettazione e simili.)

No . I tester sono più bravi nei test di te. E come fai notare, proprio come la correzione di bozze, è molto difficile individuare i tuoi errori. Avere bulbi oculari extra avrà un impatto (buono) importante sulla qualità del programma.

Hai molte altre domande. Risponderò solo a uno:

Un programmatore dovrebbe affinare le specifiche?

Sì! Devi implementare la specifica, quindi devi assicurarti che la specifica sia effettivamente implementabile. Inoltre, in qualità di programmatore, addestrato a ragionare in modo chiaro, precisione e simili, puoi aiutare le persone a scoprire ciò che effettivamente deve essere fatto e eliminare requisiti ambigui o logicamente imperfetti.

Quello che stanno dicendo e la realtà sono probabilmente due cose diverse. Molto probabilmente la logica è:
"Perché devo pagare lo stipendio di un tester quando posso semplicemente fare in modo che il programmatore faccia il doppio dovere?"

Naturalmente, non lo diranno e inventeranno ogni sorta di scuse che ritengono ragionevoli. Posso pensare a diverse confutazioni al loro punto, ma onestamente non aiuteranno. Ho visto questa battaglia ancora e ancora e cambieranno il loro approccio ogni volta che annulli il loro attuale ragionamento. Alla fine si arrenderanno e ti diranno semplicemente di farlo comunque e verrai etichettato come lamentatore.

L'approccio migliore che mi viene in mente è quello di affrontarlo non da un punto di vista della qualità, che il management non sembra mai valutare fino a quando non ci sono problemi, ma da un punto di vista dei costi. I tester sono, o almeno sono percepiti come, meno costosi dei programmatori. Ricorda loro che facendo il doppio dovere stanno pagando una risorsa più alta (programmatore) per svolgere il lavoro che potrebbe essere realizzato da una risorsa meno costosa (tester). Quindi non stanno massimizzando il valore che stanno estraendo dalla tua abilità di programmazione.

Questo approccio ha il rovescio della medaglia di cadere a pezzi se sei stipendiato e non hanno lamentele sul fatto di farti lavorare più non pagati negli straordinari, ma vale la pena provare.

Il sistema in questione è grande ma è sviluppato esclusivamente da me. Ciò ha causato anche alcune funzioni manageriali che mi cadevano in grembo, come la definizione dei programmi e il lavoro sulle specifiche.

Giusto.

Questo tipo di compiti dovrebbe essere la mia responsabilità?

Alla fine spetta al tuo management decidere.

Mi vedo rigorosamente come programmatore e nient'altro.

Forse allora hai sbagliato lavoro. A molte persone piace avere la responsabilità extra.

E se queste sono le mie responsabilità, fino a che punto?

Se la direzione lo dice, sì.

Quando un progetto è così grande da richiedere tester?

Quando c'è troppo altro lavoro che gli sviluppatori devono fare. A quel punto, i dirigenti devono decidere se vogliono impiegare un tester dedicato o correre il rischio di lesinare sui test. (In definitiva, gli sviluppatori possono fare solo così tanto.)

Ci sono vantaggi evidenti nell'avere tester dedicati, ma ci sono anche degli svantaggi ... oltre al costo di impiegare personale extra.

Se un programmatore dovesse perfezionare le specifiche,

Se necessario, sì. In effetti, se le specifiche devono essere perfezionate e nessun altro ci sta lavorando, è probabile che il mancato rispetto di ciò causi il fallimento del progetto.

preoccuparsi della gestione del progetto

Se necessario, sì.

o addirittura fornire assistenza clienti?

Se necessario, sì.

Mi sembra che tu sia oberato di lavoro e che reagisca alla pressione. Questo è un problema. Ma assumere la posizione che "non è il tuo lavoro fare X, Y, Z" non ti aiuterà. Un piano migliore è quello di chiarire che c'è solo così tanto da fare e sottolineare che è probabile che ciò comporti il ​​mancato rispetto delle scadenze, il mancato rispetto della qualità, uno scarso supporto clienti e così via. Ma fai comunque del tuo meglio ... senza danneggiare la salute, le relazioni, ecc. Nel processo.

Abbiamo tester. Non vorrei lavorare senza di loro. Sebbene scrivo unit test (usando TDD) e test di integrazione automatizzati per tutto il mio codice, i tester hanno ancora una funzione molto preziosa.

1. Sono altamente qualificati e hanno competenze diverse dai programmatori.
   1. Hanno molta esperienza e conoscenza su come eseguire i test di controllo qualità e su come verificare che il codice prodotto corrisponda realmente sia alle aspettative dell'utente sia al comportamento effettivo degli utenti.
   2. Hanno riscontrato molti bug e sono molto bravi a pensare a situazioni che potrebbero danneggiare il software.
   3. Tendono ad essere cinici e sistematici. Ho osservato che i programmatori sono spesso molto più ottimisti.
2. Forniscono un prezioso feedback iniziale sull'usabilità. Ad esempio, durante la creazione recente di un'API REST, le aree che i tester QA non sono in grado di comprendere facilmente sono una buona indicazione delle aree che l'utente non sarebbe soddisfatto.
3. Testano sull'ambiente reale, in effetti molte configurazioni del vero hardware, sistema operativo, ecc.
4. Sanno come costruire banchi di prova su larga scala, realistici, e test di prestazioni, carico e stress
5. Si concentrano sulla prevenzione dell'uscita di cattive uscite. I programmatori tendono a concentrarsi sul rilascio del codice. È quasi come se un programmatore rilascerà il codice per impostazione predefinita, ma un tester QA avrà bisogno di un motivo per rilasciarlo (è stato dimostrato che funziona!)

"se avessimo dei tester, non testeresti affatto il tuo codice"

" Se la tua auto avesse una cintura di sicurezza, la faresti schiantare continuamente! "

Questo tipo di compiti dovrebbe essere la mia responsabilità? [...] E se queste sono le mie responsabilità, fino a che punto?

La risposta è "dipende". Da quello che ho capito, i tuoi datori di lavoro ti vedono come il "dipartimento IT one-man". In tal caso, sì, lo sono (la tua responsabilità). Se hai responsabilità che odi assolutamente e desideri evitare, cerca una posizione all'interno di un'azienda con un reparto IT più ampio.

Quando un progetto è così grande da richiedere tester?

Non è (abbastanza) una domanda corretta da porre. È meglio chiedere "quando è la qualità del prodotto / immagine dell'azienda così importante da richiedere tester?"

Se un programmatore dovesse perfezionare le specifiche, [...]

Sì, sicuramente. La maggior parte delle volte esiste una grande discrepanza tra ciò di cui uno sviluppatore / implementatore ha bisogno e ciò che i clienti forniscono [come specifiche].

Molte volte spetta a te trovare aree grigie / non specificate e porre le domande giuste, notare e indicare requisiti tecnicamente impossibili o contraddittori e così via (specialmente se sei l'unico sviluppatore).

[...] preoccuparsi della gestione del progetto o addirittura fornire assistenza ai clienti?

Dipende dalle responsabilità che hai accettato quando hai preso la posizione. Ad esempio, alcune posizioni richiedono di rivolgersi direttamente ai clienti. A parità di altre condizioni, tenterei di evitare tali posizioni (ma dipende da te e potresti non avere molte scelte di lavoro).

Prima di tutto, testare, o meglio dire Quality Assurance, non è solo testare la funzionalità facendo clic sull'applicazione. La garanzia della qualità riguarda i processi . Non solo per testare l'applicazione per trovare gli errori, devono anche impedire agli sviluppatori di eseguirli.

1. Specifiche del prodotto + casi d'uso
   Anche se tutti sanno (o pensano di fare) qual è la funzionalità del prodotto, deve essere scritto. Non è possibile testare un'applicazione senza una specifica chiara. Una specifica definisce cos'è il comportamento corretto e cos'è un bug.
2. Test unitari, test di integrazione
   Test degli interni difficili da testare nell'interfaccia utente, stati di applicazione eccezionali. Questo è un must per ogni sistema più grande. Entrambi i tipi di test hanno anche un'altra proprietà interessante: ti costringono a ripassare ogni parte del codice e ti accorgerai di bug / problemi di architettura che non hai mai visto prima.
3. Qualità del codice e standard di codifica
   Uno dei compiti che il QA dovrebbe fare è misurare la complessità del codice. Il codice a bassa complessità riduce la possibilità di errori (prevenzione dei bug).
4. Revisioni del codice
   Quando un progetto raggiunge una determinata dimensione o viene utilizzato da molti utenti, le revisioni del codice sono indispensabili. Un altro programmatore trova sempre problemi di codice / bug che hai perso. I programmatori sono talvolta ciechi rispetto a evidenti bug nel proprio codice.
5. Documentazione
   Documenta il tuo codice e la sua architettura, ti aiuterà a realizzare possibili difetti (la mia esperienza).
6. Testers
   Tester non è una scimmia che fa semplicemente clic sull'interfaccia utente. Un tester prende le specifiche e utilizza i casi e crea casi di test. Quindi li verifica uno per uno. Se viene segnalato un bug dagli utenti finali, è necessario aggiungere un caso di prova.

Un programmatore non dovrebbe mai creare la specifica (1). Non sei lì per decidere la funzionalità. Di solito devono parlare con gli utenti finali, creare progetti grafici ecc. È un compito che richiede tempo. Se un programmatore decide la funzionalità, di solito finisce con "è okey ma potresti cambiare tutto in questa finestra entro domani?" "questo non è quello che volevo" "funziona ma è difficile da usare" "manca l'unica funzionalità di cui avevamo veramente bisogno".

Ciò che un programmatore può ottenere è 2, 3 e 5.

È necessario un altro programmatore per 4. Qualsiasi azienda con un grande progetto IT e un solo sviluppatore che conosce i passi del sistema su un terreno molto pericoloso.

Se non hai abbastanza tempo, non preoccuparti mai di creare casi di test (5). Di solito è necessaria una persona dedicata poiché richiede molto tempo. Senza casi di test, il test è solo uno scherzo.