Mi è capitato di conoscere qualche amministratore di sistema e, secondo lui, ai test non vengono date preferenze in un'organizzazione rispetto agli sviluppatori. Non c'è dubbio che le versioni software non siano possibili senza tester, ma non ho mai messo le mani sui test quindi non ne sono molto consapevole. Senza offesa intesa.
Nella mia esperienza, sfortunatamente, sono spesso trattati come impiegati di seconda classe e ancora peggio per i programmatori con un frivolo perk.
Deriva da una serie di cose:
Quando i tester stanno facendo il proprio lavoro correttamente, è facile per tutti, tranne i programmatori, dimenticare che esistono persino. Proprio come un amministratore di rete, li noti solo quando non stanno facendo il loro lavoro o li fanno male. Quindi dal punto di vista del resto dell'organizzazione, vengono ricordati solo per i loro errori.
Viene erroneamente visto come un lavoro entry-level per le persone che aspirano a diventare programmatori, ma non sono ancora qualificati per quei lavori. In effetti, in una società in cui lavoravo, gli erano stati dati dei titoli di lavoro per programmatori Jr. nonostante le loro richieste di ottenere un Q & un titolo di lavoro. Anche il fatto che si trovassero in un dipartimento di QA non è stato sufficiente a far sì che le risorse umane si trasferissero in quella direzione.
A causa del n. 2, si presume che i tester siano tutti di livello base e dovrebbero essere pagati di conseguenza.
A nessuno piace essere criticato, ed è fin troppo comune che i programmatori difensivi non amano i tester perché il loro lavoro richiede loro di segnalare errori del programmatore per tutto il giorno. Come dirigente, ero costantemente impegnato in una missione di pubbliche relazioni per ricordare ai programmatori che il team addetto al controllo qualità era lì per farli apparire belli, non per stupirli.
Tende ad essere un lavoro che le persone subiscono per caso e non una scelta, almeno inizialmente. Non ricordo alcun piano di laurea in nessuna delle scuole che ho frequentato che preparasse le persone per il software Q & A. Esistono, ma di solito nelle scuole professionali di fascia bassa, che contribuiscono solo all'idea di essere dei professionisti meno esperti.
I test di posti di lavoro sono molto più probabili rispetto alla programmazione dei lavori da inviare al largo. Almeno i programmatori possono sostenere che è più efficiente comunicare le esigenze di progettazione a livello locale e che è prezioso mantenere la conoscenza di come funziona l'app di punta dell'azienda all'interno dell'azienda. I test, tuttavia, sono molto più semplici da modulare e quindi più facili da esternalizzare.
Per tutte le ragioni sopra esposte, i tester tendono a vedere la scritta sul muro e a spostarsi in altri lavori (come la programmazione), specialmente quelli veramente buoni. Ciò significa che la maggior parte dei lavori di testing tendono a ricevere personale con un numero sempre maggiore di persone che non si sono ancora esaurite o trasferite ad altre cose, cosa che purtroppo rafforza molte delle idee di cui sopra.
Dipende dalla compagnia, ma di solito. Sono spesso visti come cittadini di seconda classe, e in molte aziende, il testing è visto come una posizione entry-level da cui poi passeresti a diventare un vero sviluppatore.
Questa è, ovviamente, merda. Avendo lavorato con alcuni bravi tester, posso dire che sono entrambi preziosi e difficili da trovare. Qualcuno con una mente abbastanza creativa da trovare bug non ovvi e abbastanza metodici da fare un lavoro completo.
Un'eccezione, tuttavia: ho conosciuto alcuni test di Microsoft e ho sentito che i tester sono cittadini di prima classe.
Ho lavorato come tester funzionale per un anno su un progetto abbastanza grande. Ogni squadra di circa 10 membri aveva 2-3 testimoni. Devo dire che siamo stati trattati come ugualmente importanti per il progetto come gli sviluppatori.
Trovare bug non è facile. Innanzitutto, i tester devono capire che cosa dovrebbe fare il codice. Ciò significa leggere e comprendere i requisiti. La chiave qui è capire i requisiti: se i tester non sono in grado di comprendere i requisiti abbastanza bene da sapere come scrivere casi di test positivi, dovresti essere preoccupato. Ciò significa che gli sviluppatori hanno scritto del codice che fa quello che hanno pensato di fare. Questa assunzione è quella giusta? Non lo sai finché non hai risolto i requisiti e puoi ringraziare i tuoi tester per aver trovato quel difetto.
In secondo luogo, i tester devono scrivere casi di test falsi, il che garantisce che il codice non non sia quello che non dovrebbe fare. Una ragionevole regola empirica è che scrivi 5-10 casi di test falsi per ogni caso di test positivo. Ciò significa comprendere ulteriormente i requisiti, e spesso questa informazione è, o almeno era nel nostro progetto, confusa e ambigua. (E non è stato per il basso sforzo nel raccogliere i requisiti - abbiamo avuto qualcosa come 13.000 nel nostro team da soli.) Ancora una volta, gli sviluppatori avranno scritto il loro codice usando le loro ipotesi, o anche peggio, nemmeno preso in considerazione questo. Quindi cosa fa il codice in queste condizioni che non sono normali? Non lo sai finché non lo hai testato. Forse il programma non risponde; forse si blocca solo; forse distrugge i dati; forse consente all'utente di eseguire comandi come utente root. Qualunque cosa faccia, vuoi sapere. Altrimenti potresti trovarti a leggere il seguente titolo sul giornale un giorno - INSERISCI IL PROGRAMMA FLAGSHIP DI BUG IN [IL TUO NOME DELLA TUA AZIENDA SCENDE I NUMERI DI CARTE DI CREDITO DEI CLIENTI. Puoi ringraziare i tuoi tester se ciò non avviene accadere.
Quindi tratta bene i tuoi tester. Trattali bene. Dopotutto, sono loro a sradicare gli errori nel software e a rendere la tua e la nostra vita più facile.
I buoni tester che possono analizzare i problemi in modo efficiente e possono fare un'autentica automazione dei test valgono il loro peso in oro, dato che ci sono così tanti cowboy tester (quando intervistano un "tester" una volta che scoppia a ridere mentre si rende conto che sapevamo stava facendo le cose sul posto mentre veniva interrogato sul suo CV).
Nella mia squadra il tester è trattato come un pari - che include responsabilità e salario. Se vuoi un tester che fa clic su tutto il giorno, esternali a un prezzo inferiore (lo facciamo anche noi).
Aggiornamento dopo aver letto altre risposte: Ci sono molti professionisti della QA che amano il lavoro che fanno. Solo per dare un'altra prospettiva se non si sono imbattute in posizioni di controllo qualità rispettate, un esempio qui: App integrate / test delle app mobili per i principali produttori di automobili. Si assicurano che i requisiti aziendali siano completamente soddisfatti prima che un veicolo venga immesso sul mercato e nessun utente sperimenta un cruscotto dell'automobile lento o poco reattivo. Lavorano a stretto contatto con i dirigenti e la gestione di livello superiore, e anche gli sviluppatori a partire dalla pianificazione del processo di controllo qualità per vivere test pratici sui simulatori nella struttura di progettazione. Non riesco a pensare che siano di basso profilo, gestiscono enormi responsabilità e titolarità e sono tra i migliori ingegneri.
ora la mia risposta precedente, il rovescio della medaglia:
Ho osservato che i laureati in ingegneria odiano essere assegnati a unità di test (contesto: India, grandi aziende di servizi software in cui tutto è guidato da "requisiti aziendali"), poiché lo considerano un ambiente di lavoro non tecnico. Vengono forniti fogli di Excel con istruzioni come "fai clic su tutti i link nella pagina web e verifica", sono costretti a lavorare con i laureati da flussi non tecnici (scienze, arte) che considerano un'umiliazione e si sentono come se le loro abilità tecniche non fossero utilizzato. Queste allocazioni sono puramente basate sui requisiti dell'organizzazione e una maggior parte del tempo, più fresco, non ha il potere di negoziare il suo percorso professionale. Quindi se sei un cercatore di lavoro che mira a una grande azienda IT, sei stato avvisato. Non puoi fare molto, praticamente, tranne uscire dalla compagnia al momento giusto.
A meno che non ci siano opportunità di apprendere test automatici, test di carico / prestazioni ecc., la carriera è stagnante. Personalmente so che le opportunità per incarichi in loco (= un sacco di soldi da un punto di vista del programmatore offshore) sono più per testare l'unità nella mia organizzazione rispetto a qualsiasi altra unità. Funzionano con tutti i settori verticali come riempitivi o colla, poiché la verifica è inevitabile nei progetti in tutti i domini.
Se sei sicuro di poter guidare la tua carriera come vuoi, il test non è niente di basso profilo. Con 4-5 anni di esperienza e un po 'di fortuna puoi ottenere un'ottima esposizione, a volte interagendo con gli utenti aziendali di alto livello. Puoi anche avere una buona conoscenza del settore / dominio in cui lavori (rispetto a uno sviluppatore che si concentrerebbe principalmente su qualche parte del sistema). A questo punto si può scegliere di passare anche a un ruolo di analista aziendale.
Conosco società in cui il team addetto al controllo qualità è responsabile delle versioni. Ciò significa che hanno il potere di bloccare un rilascio a causa della mancanza di qualità. Se viene segnalato un problema nel campo, sono i primi nella linea di fuoco (bene dopo l'ingegnere sul campo).
In genere hanno una conoscenza di dominio superiore. Tendono a conoscere meglio la funzionalità complessiva del prodotto mentre gli sviluppatori si concentrano sul loro modulo / caratteristiche.
So anche delle organizzazioni di QA dove devono scrivere i propri strumenti di test. Per non parlare dell'automazione di tutto il materiale. Sono uno sviluppatore e ho sempre apprezzato i membri del QA che testano le mie funzionalità.
Almeno nella mia organizzazione, il controllo qualità è trattato allo stesso modo con gli sviluppatori. Penso che sia dovuto al dominio (telecom) in cui il protocollo e la conoscenza dell'architettura di rete sono ugualmente apprezzate con le competenze di programmazione.
Sì. Piace o lascia che siano ugualmente importanti ma sono sempre meno preferiti. Può essere perché sono facili da sostituire.
Leggi altre domande sui tag testing