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

Credo che sia. Perché?

1. Ho incontrato molti ingegneri del software che credono di essere in qualche modo superiori agli ingegneri del controllo qualità. Penso che possa aiutare a placare questa convinzione se fanno il lavoro di un ingegnere addetto al controllo qualità per qualche tempo, e si rendono conto che si tratta di un insieme di abilità unico e prezioso.

2. Meglio un ingegnere del software sta testando i propri programmi, minori saranno i costi nel tempo in cui il suo codice si fa strada durante il resto del ciclo di vita dello sviluppo del software.

3. Più tempo un ingegnere del software trascorre pensando a come un programma può rompersi, più spesso devono considerare questi casi mentre li stanno sviluppando, riducendo così i bug nel prodotto finale.

4. La definizione di "completo" di un ingegnere del software è sempre interessante ... se hanno trascorso del tempo come ingegnere addetto al controllo qualità, forse questa definizione corrisponderà più strettamente al progettista del software.

Nota: suggerisco sopra con un piccolo lasso di tempo in mente, poiché sono consapevole che qualcuno che lavora in una posizione che non è la posizione per cui sono assunti è sicuramente una ricetta per perdere quello sviluppatore.

Che ne pensate?

1. Ho incontrato molti ingegneri del software che credono di essere in qualche modo superiori agli ingegneri del controllo qualità. Penso che possa aiutare a placare questa convinzione se fanno il lavoro di un ingegnere addetto al controllo qualità per qualche tempo, e si rendono conto che si tratta di un insieme di abilità unico e prezioso.

Una buona ingegneria del software ha un background in termini di qualità, inclusi test, metriche e statistiche. Chiunque esegua qualsiasi tipo di sviluppo software deve essere consapevole (se non ha familiarità) mantenendo un codice sorgente di qualità e producendo / mantenendo casi di test efficaci. Con il passare del tempo, sospetterei che qualsiasi sviluppatore di software comprenda le diverse sfaccettature 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 dalla tua attenzione (sia come lavoro che nella fase corrente del progetto), è importante ricordare la qualità.

2. Meglio un ingegnere del software sta testando i propri programmi, minori saranno i costi nel tempo in cui il loro codice si presenta durante il resto del ciclo di vita dello sviluppo del software.

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

3. Più tempo un ingegnere del software trascorre pensando a come un programma può rompersi, più spesso devono considerare questi casi mentre li stanno sviluppando, riducendo così i bug nel prodotto finale.

È un'affermazione totalmente vera. Ma ancora una volta, spetta anche agli ingegneri dei requisiti verificare che non vi siano conflitti nei requisiti, gli architetti a garantire che il progetto risponda effettivamente ai requisiti e così via. Tutti dovrebbero cercare di creare buchi nel loro lavoro e quindi lavorare con le persone appropriate per sigillarli bene e in modo stretto.

4. La definizione di "completo" di un ingegnere del software è sempre interessante ... se hanno trascorso del tempo come ingegnere addetto al controllo qualità, forse questa definizione corrisponderà più da vicino al progettista del software.

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

Rendere i programmatori responsabili del proprio codice e richiedere loro di correggere i propri bug può occuparsene. Quello e una perdita di bonus e / o lavoro.

Non che questa esperienza non sarebbe di aiuto, ma fino a che punto puoi procedere con questa linea di pensiero? Supporto tecnico, vendite, utenti beta, pulire i bagni (sarebbe un'esperienza umiliante).

"... devono lavorare come ingegneri addetti al controllo qualità ..."? Lo fai sembrare contraddittorio o punizione.

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

Sono in collaborazione con il nostro dipartimento di controllo qualità. Il mio obiettivo è quello di semplificare il loro lavoro, così come il loro lavoro è aiutarmi a raggiungere il mio obiettivo di fornire software che faccia quello che dovrebbe, facilitando così la mia vita. Li considero la mia seconda serie di occhi e un po 'una rete di sicurezza, proprio come faccio i miei test unitari.

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

In generale, le opzioni che presenti sembrano molto contraddittorie e mi fanno pensare se hai avuto delle brutte esperienze con alcuni terribili sviluppatori. Nella mia mente, uno sviluppatore deve SEMPRE essere consapevole dei problemi di qualità e dei test e dovrebbe essere abbastanza orgoglioso del proprio lavoro da non considerarlo finito fino a quando non supererà test rigorosi nei test unitari come quello che utilizzerà il dipartimento ufficiale di controllo qualità. Se avessi un pari, o fossi responsabile tecnico di una squadra e avessi uno sviluppatore che mostrasse "tude" verso il QA, mi troverebbe a tirarlo fuori per una correzione dell'atteggiamento. Se entrambe le facce della medaglia di consegna del software non possono cooperare e agire come una squadra, c'è un vero problema di cultura. Non vorrei lavorare lì e le risorse umane, insieme all'alta direzione, dovrebbero essere informate.

Far lavorare i programmatori come ingegneri del QA è una ricetta per perdere i tuoi migliori sviluppatori. La programmazione e il QA richiedono diversi set di abilità e processi di pensiero.

Tuttavia, è importante che i programmatori siano esperti nell'arte di testare e convalidare il proprio lavoro prima di passarlo al team di controllo qualità. Gli sviluppatori e il QA hanno accesso a diversi strumenti, conoscenze e competenze. Gli sviluppatori devono essere abili nel passare in rassegna il loro codice alla ricerca di comportamenti imprevisti, test unitari per condizioni diverse, stressare il codice filettato alla ricerca di condizioni di gara ecc. Ad esempio test dal punto di vista dello sviluppatore.

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

Non necessariamente: sia i programmatori che i tester devono avere 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 per essere un tester).

