Credi sia una buona idea che gli ingegneri del software debbano lavorare come tecnici dell'assicurazione della qualità per un certo periodo di tempo? [chiuso]

1. I've encountered many Software Engineers who believe they are somehow superior to QA engineers. I think it may help quench this belief if they do the job of a QA engineer for some time, and realize that it is a unique and valuable skill-set of its own.

Una buona ingegneria del software ha un background di qualità, inclusi test, metriche e statistiche. Chiunque faccia qualsiasi tipo di sviluppo del software dovrebbe essere consapevole (se non ha familiarità con) di mantenere il codice sorgente di qualità e produrre / mantenere casi di test efficaci. Nel corso del tempo, sospetterei che qualsiasi sviluppatore di software acquisisca una comprensione dei diversi aspetti della qualità: qualità del codice, portabilità, manutenibilità, testabilità, usabilità, affidabilità, efficienza e sicurezza.

Gli ingegneri del software potrebbero concentrarsi su un aspetto particolare del ciclo di vita: ingegneria dei requisiti, architettura e progettazione, costruzione, test e manutenzione. Tuttavia, indipendentemente dal tuo focus (sia come lavoro che nella fase attuale del progetto), è importante ricordare la qualità.

2. The better a Software Engineer is at testing their own programs, the less cost in time their code incurs when making its way through the rest of the software development life-cycle.

Potrebbe essere vero. Ma alcuni problemi sono meglio visti più avanti nello sviluppo. Ad esempio, problemi di prestazioni ed efficienza potrebbero non essere visti fino all'integrazione. Avere un buon codice solido e test unitari efficaci sono solo l'inizio. La qualità deve iniziare con i requisiti e seguire tutte le fasi delle attività di manutenzione.

3. The more time a Software Engineer spends thinking about how a program can break, the more often they are to consider these cases as they are developing them, thus reducing bugs in the end product.

Questa è una dichiarazione assolutamente vera. Ma ancora una volta, spetta anche agli ingegneri dei requisiti verificare che non ci siano conflitti nei requisiti, architetti che garantiscano che il design risponda effettivamente ai requisiti e così via. Tutti dovrebbero provare a fare buchi nel loro lavoro e poi lavorare con le persone appropriate per sigillarli in modo bello e stretto.

4. A Software Engineer's definition of "complete" is always interesting...if they have spent time as a QA engineer maybe this definition will more closely match the designer of the software's.

"Completo" può essere misurato solo in base ai requisiti. O i requisiti sono soddisfatti e il progetto è completo, oppure ci sono requisiti incompleti e il progetto non è completo. Qualsiasi altra misura di completamento è inutile.

Rendere i programmatori responsabili per il loro codice e richiedere loro di correggere i propri bug può prendersene cura. Quello e una perdita di bonus e / o lavoro.

