Un programmatore dovrebbe essere autosufficiente?

fai hai tester. Solo, li chiami "utenti finali". Questo è dannoso per tutte le ragioni che descrivi; non importa quanto sei un programmatore coscienzioso, semplicemente non sarai mai in grado di fare un buon lavoro superando i tuoi stessi preconcetti su come il "presunto" codice debba essere usato per trovare tutti i modi in cui può rovinare .

Devi riaprire questo problema con la gestione. A questo punto, sembra che tu abbia alcuni dati rigidi a supporto del tuo caso; l'attuale approccio "hands-off" all'assicurazione della qualità vi fa perdere tempo e e compromette l'esperienza dei vostri utenti. Devi fare attenzione a come lo presenti, in modo che sia chiaro che si tratta di un problema strutturale e non un caso di "Fai schifo a testare", ma suona come una discussione che deve accadere.

Sembra che tu stia arrivando a un bivio con questo datore di lavoro. Se sei intento a rimanere un programmatore e nient'altro, potresti dover ricominciare a spingere indietro e chiedere di iniziare a ricevere l'aiuto necessario per portare a termine alcuni dei compiti manageriali, inserendo qualcuno di nuovo o ampliare le responsabilità di un collega esistente. ("Questo non è quello per cui mi hai assunto, e questi compiti non stanno andando via. Il tempo che passo a fare queste cose male è il tempo in cui sono non a spendere su ciò in cui sono bravo. ") Ma potrebbe essere o non essere realistico. Pensi di riuscire a passare a un ruolo più manageriale se ti fornissero le risorse e l'autorità necessarie per svolgere correttamente il lavoro?

Riguardo a quanto deve essere grande un progetto prima che abbia bisogno di tester, non sono sicuro di come definire precisamente quella linea, ma sicuramente penso che tu l'abbia superato. Stai spendendo più tempo di quanto desideri per correggere i bug che arrivano da utenti reali; per me questo dice che è il momento di dedicare più tempo a fermare gli errori prima di arrivare agli utenti.

Sì. Se hai , 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 migliori nei test di quello che sei. E come fai notare, proprio come la correzione di bozze, è molto difficile individuare i propri errori. Avere bulbi oculari extra avrà un importante (buono) impatto sulla qualità del tuo programma.

Hai un sacco di altre domande. Ne risponderò solo una:

Un programmatore deve ridefinire le specifiche?

Sì! Devi implementare le specifiche, quindi devi assicurarti che le specifiche siano effettivamente implementabili. Inoltre, in qualità di programmatore, formato in modo chiaro, con precisione e così via, puoi aiutare le persone a scoprire ciò che è effettivamente necessario fare e eliminare i requisiti ambigui o logicamente imperfetti.

Ciò 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 fare in modo che il programmatore esegua il doppio lavoro?"

Naturalmente, non lo diranno e trarranno ogni sorta di scuse che ritengono ragionevoli. Posso pensare a diverse confutazioni al riguardo, ma sinceramente non aiuteranno. Ho visto questa battaglia più e più volte e cambieranno il loro approccio ogni volta che decifri il loro ragionamento corrente. Alla fine si arrenderanno e ti dirigeranno a farlo comunque e sarai etichettato come un lagnè.

L'approccio migliore che riesco a pensare è quello di affrontarlo non da un punto di vista della qualità, che la gestione sembra non apprezzare fino a quando non ci sono problemi, ma dal punto di vista dei costi. I tester sono, o almeno sono percepiti come, meno costosi dei programmatori. Ricorda loro che, facendo doppio lavoro, pagano una risorsa più alta pagata (programmatore) per fare il lavoro che potrebbe essere svolto 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 alcuna complicazione riguardo al fatto di farti lavorare più straordinari non pagati, ma vale la pena provare.

The system in question is large but is developed solely by me. This has also caused some managerial duties to fall on my lap, such as defining schedules and working on specifications.

Giusto abbastanza.

Should these kind of tasks be my responsibility?

In definitiva, è compito della tua direzione decidere.

I see myself strictly as a programmer and nothing else.

Allora forse hai sbagliato lavoro. A molte persone piace essere data la responsabilità extra.

And if these are my responsibility, to what extent?

Se la direzione lo dice, sì.

When is a project so large that it requires testers?

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

Ci sono indubbi vantaggi nell'avere tester dedicati, ma ci sono anche aspetti negativi ... oltre al costo di impiegare personale extra.

Should a programmer have to refine the specification,