Un grande tester deve avere abilità davvero 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 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.

Ciò non significa che prendi un programmatore esperto e lo fai testare per un po 'solo per fargli capire quanto duramente lavorano gli ingegneri del QA.

Ecco alcuni potenziali problemi che vedo con la tua proposta:

1) Se stai suggerendo di mettere gli ingegneri del software nuovi nel settore per un breve periodo, questo non avrà l'effetto opposto? - possono presumere che il QA sia qualcosa che fai quando sei un principiante e non capisci cosa stai facendo - dopo tutto, è così che ha funzionato per loro.

2) Essere un pessimo tester per un po 'non insegnerà loro necessariamente nulla di prezioso. Ma potrebbe renderli inattaccabili in seguito, perché presumeranno di sapere tutto sui test ora, perché hanno trascorso 6 settimane in un reparto di test una volta.

3) Dato che ovviamente saranno lì solo per un breve periodo, e il reparto QA lo saprà, è anche probabile che a loro vengano assegnati solo compiti relativamente poco impegnativi, che richiedono poca supervisione o comprensione, ma che li tengono occupati . Ciò rafforzerà solo 1 e 2.

4) Se vuoi evitare 1, 2 e 3, come convincerai il tuo reparto test che vale la pena investire un'enorme quantità di energia nell'insegnamento e nella supervisione di qualcuno che non è nemmeno interessato ai test? (Posso dirti che ci vuole una quantità spaventosa di tempo ed energia per lavorare con qualcuno che, ricordiamo, non è stato scelto per la sua attitudine al test . Non stai offrendo al team di test risorse aggiuntive per alcune settimane, tu stai chiedendo loro di perdere una delle persone più esperte per alcune settimane, mentre insegnano al tuo novizio).

Detto questo, penso che il tuo obiettivo generale - aumentare la comprensione dei test da parte dei nuovi ingegneri del software - sia davvero fantastico. Penso che il suggerimento di Greg abbia maggiori probabilità di realizzarlo comunque: fai collaborare strettamente i tuoi team di sviluppo e QA e lavora per abbattere qualsiasi barriera tra i team. (Attualmente sto lavorando in un'azienda in cui tester e programmatori fanno parte dello stesso team - è davvero fantastico e non voglio mai tornare a lavorare in team separati.)

Se desideri ancora che i programmatori facciano un periodo nel QA, ecco un suggerimento: dare l'esempio. Vai tu stesso per primo. Forse trasformalo in qualcosa che i membri del tuo team possono fare quando sono già bravi e vogliono ottenere quel vantaggio in più, trascorrendo un po 'di tempo ogni settimana con altri team specializzati in aree sovrapposte: test, DBA, ecc. Se lo presenti in questo modo, quindi avrai maggiori possibilità di successo.

Ho avuto un percorso di carriera che è un po 'l'inverso di ciò che normalmente vedi. Ho iniziato come supporto software per la fisica scientificamente stimolante, poi ho finito per lavorare nell'intersezione di architettura, programmazione e algoritmi per un'azienda informatica. Dopo di che sono finito ho fatto l'ottimizzazione delle prestazioni di un importante codice di ingegneria per diversi anni, ma anche quel lavoro è finito. Ora che mi sto avvicinando all'età pensionabile sto facendo il QA sullo stesso codice. È una combinazione di sfida e fatica. Abbiamo un nuovo ragazzo davvero acuto che lavora al 100% su correzioni di bug e spendo molto a lavorare con lui. È una posizione stimolante e puoi imparare molto facendolo. A questo punto il mio interesse principale per lo sviluppo professionale è per i miei gemelli, che sono matricola del college di scienze. Quindi ho un nuovo interesse per l'apprendimento (o il riapprendimento) di materiale che sarà rilevante per la loro carriera, in particolare per la matematica applicata. Ho una prospettiva diversa delle cose ora che mi occupo di QA / validazione, dove per il quarto di secolo precedente era la velocità, la velocità, la velocità ad ogni costo.

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