Non che questa esperienza non sarebbe di aiuto, ma fino a che punto si può andare con questa linea di pensiero? Supporto tecnico, Vendite, Utente Beta, pulizia dei servizi igienici (sarebbe un'esperienza umiliante).

"... devono lavorare come ingegneri del controllo qualità ..."? Lo fai sembrare contraddittorio o punitivo.

Sono uno sviluppatore di software. Considero parte del mio lavoro anche un ingegnere di QA, anche se abbiamo un dipartimento di QA. Il mio compito è quello di fornire software che realizzi determinate cose e, per farlo, devo scrivere test unitari e assicurarmi che il software li superi.

Sono in partnership con il nostro dipartimento QA. Il mio obiettivo è quello di rendere più facile il loro lavoro, proprio come il loro lavoro è quello di aiutarmi a raggiungere il mio obiettivo di fornire software che fa quello che dovrebbe, rendendo così la mia vita più facile. Li considero il mio secondo set di occhi e in qualche modo una rete di sicurezza, proprio come faccio con i miei test unitari.

Ho scelto di sviluppare software e di sviluppare software. Se un manager venisse da me e mi avesse detto che non potevo farlo e che dovevo fare QA, direi loro che hanno bisogno di trovare un nuovo sviluppatore software E una persona di controllo qualità perché non lavorerò lì. Sono anale come può essere con il mio codice, ma il processo creativo e la programmazione puzzle / sfida sono estremamente importanti per me. Preferirei tornare ai carrelli elevatori se non riesco a scrivere codice perché stare in un ambiente aziendale senza il vantaggio di essere creativo e di essere sfidato come me sarebbe un vero inferno per me.

In generale le opzioni che presenti sono molto contraddittorie e mi chiedo se hai avuto esperienze davvero brutte con alcuni sviluppatori terribili. Nella mia mente, uno sviluppatore deve SEMPRE essere a conoscenza di problemi di qualità e test e dovrebbe essere abbastanza orgoglioso del proprio lavoro da non ritenerlo finito fino a quando non passerà come test rigorosi nei test delle unità come verrà utilizzato dal dipartimento di controllo qualità ufficiale. Se avessi un pari, o avessi un ruolo chiave in una squadra e avessi uno sviluppatore che mostrasse "tude" nei confronti della QA, mi avrebbe trovato a trascinarlo per una correzione di atteggiamento. Se entrambi i lati della moneta di consegna del software non possono cooperare e agire come una squadra, c'è un vero problema culturale. Non vorrei lavorare lì e le risorse umane, insieme al management superiore, dovrebbero essere tenute in considerazione.

Fare in modo che i programmatori lavorino come tecnici del controllo qualità è una ricetta per perdere i tuoi migliori sviluppatori. La programmazione e la verifica della qualità richiedono diversi set di abilità e processi di pensiero.

Tuttavia, è importante che i programmatori siano esperti nell'arte di testare e validare il proprio lavoro prima di trasmetterlo al team addetto al controllo qualità. Gli sviluppatori e QA hanno accesso a diversi strumenti, conoscenze e competenze. Gli sviluppatori devono essere esperti nel passaggio attraverso il loro codice alla ricerca di comportamenti imprevisti, test di unità per condizioni diverse, stress del codice filettato alla ricerca di condizioni di gara ecc. Ad esempio, test dal punto di vista dello sviluppatore.

Il controllo qualità fa i loro test dal punto di vista dell'utente. Pensare come diversi tipi di utenti, inventare strani casi limite e rendere riproducibili problemi oscuri sono le abilità di QA.

Non necessariamente: sia i programmatori che i tester devono possedere competenze diverse. Solo perché sei un buon programmatore non significa che puoi essere un buon tester (molte persone non lo capiscono, ma essere un programmatore non ti qualifica automaticamente come tester).

Un grande tester deve possedere abilità veramente diaboliche, essere in grado di fare cose che il software non è stato progettato per fare, ma può aspettarsi che l'utente faccia nel mondo reale. Ciò richiede abilità, pazienza, capacità di vedere cosa può andare storto dove, una comprensione della mentalità dell'utente e di tanti altri fattori.

Nota che uso le parole programmatore e tester - ma se sei un ingegnere del software e non hai ancora deciso se vuoi essere un programmatore o un tester, allora comprende entrambe queste cose e quindi sì, dovresti avere esperienza in entrambi almeno nei primi anni della tua vita prima di prendere la decisione.

Questo non significa che prendi un programmatore esperto e fallo testare per un po 'solo per fargli capire quanto duramente lavorano gli ingegneri del controllo qualità.

Ecco alcuni potenziali problemi che vedo con la tua proposta:

1) Se stai suggerendo che avresti messo ingegneri software nuovi sul campo nel reparto QA per un breve periodo, non avremmo solo l'effetto opposto? - possono presumere che il QA sia qualcosa che fai quando sei un principiante e non capisci cosa stai facendo - dopotutto, è così che ha funzionato per loro.