Se necessario, sì. In effetti, se le specifiche richiedono un perfezionamento e non c'è nessun altro che ci lavori, allora l'impossibilità di farlo potrebbe far fallire il progetto.

worry about management of the project

Se necessario, sì.

or even provide customer support?

Se necessario, sì.

Mi sembra che tu sia oberato di lavoro e reagisci alla pressione. Questo è un problema. Ma prendere la posizione che "non è il tuo lavoro da fare X, Y, Z" non sarà di aiuto. Un piano migliore è quello di chiarire che c'è solo così tanto che puoi fare, e sottolineare che questo potrebbe far perdere le scadenze, la qualità di scivolare, l'assistenza clienti scadente e così via. Ma fai del tuo meglio comunque ... senza danneggiare la tua salute, le relazioni, ecc. Nel processo.

Abbiamo dei tester. Non vorrei lavorare senza di loro. Sebbene io scriva test unitari (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 per i programmatori.
   1. Hanno molta esperienza e conoscenza su come eseguire il test del QA e su come verificare che il codice prodotto sia realmente all'altezza delle aspettative dell'utente e del comportamento effettivo degli utenti.
   2. Hanno subito molti bug e sono molto bravi a pensare a situazioni che potrebbero rompere il software.
   3. Tendono ad essere cinici e sistematici. Ho osservato che i programmatori sono spesso molto più ottimisti.
2. Forniscono preziosi feedback precoci sull'usabilità. Ad esempio, durante la creazione di un'API REST di recente, le aree che i tester del QA non erano in grado di comprendere facilmente erano una buona indicazione di aree di cui l'utente sarebbe anche insoddisfatto.
3. Testano l'ambiente reale, in effetti molte configurazioni dell'hardware reale, del sistema operativo, ecc.
4. Sanno come costruire test su misura su larga scala e realistici, eseguire test di prestazioni, carico e stress
5. Sono focalizzati sulla prevenzione delle cattive uscite dall'uscita. I programmatori tendono a concentrarsi sul rilascio del codice. È quasi come, un programmatore rilascerà il codice per impostazione predefinita, ma un tester di QA avrà bisogno di un motivo per rilasciarlo (è stato dimostrato che funziona!)

"if we had testers, you wouldn't test your own code at all"

" Se la tua auto avesse una cintura di sicurezza, la romperai tutto il tempo! "

Should these kind of tasks be my responsibility? [...] And if these are my responsibility, to what extent?

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

When is a project so large that it requires testers?

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

Should a programmer have to refine the specification, [...]

Sì, sicuramente. Nella maggior parte dei casi, vi è una grande discrepanza tra ciò di cui uno sviluppatore / implementatore ha bisogno e ciò che i client 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).

[...] worry about management of the project or even provide customer support?

Dipende dalle responsabilità che hai accettato quando hai assunto 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 opzioni di lavoro).

Prima di tutto, il test o, meglio, la garanzia della qualità, non si limita a testare la funzionalità facendo clic sull'applicazione. La garanzia della qualità riguarda i processi . Non solo per testare l'applicazione per trovare gli errori, ma anche per impedire agli sviluppatori di eseguirli.

1. Specifiche del prodotto + casi d'uso
   Anche se tutti sanno (o pensano di farlo) quale sia la funzionalità del prodotto, devono essere annotati. Non è possibile testare un'applicazione senza una specifica chiara. Una specifica definisce qual è il comportamento corretto e cos'è un bug.
2. Test unitari, test di integrazione
   Test degli interni che sono difficili da testare attraverso l'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 esaminare ogni parte del codice e ti renderai conto di problemi di bug / architettura che non hai mai visto prima.
3. Qualità del codice e amp; 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 (impedendo bug).
4. Recensioni 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 ti erano sfuggiti. I programmatori sono a volte ciechi per ovvi bug nel proprio codice.
5. Documentazione
   Documenta il tuo codice e la sua architettura, ti aiuterà a capire i possibili difetti (la mia esperienza).
6. Tester
   Tester non è una scimmia che fa semplicemente clic sull'interfaccia utente. Un tester prende le specifiche & utilizzare i casi e creare casi di test. Poi li mette alla prova uno per uno. Se un bug viene segnalato dagli utenti finali, deve essere aggiunto un test case per questo.

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'attività 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ò raggiungere è 2, 3 e 5.

Hai bisogno di un altro programmatore per 4. Qualsiasi azienda con un grande progetto IT e un solo sviluppatore che conosce i passaggi 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é ci vuole un sacco di tempo. Senza test case, test è solo uno scherzo.