Mi è capitato di conoscere un po 'di amministratore di sistema e secondo lui, i ragazzi di prova non hanno preferenze in un'organizzazione rispetto agli sviluppatori. Senza dubbio le versioni del software non sono possibili senza i tester, ma non ho mai messo le mani sui test, quindi non ne sono molto consapevole. Nessuna infrazione prevista.
Risposte:
Nella mia esperienza, sfortunatamente, sono spesso trattati come impiegati di seconda classe e, ancor peggio, un vantaggio frivolo per i programmatori.
Deriva da una serie di cose:
Quando i tester svolgono correttamente il proprio lavoro, è facile per tutti, ma i programmatori dimenticano persino che esistono. Proprio come un amministratore di rete, li noti solo quando non svolgono il loro lavoro o se li fanno male. Quindi, dal punto di vista del resto dell'organizzazione, vengono ricordati solo per i loro errori.
È erroneamente visto come un lavoro entry-level per le persone che aspirano a essere programmatori, ma non sono ancora qualificati per quei lavori. In effetti, in una società in cui ho lavorato hanno ottenuto titoli di lavoro per Jr. Programmer, nonostante le loro richieste di ottenere un titolo per domande e risposte. Anche il fatto che fossero in un dipartimento di controllo qualità non era abbastanza per convincere le risorse umane a muoversi su questo.
A causa del n. 2, si presume che i tester siano tutti persone entry-level e debbano essere pagati di conseguenza.
A nessuno piace essere criticato, ed è fin troppo comune per i programmatori difensivi non amare i tester perché il loro lavoro richiede loro di segnalare gli errori del programmatore tutto il giorno. Come manager, 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 farli fuori.
Tende ad essere un lavoro che le persone intraprendono per caso e non per scelta, almeno inizialmente. Non ricordo alcun piano di laurea in nessuna delle scuole che ho frequentato che preparasse persone per domande e risposte sul software. Esistono, ma di solito nelle scuole professionali di fascia bassa, il che contribuisce solo all'idea di essere professionisti meno qualificati.
I lavori di prova sono molto più probabili dei lavori di programmazione da inviare in mare aperto. Almeno i programmatori possono sostenere che è più efficiente comunicare a livello locale le esigenze di progettazione e che è utile mantenere la conoscenza di come funziona l'app di punta dell'azienda all'interno dell'azienda. I test, tuttavia, sono molto più facili da modulare e quindi più facili da esternalizzare.
Per tutti i motivi di cui sopra, i tester tendono a vedere le scritte sul muro e passare ad altri lavori (come la programmazione), in particolare quelli veramente buoni. Ciò significa che la maggior parte dei lavori di collaudo tende ad assumere personale con un numero maggiore di persone entry level che non si sono ancora esaurite o sono passate ad altre cose, il 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 i test sono visti come una posizione entry-level da cui passeresti per diventare un vero sviluppatore.
Questa è, ovviamente, merda. Avendo lavorato con alcuni buoni tester, posso dire che sono entrambi preziosi e difficili da trovare. Qualcuno con una mente abbastanza creativa da trovare bug non ovvi e abbastanza metodico da fare un lavoro approfondito.
Un'eccezione, però: ho conosciuto alcuni ragazzi di test Microsoft e ho sentito che i tester ci 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 erano tester. Devo dire che siamo stati trattati come ugualmente importanti per il progetto come gli sviluppatori.
Trovare i bug non è facile. In primo luogo, i tester devono capire cosa dovrebbe fare il codice. Ciò significa leggere e comprendere i requisiti. La chiave qui è capire i requisiti - se i tester non riescono a capire 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 si aspettavano che facesse. Questo presupposto è quello giusto? Non lo sai fino a quando non hai risolto i requisiti e puoi ringraziare i tester per aver scoperto quel difetto.
In secondo luogo, i tester devono scrivere casi di test falsi, il che garantisce che il codice non faccia ciò che non dovrebbe fare. Una regola pratica ragionevole è che scrivi 5-10 casi di test falsi per ogni caso di test positivo. Ciò significa comprendere ulteriormente i requisiti e spesso questol'informazione è, o almeno era nel nostro progetto, confusa e ambigua. (E non è stato a causa del basso sforzo nella raccolta dei requisiti - avevamo solo qualcosa come 13.000 nel nostro team.) Ancora una volta, gli sviluppatori avranno scritto il loro codice usando i loro presupposti, o peggio ancora, non lo avrebbero nemmeno preso in considerazione. Quindi cosa fa il codice in queste condizioni che non sono normali? Non lo sai fino a quando non lo hai provato. Forse il programma non risponde; forse si blocca e basta; 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 - ERRORE NEL PROGRAMMA DI BANDIERA DI [IL NOME DELLA TUA IMPRESA] LASCIA I NUMERI DELLA CARTA DI CREDITO DEI CLIENTI.
Quindi tratta bene i tuoi tester. Trattali bene. Dopotutto, sono quelli che sradicano i bug nel tuo software e semplificano la vita e la nostra.
I bravi tester che sono in grado di analizzare i problemi in modo efficiente e possono fare un'automazione dei test decente valgono il loro peso in oro poiché ci sono così tanti tester di cowboy là fuori (quando intervista un "tester" una volta che è scoppiato a ridere mentre si rendeva conto che sapevamo che stava facendo roba sul posto mentre viene interrogato sul suo CV).
Nella mia squadra il tester è trattato alla pari - che include responsabilità e salario. Se vuoi un tester che fa clic per tutto il giorno, esternalizzalo in un posto economico (lo facciamo anche noi).
Aggiorna dopo aver letto le altre risposte: ci sono molti professionisti del controllo qualità che adorano il lavoro che svolgono. Giusto per dare un'altra prospettiva se non ti sei imbattuto in posizioni di QA rispettate, un esempio qui: Test di app / mobile app integrate per i principali produttori di automobili. Assicurano che i requisiti aziendali siano completamente soddisfatti prima che un veicolo venga immesso sul mercato e nessun utente abbia esperienza di un cruscotto dell'auto lento o che non risponde. Lavorano a stretto contatto con i manager e la gestione di livello superiore, nonché con gli sviluppatori a partire dalla pianificazione del processo di controllo qualità per condurre test pratici sui simulatori nella struttura di progettazione. Non riesco a pensare che siano di basso profilo, gestiscono enormi responsabilità e proprietà 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 società di servizi software in cui tutto è guidato da "requisiti aziendali"), poiché lo considerano un ambiente di lavoro non tecnico. Vengono dati fogli Excel con istruzioni come "fai clic su tutti i collegamenti nella pagina Web e verifica", sono costretti a lavorare con i laureati di flussi non tecnici (scienza, arte) che considerano un'umiliazione e si sentono come se le loro abilità tecnologiche non lo fossero utilizzato. Queste assegnazioni si basano esclusivamente sui requisiti dell'organizzazione e una più fresca, il più delle volte, non ha il potere di negoziare il suo percorso professionale. Quindi, se sei in cerca di lavoro e miri a un'azienda IT così grande, sei stato avvisato. In pratica, non puoi fare molto se non 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 in una certa misura. Personalmente so che le opportunità per incarichi in loco (= carichi di denaro dal punto di vista di un programmatore offshore) sono più per unità di test in la mia organizzazione rispetto a qualsiasi altra unità. Funzionano con tutti i verticali del settore come riempitivi o colle, poiché i test sono inevitabili in progetti in tutti i settori.
Se sei sicuro di poter guidare la tua carriera nel modo desiderato, i test non sono 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 stai lavorando (rispetto a uno sviluppatore che si concentrerebbe principalmente su qualche parte del sistema). A questo punto si può scegliere di passare anche a un tipo di analista aziendale di ruolo.
Conosco aziende in cui il team QA è responsabile delle pubblicazioni. Ciò significa che hanno il potere di bloccare un rilascio a causa della mancanza di qualità. Se viene segnalato un problema sul campo, questi sono i primi nella linea di tiro (ben dopo l'ingegnere sul campo).
In genere hanno una conoscenza del dominio superiore. Tendono a conoscere meglio la funzionalità complessiva del prodotto mentre gli sviluppatori si concentrano sul loro modulo / funzionalità.
Conosco anche organizzazioni di controllo qualità in cui devono scrivere i propri strumenti di test. Per non parlare dell'automazione dell'intera roba. Sono uno sviluppatore e ho sempre valutato i ragazzi del QA che testano le mie funzionalità.
Almeno nella mia organizzazione, il QA viene trattato allo stesso modo con gli sviluppatori. Penso che sia a causa del dominio (telecomunicazioni) in cui la conoscenza del protocollo e dell'architettura di rete è valutata allo stesso modo con le capacità di programmazione.
Sì. Piace o lascialo sono ugualmente importanti ma sono sempre meno preferiti. Può essere perché sono facili da sostituire.