2) Essere un cattivo valutatore per un po 'non insegnerà loro nulla di utile. Ma potrebbe renderli non più accessibili in seguito, perché presumerà che sanno tutti dei test ora, perché hanno trascorso 6 settimane in un reparto test una volta.

3) Dato che ovviamente saranno lì solo per un breve periodo, e il dipartimento di QA lo saprà, è anche probabile che gli verranno assegnati compiti relativamente poco impegnativi che richiedono poca supervisione o comprensione, ma che tenerli occupati. Ciò rafforzerà solo 1 e 2.

4) Se vuoi evitare 1, 2 e 3, come convincerai il reparto test che vale la pena investire un'enorme quantità di energia nell'insegnare e supervisionare qualcuno che non è nemmeno interessato ai test? (Posso dirti, ci vuole una quantità spaventosa di tempo ed energia per lavorare con qualcuno che, ricordiamoci, non è stato scelto per la loro attitudine ai test . risorsa per alcune settimane, stai chiedendo loro di perdere una delle persone più esperte per alcune settimane, mentre insegnano al tuo principiante).

Detto questo, penso che il tuo obiettivo generale - aumentare la comprensione dei test sui nuovi programmatori di software - sia davvero fantastico. Penso che il suggerimento di Greg sia più probabile che raggiungerlo comunque - ottieni il tuo dev & I team di QA collaborano a stretto contatto e lavorano per abbattere eventuali ostacoli tra le squadre. (Attualmente sto lavorando in un'azienda in cui tester e programmatori sono nella stessa squadra: è davvero eccezionale e non voglio mai tornare a lavorare in team separati.)

Se hai ancora voglia di far fare ai programmatori un periodo di prova in AQ, ecco un suggerimento: dare l'esempio. Vai prima tu. Forse trasformarlo in qualcosa che i membri del tuo team possono fare quando sono già bravi, e vuoi ottenere quel vantaggio in più, spendendo un po 'di tempo ogni settimana con altri team specializzati in aree sovrapposte: test, DBA, ecc. lo presenti così, quindi avrai più possibilità di successo.

Ho avuto una sorta di percorso di carriera che è un po 'l'inverso di quello che normalmente vedi. Ho iniziato come supporto software per la fisica scientificamente impegnativa, finì per lavorare nel intersezione di architettura, programmazione e algoritmi per un'azienda di computer. Dopo quello che è successo mi ha fatto ottimizzare le prestazioni di un importante codice tecnico per diversi anni, ma anche quel lavoro è finito. Ora, che mi sto avvicinando all'età della pensione, sto facendo QA sullo stesso codice. È una combinazione di sfida e duro lavoro. Abbiamo un nuovo ragazzo molto acuto che lavora al 100% sulle correzioni di bug e trascorro molto lavoro con lui. È una posizione stimolante e puoi imparare molto a farlo. A questo punto il mio interesse principale per lo sviluppo professionale è per i miei gemelli, che sono matricola del college. Quindi ho un nuovo interesse nell'apprendimento (o nel riapprendimento) di cose che saranno rilevanti per la loro carriera, in particolare matematica applicata. Ho una prospettiva diversa delle cose ora che mi occupo di QA / validazione, mentre per il quarto di secolo precedente era velocità, velocità, velocità ad ogni costo.

Il test del software è il processo distruttivo piuttosto che costruttivo. Ma i programmatori pensano al loro prodotto costruttivo per garantire che il prodotto sia completato nei tempi e con il budget. Se lo sviluppatore del software pensa come distruttivo del proprio prodotto, chi sarà il prossimo a costruire il prodotto. Quindi ogni porzione del ciclo di sviluppo del software deve essere eseguita dalle persone assegnate in ciascuna parte del ciclo di sviluppo. Se sei impegnato in due o più campi, è sicuro che non sarai mai perfetto su nessuno di loro, quindi fai una cosa o programmatore o QA o qualsiasi altra opzione e sii perfetto su quello.